AWS上的Apache和Passenger性能

我在AWS上看到一个奇怪的问题，我希望看看是否有人对此有何看法？AWS上的Apache和Passenger性能

设置：
利用3 EBS GP2卷在RAID0组 t2.medium实例
elasticache（分布式缓存）本地MySQL配置成从所述RAID组
Ubuntu的运行14.04
阿帕奇2.4.7
乘客5.1.7
日志发送到papertrail并没有写入到本地磁盘

测试：

测试从AWS上的t2.micro实例的jmeter运行，该实例访问主页，登录，查看配置文件页面，然后重新登出。在登录和配置文件视图中有数据库查询，但mysql看起来并不是瓶颈。

测试配置1： mpm_event.conf

<IfModule mpm_event_module> 
StartServers  10 
MinSpareThreads  75 
MaxSpareThreads  250 
ThreadLimit  128 
ThreadsPerChild  32 
MaxRequestWorkers 1984 
ServerLimit  800 
MaxConnectionsPerChild 0 
</IfModule>

而且passenger.conf看起来是这样的：

<IfModule mod_passenger.c> 
PassengerRoot /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini 
PassengerDefaultRuby /usr/bin/passenger_free_ruby 
PassengerMaxPoolSize 30 
PassengerPoolIdleTime 150 
PassengerPreStart *** points to host in /etc/hosts *** 
PassengerMaxRequestQueueSize 500 
</IfModule>

所以上面的配置结果中没有任何错误（部分由增加RequestQueueSize），但是响应在测试结束时以90秒（！）为北。

现在，这里的事情变得怪异，如果我改变配置乘客到：

<IfModule mod_passenger.c> 
PassengerRoot /usr/lib/ruby/vendor_ruby/phusion_passenger/locations.ini 
PassengerDefaultRuby /usr/bin/passenger_free_ruby 
PassengerMaxPoolSize 2 
PassengerPoolIdleTime 150 
PassengerPreStart *** points to host in /etc/hosts *** 
PassengerMaxRequestQueueSize 500 
</IfModule>

的响应时间更快，使他们到60秒，它仍然是缓慢的，但要好得多。

我在监控（使用htop，iotop，iftop，mytop，free -m和乘客身份）时看到的是乘客状态排队从测试开始稳步增长，如果有100个队列限制作为标准，它将开始提供503错误，但是当队列增加时，请求排队大量时间。

乘客企业不是我真正的选择使用。

我在这里做了错误的乘客配置或与MPM的权利？这台服务器应该能够处理600多个连接，并在1.3秒内响应（我已经在Brightbox服务器上运行过相同的测试，并且性能相当可笑）

我愿意接受任何和所有建议。

注：

我已经通过计算对内存使用情况的乘客，跑到这应该站在35，我用30不完全最大程度的发挥RAM由于没有运行的交换，因为它更糟糕，当它击中它。

来源

2017-08-08 abkay

乘客作者在这里。这听起来像是你遇到了应用程序内部或后面的瓶颈。如果您的应用程序无法足够快地处理请求，那么Passenger请求队列一直保持增长，直到它的限制为止是正常的。同样正常的是，你增加队列的次数越多，你的反应越接近队列末尾。

更多的进程让事情变得更慢听起来就像你的进程正在争夺一个只支持非常低并发性的共享资源。这可能是数据库，但你已经排除了。它可能是您拨打的网络服务。它可能是一个文件锁。没有关于你的应用程序的知识，我不知道问题到底是什么，但至少看起来Passenger并不是问题。

来源

2017-08-09 17:36:30 Hongli

我将使用[rack-mini-profiler]（https://github.com/MiniProfiler/rack-mini-profiler）和[flamegraphs]（https://github.com/CamJN）来添加您的web应用程序/ flamegraph）宝石是找到这些瓶颈的好方法。（我链接的flamegraphs宝石是我自己的叉子，它更容易阅读和解释）。 –

AWS上的Apache和Passenger性能

回答

相关问题