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性能

回答

相關問題