用Netty作http静态资源服务器，类似Nginx这样的，大一点的文件响应不正常怎么回事？

您好，对于你的遇到的问题，我很高兴能为你提供帮助，我之前也遇到过哟，以下是我的个人看法，希望能帮助到你，若有错误，还望见谅！。展开全部

Nginx+PHP-fpm组合，以内存占用小，负载能力强壮的特点，成为小内存VPS建站的首选组合。我们一起来探讨一下nginx+php-fpm高负载的优化方法。

先来看看nginx配置参数的优化。nginx是前端接受浏览器端请求的web server, 配置可调的参数如下：

下面是示例nginx配置

user www-data

worker_processes 8

#worker_processes 调至8， 大于8没什么用，小于8，nginx性能发挥不出来

worker_cpu_affinity 01 10 01 10 01 10 01 10

#worker_cpu_affinity 参数可以使nginx充分发挥多核Cpu的性能优势 ，上面的配置是针对双核CPU的配置。01表示第一个核，10表示第二个核，如果是四核cpu，一至四个核分别表示为 0001 0010 0100 1000

error_log /var/log/nginx/error_log crit

pid /var/run/nginx.pid

worker_rlimit_nofile 10240

#worker_rlimit_nofile 是nginx能打开文件的最大句柄数，我们需要把这个数字设大一点。

#linux系统的文件查看数限制查看是用 ulimit -n ，修改这个限制是用 ulimit -HSn 65535

events

{

use epoll

#必须要用高效的event驱动，以获得最大性能

worker_connections 10240

#max_clients = worker_processes * worker_connections/4 （最大连接数的计算公式）

}

http

{

include /etc/nginx/deny.iplist

include /etc/nginx/mime.types

default_type application/octet-stream

server_name_in_redirect off

server_names_hash_bucket_size 128

server_tokens off

client_header_buffer_size 32k

#client头buffer可以调为32K

large_client_header_buffers 4 32k

client_max_body_size 8m

sendfileon

tcp_nopush on

keepalive_timeout 65

tcp_nodelayoff

client_body_timeout 10

client_header_timeout 10

send_timeout 60

output_buffers 1 32k

postpone_output 1460

open_file_cache max=1000 inactive=20s

open_file_cache_valid30s

open_file_cache_min_uses 2

open_file_cache_errors on

fastcgi_connect_timeout 300

fastcgi_send_timeout 300

fastcgi_read_timeout 300

fastcgi_buffer_size 32k

fastcgi_buffers 4 32k

fastcgi_busy_buffers_size 32k

fastcgi_temp_file_write_size 32k

gzip on

gzip_buffers 4 16k

gzip_http_version 1.0

gzip_comp_level 2

gzip_types text/plain application/x-javascript text/css application/xml

gzip_proxied expired no-cache no-store private auth

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:80m inactive=1d max_size=2500m

proxy_temp_path /var/lib/nginx/proxy

proxy_connect_timeout 300

proxy_read_timeout 120

proxy_send_timeout 120

proxy_buffer_size 16k

proxy_buffers 4 16k

upstream wordpressnginx

{

server 127.0.0.1:6000 weight=1 fail_timeout=120s

}

include /etc/nginx/sites-enabled/*

}

上面的配置里面，有多处设及到buffer和timeout的地方。我们可以根据需要，慢慢调大这些参数，buffer自然是大点好，但不要太大。16K是标准配置，可以增加到32，往上加更大也不是不行，但 要考虑到你系统内存大不大，够不够用。timeout是超时，如果服务器很繁忙，不妨增加超时等待时间，以避免频繁出现502错误。

gzip是必须开启的，reverse proxy在允许的情况下，也尽量开启，一 是可以提升响应效率，二是降低服务器压力，gzip开启后更可以节省服务器带宽。

nginx主要的配置如上所述。

现在看一下php-fpm的配置。

[global]

pid = run/php5-fpm.pid

process_control_timeout = 5

[www]

listen = /dev/shm/php-cgi.sock

listen.allowed_clients = 127.0.0.1

user = www-data

group = www-data

pm = static

pm.max_children = 7

#这个决定了 php-fpm的总进程。我们要想同时响应更多的并发数，这个数值要尽可能大，比如500，1000

pm.max_requests = 10000

#并发数越大，这个最大请求数应该越大，并发数小，这个数值也应该越小。它表示，php-fpm进程响应了10000个并发请求之后，就自动重启一下进程。

request_terminate_timeout = 30

#表示等待30秒后，结束那些没有自动结束的php脚本，以释放占用的资源。

env[HOSTNAME] = $HOSTNAME

env[PATH] = /usr/local/bin:/usr/bin:/bin

env[TMP] = /tmp

env[TMPDIR] = /tmp

env[TEMP] = /tmp

小内存的vps虽然经过使用php-fpm+nginx，提升了系统的效率，可以同时响应较多的并发请求，但是当并发数上来了，比如从100上升到10000，小内存肯定响应不过来，cpu也会 因为太忙，而导致系统负载变得很高很高，这个时候，我们就要考虑升级硬件配置了。

内存越大越好，CPU核心频率越高越好，CPU核越多越好。硬盘最好是SSD+RAID10。这样性能不仅高，数据安全也有保障。

上面所提到的各个配置参数，设及到数值的，不妨自己 多试着调小，调大参数，然后重启下nginx或者php-fpm进程，看看效果怎么样。

下面介绍一个比较好的压力测试工具，siege.

debian和ubuntu用户可以通过apt-get install siege来安装siege.

siege是一个跟ab.exe相似的http压力测试软件。

我们可以用siege来测试我们的网站和服务器性能。

siege -r 100 -c 10

-r 是 repeat , -r 100是重复100次测试

-c 10是表示模拟10个用户同时并发连接

最后面是要测试的URL地址。

测试过程中可以随时按CTRL+C中止进程，siege会生成一个报告给我们。

我们可以同时根据siege的测试结果和监视服务器的负载情况，对系统压力状况进行一个深入了解和分析。接下来可以帮助我们判断该如何进行下一步操作，是继续优化配置，还是升级硬件。非常感谢您的耐心观看，如有帮助请采纳，祝生活愉快！谢谢！

为什么Nginx的性能要比Apache高得多？

????这得益于Nginx使用了最新的epoll（Linux?2.6内核）和kqueue（freebsd）网络I/O模型，而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。

处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：

假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了。为什么会出现502错误呢？

nginx出现502有很多原因，但大部分原因可以归结为资源数量不够用，也就是说后端php-fpm处理有问题，nginx将正确的客户端请求发给了后端的php-fpm进程，但是因为php-fpm进程的问题导致不能正确解析php代码，最终返回给了客户端502错误。优化php-fpm，优化代码，加大内存才是解决502的根源。10000并发的话，nginx的表现怎么样？

2009年9月3日下午2：30，金山游戏《剑侠情缘网络版叁》临时维护1小时，大量玩家上官网，论坛、评论、客服等动态应用Nginx服务器集群，每台服务器的Nginx活动连接数达到2.8万。

一、什么是Netty

Netty是一个高性能 事件驱动、异步非堵塞的IO(NIO)Java开源框架，Jboss提供，用于建立TCP等底层的连接，基于Netty可以建立高性能的Http服务器，快速开发高性能、高可靠性的网络服务器和客户端程序。支持HTTP、 WebSocket 、Protobuf、 Binary TCP |和UDP，Netty已经被很多高性能项目作为其Socket底层基础，如HornetQ Infinispan Vert.x Play Framework Finangle和 Cassandra。其竞争对手是：Apache MINA和 Grizzly。

也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。

“快速”和“简单”并不意味着会让你的最终应用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMTP,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。

二、不选择Java原生NIO编程的原因

首先开发出高质量的NIO程序并不是一件简单的事情，除去NIO固有的复杂性和BUG不谈，作为一个NIO服务端，还需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况，如果你没有足够的NIO编程经验积累，一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是，一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，需要重启服务器，这种非正常停机会带来巨大的损失。

从可维护性角度看，由于NIO采用了异步非阻塞编程模型，而且是一个I/O线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。

现在我们总结一下为什么不建议开发者直接使用JDK的NIO类库进行开发，具体原因如下。

1）跨平台与兼容性：NIO算是底层的APIs需依赖系统的IO APIs。但Java NIO发现在不同系统平台会出现问题。大量测试也耗不少时间；NIO2只支持JDK1.7+，而且没提供DatagramSocket，故NIO2不支持UDP协议。而Netty提供统一接口，同一语句无论在JDK6.X 还是JDK7.X 都可运行，无需关心底层架构功能！

2）JAVA NIO的ByteBuffer构造函数私有，无法扩展。Netty提供了自己的ByteBuffer实现，通过简单APIs对其进行构造、使用和操作，一此解决NIO的一些限制。

3）NIO对缓冲区的聚合与分散操作可能会导致内存泄漏。直到JDK1.7才解决此问题。

4）NIO的类库和API繁杂，使用麻烦，你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。

5）使用JAVA NIO需要具备其他的额外技能做铺垫，例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的NIO程序。

6）可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题。

7）JDK NIO的BUG，例如臭名昭著的epoll bug，它会导致Selector空轮询，最终导致CPU 100%。官方声称在JDK 1.6版本的update18修复了该问题，但是直到JDK 1.7版本该问题仍旧存在，只不过该BUG发生概率降低了一些而已，它并没有得到根本性解决。该BUG以及与该BUG相关的问题单可以参见以下链接内容。

异常堆栈如下。

java.lang.Thread.State: RUNNABLE

at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)

at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)

at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

- locked <0x0000000750928190>(a sun.nio.ch.Util$2)

- locked <0x00000007509281a8>(a java.util.Collections$ UnmodifiableSet)

- locked <0x0000000750946098>(a sun.nio.ch.EPollSelectorImpl)

at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)

at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)

由于上述原因，在大多数场景下，不建议大家直接使用JDK的NIO类库，除非你精通NIO编程或者有特殊的需求。在绝大多数的业务场景中，我们可以使用NIO框架Netty来进行NIO编程，它既可以作为客户端也可以作为服务端，同时支持UDP和异步文件传输，功能非常强大。

---