一、使用工具
- Apache的 ab 测试工具 apachebench
ab -n 100 -c 10 http://jeeinn.com:80/index.php
-n 100表示请求总数为100
-c 10表示并发用户数为10- http_load
http_load -p 并发访问进程数 -s 访问时间 需要访问的URL文件压测原理 一般会创建多个并发访问线程，模拟多个访问者同时对某一个 URL 地址进行访问。它的测试目标是基于 URL 的，因此，它既可以用来测试 apache 的负载压力，也可以测试 nginx、lighthttp、tomcat、IIS 等其它 Web 服务器的压力。
二、简易算法
根据服务器的瓶颈来计算，感觉是较为合适的一种计算方式。这里引用“开源小站”的说法：
- DB极限型 （ 50～100QPS ）
- 带宽极限型 （ 300～800QPS ）
- 内网带宽极限＋Memcache极限型 （ 500～1000QPS ）
- 锁/同步模式极限型 （ 1000～2000QPS ）
- C10K极限 （ 2000QPS以上 ）
以下为原站引用：
评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个Web网站的数量级。
Web网站的几个并发量级
相信很多人谈论一个网站的热度，总免不了会询问日均PV，同时在线人数、注册用户数等运营数据，说实话从技术角度来说，这几个数值没有一个可以放在一起比较的——一个静态网站的PV跟一个SNS类/Web Game网站的PV根本就不是一回事。由于互联网有一个传说中的“3秒定律”，可能当下更多的网站技术指标要求1.5秒以内加载整页，或者至少可以达到阅读的标准。如果要较真什么“同时在线”，毫不客气的说，对于HTTP这类短链接的网络协议来说，在WebSocket还不普及的时代，能统计在线纯属扯淡，唯一能做的只是取个时间段，计算下访问用户而已。这些依然可以换算成QPS（Quest Per Second每秒请求数）。就并发而言，我唯一推崇的只有理论最大QPS和悲观QPS。
这里就大致根据理论最大QPS，并保持尽可能不用技术术语的原则，给网站做几个分类。
50QPS以下——小网站
没什么好说的，简单的小网站而已，就如同本站这样，你可以用最简单的方法快速搭建，短期没有太多的技术瓶颈，只要服务器不要太烂就好。
50～100QPS——DB极限型
大部分的关系型数据库的每次请求大多都能控制在0.01秒左右，即便你的网站每页面只有一次数据库请求，那么页面请求无法保证在1秒钟内完成100个请求，这个阶段要考虑做缓存（cache）或者多数据库（DB）负载。无论那种方案，对网站重构是不可避免的。
300～800QPS——带宽极限型
目前服务器大多用了IDC机房提供了“百兆带宽”，“百兆出口”，似乎这就是单机的最高配了。这意味着网站出口的实际带宽是8M Byte左右。假定每个页面只有10K Byte，在这个并发条件下，即便你的网站是静态页面，不用什么数据库之类的技术，百兆带宽早已经吃完。这个情况下首要考虑是CDN加速／异地缓存，多机负载等技术。
500～1000QPS——内网带宽极限＋Memcache极限型
由于Key/value的特性，每个页面对memcache的请求远大于直接对DB的请求，Memcache的悲观并发数在2w左右，看似很高，但事实上大多数情况下，首先是有可能在此之前内网的带宽就已经吃光，接着是在8K QPS左右的情况下，但节点上的Memcache已经表现出了不稳定，如果代码上没有足够的优化，缓存的miss可能会导致系统直接将压力转嫁到了DB层上，这就使整个系统在达到某个明显的阀值之后，性能迅速下滑或直接宕机。
1000～2000QPS——锁/同步模式极限型
好吧，一句话：线程模型决定吞吐量。不管你系统中最常见的锁是什么锁，这个级别下，文件系统访问锁都成为了灾难。从网站内容的角度上讲，几乎任何的增删改都会牵扯到锁。“等解锁”的过程将会成为系统最重要的性能消耗。这就要求系统中不能存在中央节点，所有的数据都必须分布存储，数据需要分布处理。总之，关键词：分布
2000QPS以上——C10K极限
尽管现在很多应用已经实现了C25K，但短板理论告诉我们，决定网站整体并发的永远是最低效的那个环节。我承认我生涯中从未遇到过2000QPS以上，甚至1.5K以上的网站，希望有此经验的哥们可以一起交流下