İlk olarak, bu bir teşhis değil, bir teşhis yaklaşımıdır.
Bu hiçbir şekilde kapsamlı değildir - hatta yakın bir şey bile, bu sadece bir başlangıç noktasıdır.
İlk Bayt Zamanı
İlk bayt zamanı (TTFB) birkaç bileşene sahiptir:
- DNS Araması: Alan adının IP adresini bulun (olası iyileştirme: daha fazla sayıda / dağıtılmış / duyarlı DNS sunucusu)
- Bağlantı süresi: Sunucuya bir soket açın, bağlantıyı görüşün (tipik değer 'ping' süresi civarında olmalıdır - bir gidiş dönüş genellikle gereklidir - sonraki istekler için dikkatli olun)
- Bekleyen: İlk bayt gönderilmeden önce gereken ilk işlem (iyileştirmeniz gereken yer burasıdır - dinamik içerik için en önemli olanı olacaktır.
Bir ApacheBench çıktısına baktığınızda şunları da görürsünüz:
- İşleniyor: Bu, bekleyen + içeriğin tam aktarımının toplamıdır (aktarma süresi, alınan veri miktarını indirmek için beklenenden önemli ölçüde daha uzunsa, daha fazla işleme (ilk bayt alındıktan sonra) gerçekleşir (örneğin, sayfa içeriği mevcut olduğu gibi yıkamak)
Bileşenleri Ortadan Kaldırmak için Karşılaştırmalar
Birkaç istisna dışında, probleminiz genellikle aşırı karmaşık / verimsiz koda veya kötü yapılandırılmış MySQL'e inen arka uç işleminde yatmaktadır.
Bu soruna yaklaşmanın iyi bir yolu, kurulumunuzun çeşitli yönlerini ortadan kaldıracak bir dizi karşılaştırmadır. İyi bir karşılaştırma, sorunu daraltmaya yardımcı olmak için mümkün olduğunca sabit kalmalıdır. Şu anda aşağıdaki karşılaştırmaları yaptınız:
- Eski sunucuda ve yeni sunucuda çalışan özdeş (klonlanmış) site:
- Fark: Sunucu
- Sonuç: eski sunucu hızlı; yeni sunucu yavaş
- Notlar: Burada gerekenler, kullanılan sunucular (Nginx, vb.) Ve donanım açısından (daha güçlü bir makine olduğu için eski sunucu daha hızlı mıdır?) Bu sunucular arasındaki farkları ölçmektir.
- Sonuç: kod doğru kurulumda hızlı çalışabilir
- Yeni sunucuda site vs tam site
- Fark: içerik, temalar, eklentiler, vb.
- Sonuç: Test sitesi hızlı, tam site yavaş
- Notlar: Teorik olarak, bu test kurulumunuzun birçok yönünü ortadan kaldırmanıza yardımcı olmalıdır - DNS, ağ, hatta nginx / php / mysql kurulumunuz - ancak bu oldukça 'adil' değildir.
- Sonuç: Ekstra içeriğin performans üzerinde önemli bir etkisi var
İdeal test, sitenizin tamamını çoğaltmanızı, ancak bir makale ve ilişkili yorumlar hariç tüm içeriği silmenizi sağlar. Bu testin amacı, büyük miktarda içeriğin sorun olup olmadığını veya kurulumunuzun diğer yönlerinin (wordpress eklentileri, tema vb.) Nedeni olup olmadığını kesin olarak belirlemek olacaktır. Aynı sitelerin performansını aynı (yeni) sunucuda - aynı sayfayı (aynı uzunlukta, vb.) Yükleyerek karşılaştırırsınız - tek fark toplam site içeriğidir (örneğin, bazı eklentilerin artan içerikle iyi ölçeklendirin).
Hiçbir şeyi değiştirmeden yapabileceğiniz başka karşılaştırmalar da vardır:
- Uzak konumdan yerel veya yerel test - bu, ağın, gecikmenin, DNS'nin vb.
- Bunu zaten (bir şekilde) yaptınız ve çoğunlukla bir ağ sorununuz olmadığı sonucuna vardınız.
- Vernik (örn. Bağlantı noktası 80) vs nginx üzerinden doğrudan bağlantı noktası (bağlantı noktası 8080) - testler arasında yapılandırmanızı değiştirmemeye çalışın - sadece doğru bağlantı noktasını kullanın. Bu size Vernik'in etkisini gösterecektir. Vernik bir önbellek katmanı olduğundan, ilk istekten sonra tüm isteklere çok hızlı bir şekilde hizmet etmelidir - temel olarak, dinamik bir sayfa oluşturmak için gerekli olan arka ucu ve işlemi atlamalı ve önbelleğe alınmış kopyayı çok hızlı bir şekilde sunmalıdır.
- Bunu yaptınız (yerel olarak olmasa da) ve Verniğin performansınız üzerinde önemli bir olumlu etkisi olduğunu gösterdiniz.
Arka Uçunuzu Ayarlama
Bu noktada ya sorunu bulmuş olmanız ya da arka uçta yattığı sonucuna varmış olmalısınız. Bu size Nginx, PHP veya MySQL bırakır.
(Ben senin tıkanıklık CPU, RAM veya G / Ç olup olmadığını bilmek her zaman kullanışlı olduğunu, burada belirtmeliyim - arasına sar, top, iostat, vmstat, free., Vb bu konuda bazı sonuca gerekir)
nginx
Nginx sadece istek alıyor ve statik içerik sunuyor veya istekleri PHP-FPM'ye kaydırıyor - genellikle Nginx ile optimize edilecek çok şey yok.
- Set çalışanları = # CPU çekirdeği
- Kalıcılığı etkinleştir (10-15 değeri iyidir)
- Gereksiz günlük kaydını devre dışı bırak
- Gerekirse arabellek boyutlarını artırın
- İfadelerden kaçının (mümkünse normal ifadeler yerine statik adlar kullanın, gereksiz uzantıları kaldırın)
İdeal olarak, test blogunuz ve klonlanmış blogunuz aynı yapılandırmalara sahiptir, bu durumda Nginx'i sorun olarak etkili bir şekilde ortadan kaldırdınız.
Uygulama
Kodunuzdaki bir sorunu (örneğin, yavaş bir eklenti, vb.) Tanımlamaya çalışıyorsanız, yavaş günlükler başlangıç noktasıdır.
- MySQL yavaş günlüğünü etkinleştirin ve PHP-FPM yavaş günlüğü karşılaştırmanızı çalıştırın ve nelerin yavaş olduğunu görün.
MySQL
PHP
- gereksiz uzantıları devre dışı bırak,
- register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- memory_limit değerini artır
- open_basedir ve safe_mode'un önemli performans sonuçları vardır, ancak ek bir savunma katmanı da sağlayabilirler. Performans üzerindeki etkilerinin tolere edilebilir olup olmadığını belirlemek için onlarla ve onlarsız test edin.
PHP-FPM
- Pm. * Değerlerini ayarlayın - yüksek yük ile başa çıkmak için bunları artırın
Htop sonuçlarınızın php-fpm'yi CPU'nun büyük bölümünü tüketiyor olarak gösterdiğini ve sorunun doğrudan bununla ilişkili olduğu görülüyor.
Önbelleğe almak
Her olası darboğazı optimize ettikten sonra önbelleğe almaya başlayın.
- Zaten bir opCode önbelleğiniz (APC) var - çalıştığından emin olun (bir test dosyası ile birlikte gelir) - önbellek isabet oranlarınızı kontrol edin ve mümkünse disk yerine APC önbelleğine sahip olun.
- Kodunuzu önbelleğe ayarlayın (örneğin, Wordpress için W3TC gibi bir eklenti kullanarak)
- Nginx ile FastCGI önbelleğe almayı ayarlayabilirsiniz - ancak Varnish'e sahip olduğunuzdan, bu en iyi şekilde önlenir.
- Vernik (daha önce yapmış olduğunuz) gibi bir önbellek katmanı oluşturun ve çalıştığından emin olun (örn. Varnishstat kullanın, Yüksek bir Hit Hızı Elde Etme konusunu okuyun )
- Sitenizin bileşenleri için daha fazla önbellek ekleyin - örneğin, MemCached
Bazen, uygulamanızın ve donanımınızın sınırlamaları göz önüne alındığında, arka ucun kullanımını en aza indirgemek için arka uç performansını o kadar çok geliştiremeyebilirsiniz - ancak bu önbellekleme noktasıdır.
daha fazla okuma
if -fkullanma direktif ile ilgili bir şey olabilir düşünüyorumlocation. Burada okuduğum şeylere dayanarak wiki.nginx.org/Pitfalls ,-fdosya için verimsiz bir arama yaptığını hissediyorum, ilk zaman için bayt sorununa neden olabilir, özellikle çok sayıda dizinleri varsa Dosyalar.