我的理解是handeled是说处理完成的吧
730个应该是HTTP会话过程意外终止的

会话过程意外终止,这个是用户的问题,还是我服务器的问题??:D

另一台 apache 服务器上一年来,也有17000多个. 累计.

accepts 应该表示的是socket连接已经建立完成
handled 是client发送的数据（HTTP请求）已经进行了对应的处理

之间的差异有可能是client连接成功但是没有发送任何有效数据或者是发送数据超时造成的

造成差异的具体原因多种多样，比如对一个放在公网的web server来说应该有不少人用各种扫描工具之类的的进行扫描吧，如果是自己在内网测试的话，也有可能是某些时刻服务器负载过大造成一些连接出现问题或者来不及响应之类的吧
个人认为应该问题不大

之前对apache和nginx的代码有过一些研究，nginx在大并发（1万以上）的情况下肯定是比apache要有优势的。因为nginx和lighttpd这些新的web server在linux下用的是epoll，FreeBSD下用的是kqueue，比apache的select/poll效率高很多

如果web server的并发数较少，比如只有几百个，那么apache和nginx的性能差距并不大，而且apache的多进程模型会更加稳定，当然nginx也可以配置成为多进程模式

謝謝前輩的分析,真的是說的非常的有經驗.
基本上了解了.

謝謝前輩指點.

又看了下新版的apache(>2.2)，发现新的event MPM模式使用的是epoll和kqueue，在网络连接数和大并发的情况下可以使用，更正一下

nginx还算是不错了，我遇到的问题就是和java的app server配合的时候没有模块支持，用proxy模式的时候很多应用会出问题。

google 上看了一下，好像都吹的很神乎嘛

生产环境用了一个月了，确实不错，今天升级到0.7.59了

算算也用了1個多月了,不錯... 沒問題....

我做个一个实际测试双核双CPU浪潮服务器，4G内存。
使用Discuz7的论坛索引页面进行测试，模拟1024个连接，连续访问10000次。

有推导出相关结论：

1. 性能上来说NGINX还是要比Apache(Prefork)有优势。但主要是高并发连接的情况下。
Apache配置文件经过优化后（1024 Thread，4096 MaxClient）能够达到Nginx
的水平（24个worker进程，64个php-cgi进程），而且8192个连接nginx也保持稳定。
Apache的话2048个连接的测试就通过不了。

2. 在上述负载下NGINX的的出错率一直比较高，2%-5%非2xx的错误。Apache的确是
如楼上某位所言，负载高(uptime达到了32，nginx是3)，但是不出错。一个非2xx
的错误都没有。

3. 上述差别其实就是select()和epool模式的差别所在，所以可比性并不强。应该将
Aapache的epoll MPM的性能与之做比较。

4. 静态页面方面，一个1K左右的HTML，nginx吞吐是Apache的3倍，但是系统负载
只有Apache的1/3（Uptime 0.9 vs 0.35）

对应的测试过程记录文件在附件里。