Pertama, ini bukan jawaban, lebih sebagai pendekatan diagnostik.
Ini sama sekali tidak komprehensif - atau bahkan sesuatu yang dekat, itu hanya titik awal.
Saatnya Byte Pertama
Waktu ke byte pertama (TTFB) memiliki sejumlah komponen:
- Pencarian DNS: Temukan alamat IP domain (kemungkinan peningkatan: lebih banyak / didistribusikan / server DNS responsif)
- Waktu koneksi: Buka soket ke server, negosiasikan koneksi (nilai khas harus sekitar waktu 'ping' - perjalanan pulang-pergi biasanya diperlukan - keepalive akan membantu untuk permintaan berikutnya)
- Menunggu: pemrosesan awal diperlukan sebelum byte pertama dapat dikirim (ini adalah tempat perbaikan Anda seharusnya - itu akan paling signifikan untuk konten dinamis.
Ketika Anda melihat output ApacheBench, Anda juga melihat:
- Memproses: Ini adalah jumlah menunggu + transfer konten lengkap (jika waktu transfer secara signifikan lebih lama dari yang diharapkan untuk mengunduh jumlah data yang diterima, sedang diproses lebih lanjut (setelah byte pertama diterima) sedang terjadi (misalnya halaman tersebut adalah pembilasan konten karena tersedia)
Perbandingan untuk Menghilangkan komponen
Dengan beberapa pengecualian, masalah Anda akan terletak pada pemrosesan backend, yang biasanya disebabkan oleh kode yang terlalu rumit / tidak efisien, atau MySQL yang dikonfigurasi dengan buruk.
Cara yang baik untuk mendekati masalah ini adalah melalui serangkaian perbandingan yang akan menghilangkan berbagai aspek pengaturan Anda. Perbandingan yang baik harus tetap konstan sebanyak mungkin untuk membantu mempersempit masalah. Saat ini, Anda telah memberikan perbandingan berikut:
- Situs identik (dikloning) berjalan di server lama dan server baru:
- Perbedaan: Server
- Hasil: server lama cepat; server baru lambat
- Catatan: Yang Anda butuhkan di sini adalah untuk menghitung perbedaan antara server-server ini - baik dalam hal tumpukan yang digunakan (Nginx, dll) dan perangkat keras (apakah server lama lebih cepat karena merupakan mesin yang lebih kuat?)
- Kesimpulan: kode mungkin dapat berjalan cepat pada pengaturan yang benar
- Situs uji vs situs lengkap di server baru
- Perbedaan: konten, tema, plugin, dll
- Hasil: situs uji cepat, situs lengkap lambat
- Catatan: secara teori, tes ini akan membantu Anda menghilangkan banyak aspek pengaturan Anda - DNS, jaringan, bahkan pengaturan nginx / php / mysql Anda - namun, itu tidak cukup 'adil'.
- Kesimpulan: konten tambahan memiliki dampak signifikan terhadap kinerja
Tes yang ideal akan membuat Anda menduplikasi situs lengkap Anda, tetapi kemudian menghapus semua konten kecuali satu artikel dan komentar terkait. Tujuan dari tes ini adalah untuk menentukan secara meyakinkan apakah jumlah besar konten yang menjadi masalah atau apakah aspek lain dari pengaturan Anda (plugin wordpress, tema, dll) adalah penyebabnya. Anda pada dasarnya akan membandingkan kinerja situs yang identik, pada server yang sama (baru) - memuat halaman yang sama (panjang yang sama, dll) - dengan satu-satunya perbedaan adalah total konten situs (misalnya ada kemungkinan besar beberapa plugin tidak skala dengan baik dengan peningkatan konten).
Tanpa mengubah apa pun, ada beberapa perbandingan lain yang dapat Anda lakukan:
- Tes dari lokasi yang jauh vs lokal - ini akan membantu mengidentifikasi apakah jaringan, latensi, dns, dll adalah penyebabnya
- Anda telah (agak) melakukan ini dan sebagian besar menyimpulkan bahwa Anda tidak memiliki masalah jaringan.
- Tes melalui Varnish (yaitu port 80) vs nginx secara langsung (port 8080) - cobalah untuk tidak mengubah konfigurasi antar tes - cukup gunakan port yang benar. Ini akan menunjukkan kepada Anda dampak Varnish. Karena Varnish adalah lapisan caching, ia harus melayani semua permintaan setelah yang pertama dengan sangat cepat - pada dasarnya, ia harus mem-bypass backend dan pemrosesan yang diperlukan untuk menghasilkan halaman yang dinamis, dan melayani salinan yang di-cache dengan sangat cepat.
- Anda telah melakukan ini (walaupun, tidak secara lokal) dan menunjukkan bahwa Varnish memiliki dampak positif yang signifikan terhadap kinerja Anda.
Tuning Backend Anda
Pada titik ini Anda seharusnya sudah menemukan masalah atau menyimpulkan bahwa masalahnya ada di backend Anda. Itu membuat Anda Nginx, PHP, atau MySQL.
(Saya harus menyebutkan di sini, yang selalu berguna untuk mengetahui apakah hambatan Anda adalah CPU, RAM, atau I / O - antara sar, top, iostat, vmstat, free., Dll Anda harus dapat datang ke beberapa kesimpulan tentang ini)
Nginx
Nginx hanya menerima permintaan dan menyajikan konten statis atau memindahkan permintaan ke PHP-FPM - biasanya tidak banyak yang dioptimalkan dengan Nginx.
- Atur pekerja = # inti CPU
- Aktifkan keepalive (nilai 10-15 baik)
- Nonaktifkan pencatatan yang tidak dibutuhkan
- Tambah ukuran buffer jika diperlukan
- Hindari pernyataan if (gunakan nama statis alih-alih regex jika memungkinkan, hilangkan ekstensi yang tidak dibutuhkan)
Idealnya, blog percobaan dan blog hasil kloning Anda memiliki konfigurasi yang identik, dalam hal ini, Anda telah secara efektif menghilangkan Nginx sebagai masalahnya.
Aplikasi
Dalam kasus di mana Anda mencoba mengidentifikasi masalah dalam kode Anda (misalnya plugin lambat, dll) log lambat adalah tempat untuk memulai.
- Aktifkan log lambat MySQL dan log lambat PHP-FPM jalankan patokan Anda dan lihat apa yang muncul sebagai lambat.
MySQL
- Tingkatkan cache Anda dan jalankan mysqltuner.pl untuk mendapatkan titik awal yang baik.
PHP
- nonaktifkan ekstensi yang tidak dibutuhkan,
- nonaktifkan register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- tingkatkan memory_limit
- open_basedir dan safe_mode memiliki implikasi kinerja yang signifikan, tetapi juga dapat memberikan lapisan pertahanan tambahan. Uji dengan dan tanpa mereka, untuk menentukan apakah dampaknya terhadap kinerja dapat ditoleransi.
PHP-FPM
- Sesuaikan nilai pm *. - tingkatkan untuk menangani beban tinggi
Perlu dicatat bahwa hasil htop Anda menunjukkan php-fpm mengkonsumsi sebagian besar CPU - dan masalah Anda tampaknya terkait langsung dengan ini.
Caching
Setelah Anda mengoptimalkan setiap kemacetan yang mungkin terjadi, mulailah melakukan caching.
- Anda sudah memiliki cache opCode (APC) - pastikan itu berfungsi (dilengkapi dengan file uji) - periksa tingkat hit cache Anda, dan jika mungkin miliki cache APC ke memori, bukan ke disk.
- Atur kode Anda ke cache (mis. Menggunakan plugin untuk Wordpress seperti W3TC)
- Dengan nginx Anda dapat mengatur caching FastCGI - tetapi karena Anda memiliki Varnish, ini sebaiknya dihindari.
- Setup layer caching, seperti Varnish (yang sudah Anda lakukan) - dan pastikan itu berfungsi (mis. Gunakan varnishstat, baca Mencapai Hitrate tinggi )
- Tambahkan lebih banyak caching untuk komponen situs Anda - mis. MemCached jika ada
Terkadang, mengingat keterbatasan aplikasi dan perangkat keras Anda, Anda mungkin tidak dapat meningkatkan kinerja backend sebanyak itu - namun, itulah titik caching - untuk meminimalkan penggunaan backend.
Bacaan lebih lanjut
if -farahan Anda menggunakan dalamlocationwadah di konfigurasi nginx. Berdasarkan apa yang saya baca di sini wiki.nginx.org/Pitfalls , saya merasa bahwa-fmelakukan pencarian yang tidak efisien untuk file yang dapat menyebabkan masalah Time To First Byte, terutama jika Anda memiliki direktori dengan sejumlah besar file.