Amazon Linux EC2 Webserver / MYSQL升級 - 導致錯誤建立數據庫連接的流量

Question

為了給你一點背景，我目前有一個網站，允許用戶上傳照片。 該網站最初是在GoDaddy共享服務器上，但最近的流量激增迫使我探索其他選項。 在高峰時段，該站點包含400多個活動訪問者，當與用戶上載相結合時，會強制共享服務器關閉。

我在通過AWS設置服務器方面有一些經驗，並試圖將網站放在c1.medium實例Amazon Linux上。 該網站與MYSQL數據庫位於同一實例中。 雖然我已經讀到這通常不贊成，但我已經同樣讀到將數據庫移動到另一個實例不會顯着提高速度。 不幸的是，c1.medium實例也無法支持流量，我很快收到錯誤建立數據庫連接。 該網站有時會加載，因此問題源於流量負載而不是數據庫的實際問題。

我的問題是問題是圍繞MySQL進行的嗎？ 備份時數據庫本身大約為250MB。 問題是由對數據庫的輸入/輸出請求引起的嗎？ 我讀過有類似問題的人發帖，他們說安裝MySQL 5.6解決了這個問題，但也讀過MySQL 5.6比MySQL 5.5慢，這是我目前的版本。

在進行一些初步研究后，我開始相信我可以通過增加EBS的IPOS來解決問題。 最初我把IPOS設置為標准，但是將其更改為預配置IOPS和EBS大小的30倍（即60GB - 1800 IOPS）。 這再一次似乎沒什么影響。 我需要升級我的實例嗎？ 在決定實例時，我應該關注哪些措施？ 看來，具有高網絡性能和EBS優化的最便宜的實例將是c3.xlarge。 建議？

Answer 1

需要考慮的幾件事：

1）將數據庫服務器與Web服務器分開

您的數據庫不應與您的Web服務器共享資源。 結果他們都表現不佳。 更容易找到瓶頸是什么。

2）升級到MySQL 5.6

在我看過和完成的所有基准測試中，5.6的性能優於5.5

3）配置數據庫以利用您的資源

根據存儲引擎和機器中分配的內存，配置MySQL，例如將innodb_buffer_pool_size設置為（DEDICATED）RAM的 70％

4）監控MySQL並檢查慢查詢日志

慢查詢日志顯示緩慢且低效的查詢

5）學習使用EXPLAIN

EXPLAIN顯示MySQL中的查詢計划在慢速查詢中運行EXPLAIN來調整它們

6）使用鍵值存儲來緩存查詢

使用Memcached或Redis緩存查詢，以便它們不會訪問您的數據庫並從內存中返回重復的查詢

7）增加IOPS和擴展

增加IOPS並獲得更好的硬件有助於提高效率，但使用高效查詢會更有效。 大多數情況下，查詢和應用程序是導致性能問題的更大因素

8）復制

如果仍有問題，請考慮轉向MySQL主/從復制。

最后注意：使用EBS是因為EC2上的存儲是短暫的並且不會持久存在。

Answer 2

我們最近對與全球客戶群中的大量最終用戶峰值相關的性能瓶頸進行了廣泛的研究，並且分析實際上表明數據庫 - 迄今為止 - 是導致速度減慢甚至崩潰的最常見原因。 該報告（ https://queue-it.com/trend-report ）包含了客戶關於如何改善情況的最佳實踐建議，您可能會發現這些建議很有幫助。