首先,在线用户数和并量之间的关系 需要搞清楚。

　　根据先思考业务,得出业务特点

     在系统架构时期不要着急去想那个地方会是瓶颈，怎么去优化，而是先根据业务逻辑进行分析系统的特点如下，

　　　　业务的特点如是否上班时间使用？

　　　　业务处理是否集中在某个固定的时间点，如早上9点为高峰期，临下班10分钟为高峰期？

　　　　在线用户的活动特点，是半小时都不动，还是会不停的操作？

　　　　操作的内容是什么有什么特点，是集中的系统的某一个模块还是整个系统平均承担点击？

　　　　用户主要获取的内容是什么,纯文本、图片、视频？

　　　　系统需要具备什么的服务水平？如响应时间，一致性需求，可靠性需求等指标，是否允许操作失败，失败的代价是什么？

　　　　能否通过有损服务来提升系统的吞吐量？（如在100人的时候应该时间为0.1s，在1000人的时候为0.5s,用户的容忍量是什么,有损服务带来的代价是什么,能否忍受?）

       根据业务特点,有针对性的设计方案

1.使用Squid或者Varnish做缓存代理，将经常访问的图片等静态内容缓存起来，提高访问速度；
2.使用CDN内容分发网络，减少主服务器的压力（附CDN相关内容：CDN通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近）；
3.使用LVS服务器负载均衡，LVS服务器结合Keepalived做高可用；
4.LVS下面还可跟Nginx做负载均衡，再次分担压力，比如淘宝使用的再Nginx基础上改进的Tnginx。
5.DNS服务器上也可下功夫，比如做高级视图等等，这样可以解决不同网段访问Web服务器的速度问题；
6.最大的瓶颈还是在IO上，比如存储IO，比如数据库的IO。存储一方面需要保证数据不丢失，另一方面需要保证性能，比如做RAID、LVM；存储还需要考虑使用一套存储之间的数据同步（GFS、OCFS可以实现），数据的备份等等；数据库的话可以考虑使用查询缓存等等，这块我也正在学习中，展开有很多东西；
7.程序的话也可以优化，比如如果是Java Web程序，并且使用了Hibernate框架，就可以考虑使用查询缓存了；
8.硬件层：比如提高带宽，购买高转数性能好的硬盘等等；

摘自:（温国兵 http://www.zhihu.com/question/22002547）感觉回答的较衣详细^_^

补充:

　　9.根据业务特点进行拆分,如不相关的业务拆分部署、采用无状态的服务,增加系统的水平扩展能力

     10.采用针对短期变化不大的数据采用memcached,redis做缓期层,承载绝大多数的访问请求

　　11.根据IT技术,优化业务流程,而不是仅仅是根据业务描述去凑方案

     12.记录系统运行过中真实数据,针对优化用数据说话而不是拍脑袋,不要为了技术而技术为了优化而优化

     13.采用业界成熟的方案而不闭门造车,但也不要迷失.

     14.和领导积极沟通,获得高层的支持和认可,并争取相应的资源,这个也是很重要的一点.

持续优化

                持续优化,不做面子工程

                积累人才、技术、工具、流程和方法。

并发的比喻

　　　　　　个人有个不太恰当的比喻，系统是一个写字楼，在线用户数就是里面办公的人数。并发可以指同时出门，同时乘坐电梯、上厕所、出门等的人数。

用户的满意度不仅仅取决于乘坐电梯、上厕所、出门的活动。更多的取决于能否方便到达写字楼，里面的配套设施是否够舒服、物业是否够贴心.....。

 　　　　     写字楼高能够容纳的办公人数越多，理论上并发（电梯、上厕所、出门的）的压力也就越大。我们能做的就是在上、下班高峰期多开几个门，多搞几个电梯、每层多搞几个厕位^_^,把食堂放在中间的楼层；

根据人流适当调整电梯运行的楼层。对设备及时维修，减小故障率...

关于并发测试的术语:http://flymanhi.blog.51cto.com/1011558/1199053