Nginx php-fpm和Memcached的问题


Problems with Nginx php-fpm and Memcached

我有一个网站,在过去的几个月里,它的流量和往常一样多。我希望这个网站在不改变硬件的情况下在相同的时间内为更多的用户提供服务。目前我使用Apache2与Wordpress和Memcached。我想知道我是否可以使用Nginx在这个网站上获得更多的性能。当我有Nginx在Wordpress的web服务器上运行,我运行一个测试10000用户在60秒的时间内,我只得到600个成功的答案,其他9400个连接得到错误。(主要是超时)。IMG
当我使用Memcached额外到前面的配置,我得到9969个成功的答案,但每秒最大用户不超过451 IMG
但在我的网站上,有时每秒有超过1000个用户。有人能告诉我我做错了什么吗?

系统:
AWS EC2云服务器2GHz, 650MB RAM
Ubuntu 13.10
Nginx 1.4.7
Memcached 1.4.14

你应该考虑的数字是Avg error rate,你的WP + Nginx + Memcached配置看起来不太糟糕,所以在我看来这是一个很好的选择。也许您可以增加memcached中的-m参数以匹配一半的RAM。

但:memcached不保证数据在内存中可用,您必须为缓存丢失风暴做好准备。避免错过风暴的一种有趣方法是使用一些随机偏移量设置过期时间,例如10 + [0..]10]分钟,这意味着一些项目将被存储10分钟,而其他项目将被存储20分钟(目标是不是所有项目同时过期)。

同样,无论您将为memcached分配多少内存,它将只使用它需要的数量,例如,它只分配实际使用的内存。对于-k选项,然而(在您的配置中禁用),当memcached启动时保留整个内存,因此它总是分配整个内存量,无论它是否需要它。

451连接的数量实际上可以变化,这取决于。在执行基准测试时,查看平均值总是一个好主意,例如,拥有0%的Avg error rate451服务的客户端比拥有65%的Avg error rate和8200+服务的客户端要好。

然而,为了卸载更多的资源,你可以为Wordpress使用额外的缓存,有很多插件,我个人为此写了一个。

关于nginx配置,您也可以在那里调整一些参数:

worker_rlimit_nofile 100000;
worker_connections 4000;
# optmized to serve many clients with each thread, essential for linux use epoll;
# accept as many connections as possible,may flood worker connections if set too low
multi_accept on;
# cache informations about FDs, frequently accessed files
# can boost performance, but you need to test those values
open_file_cache max=200000 inactive=20s; 
open_file_cache_valid 30s; 
open_file_cache_min_uses 2;
open_file_cache_errors on;
# to boost IO on HDD we can disable access logs
access_log off;
# copies data between one FD and other from within the kernel
# faster then read() + write()
sendfile on;
# send headers in one peace, its better then sending them one by one 
tcp_nopush on;
# don't buffer data sent, good for small data bursts in real time
tcp_nodelay on;
# number of requests client can make over keep-alive -- for testing
keepalive_requests 100000;
# allow the server to close connection on non responding client, this will free up memory
reset_timedout_connection on;
# request timed out -- default 60
client_body_timeout 10;
# if client stop responding, free up memory -- default 60
send_timeout 2;
# reduce the data that needs to be sent over network
gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6]'.";

我们遇到的问题并不是一个真正的问题。我们只是把测试结果解释错了。

400个用户的限制不是一个实际的限制,服务器能够保持用户在一个恒定的水平,因为它足够快,立即回答所有的请求。

测试的结果不能与我的站点相比,我的站点获得了1k用户,因为它的硬件当然比AWS免费实例更好。但我认为对于这样一个"弱"的服务器来说,每秒400个用户是一个非常好的结果。所以

问题解决了我想,是因为我自己看测试结果的愚蠢…

谢谢你的帮助,bodi0.