LAMP Sunucusu Performans İpuçları [kapalı]


11

LAMP sunucusu çalıştıran birine hangi performans ipuçları sunulabilir?

Dağıtımın belirli bir şey olması durumunda Debian'ı hedefliyorum.

Yanıtlar:


26

Bu gerçekten iş yükünüze bağlıdır.

  • için L parçası

    • çok fazla bellek al,
    • 4GB'ın üzerine çıkabiliyorsanız 64bit'e gidin.
    • içeriğinizin, günlüklerinizin ve MySQL verilerinizin bulunduğu bölümler için bağlama seçenekleri kullanın: noatime, nodiratime.
    • ayrı fiziksel sürücüler / raid kümeleri kullanın, ideal olarak SQL verilerini, günlükleri ve sunduğunuz içeriği her biri ayrı iş milinde tutun.
  • için bir destenizin parçası - iyi belki tamamen değiştirmek istiyor nginx veya LightHTTPD sadece dinamik içerik için Apache terk belki ya ve (bu iki ya da benzeri ayrı sunucu var mathopd statik içerik için). Bir göz atın burada daha fazla seçenek için. Hem Apache'yi hem de başka bir sunucuyu aynı kutuda çalıştıracaksanız, 2. bir IP adresi kullanışlı olacaktır. Son kullanıcının gecikmesini azaltmak için, http://deve-alive kullanın. Statik içerik için bir CDN kullanmayı düşünün.

  • için M lambanla parçası - bakabilirsiniz mysqlperformanceblog . başımın üstünden:

    • yavaş sorguları günlüğe kaydet,
    • yeterli hafıza ver,
    • innodb kullanmayı düşünün.
    • arasında arama yapmak için çok fazla metin varsa - sfenks kullanın ve dizini yeniden oluşturan bir toplu işiniz olsun.
    • XYZ saniyeden daha uzun süre çalışan sorguları öldürmeyi düşünün. Kullanıcıların% 1'ini üzmek, tüm siteyi en yoğun zamanda azaltmaktan daha iyidir. Ancak bu, nakit işlemlerinizi gerçekleştirmenize veya güzel resimler göstermenize bağlıdır.
    • daha pahalı SQL sorgularının sonuçlarını önbelleğe almak için mümkünse memcached kullanın. SQL içeriğini değiştirdiğinizde önbelleği geçersiz kılmayı unutmayın. Öte yandan, tüm verilerin belleğe rahatça sığdığı çok az sitem var ve bunun için MySQL hızlı yanıp sönüyor ve ek önbelleğe gerek yok.
  • için P

    • komut dosyaları için yürütme zaman aşımını ayarlayın.
    • bazı PHP hızlandırıcı / opcode önbellek kullanmayı düşünün . Xcache'den oldukça memnun kaldım , ama şimdi kullanmıyorum.
    • CPU yoğun işlemeniz varsa - sonuçları önbelleğe alın ve bunları SQL'de saklayın veya memcached yapın

Gerçekten bir performans ipucu değil, ancak site dışı yedeklemeler yapın. Gerçekten mi.


1
Bunu ekleyebilirsem, son zamanlarda amazon s3 ile itme ve çekme stratejileri ile güvenli yedeklemeler hakkında blog yazdım. banka verileri için uygun değildir, ancak amzon'a güveneceğiniz her şeyin iyi olması gerekir. logaholic.de/2009/05/21/…
Karsten

Aslında yorum yapmadan önce blog gönderisini fark ettim; -]. yine de güzel bir tane. daha güvenli hale getirmek için yedeklemenizi her zaman şifreleyebilirsiniz.
pQd

3

Gerçekten iki farklı makinede MySQL ve Apache / PHP'yi ayırmanızı öneririm.

Örneğin, her zaman 2.0 ve daha yüksek yük ortalamasına yükselen bir makinem (C2D E6600) vardı. MySQL'i ikinci bir makineye (P4C 3Ghz) koydum ve bundan sonra her iki yük ortalaması da 0.2-0.3'ün üzerine çıkmadı. Bu yüzden çok yavaş bir siteden çok sayıda performans marjına sahip iki sunucuyla hızlı bir siteye gittim.


iyi bir nokta. sadece darboğazınızın IO alt sistemi / sürücü duyarlılığı olabileceğini tahmin edebilirim. belki daha sonra iki farklı sürücüdeki verileri ayırmak / ince disk denetleyicisine sahip olmak hile yapabilir. neyse daha fazla bellek ve daha fazla cpus her zaman iyidir, ama o zaman daha fazla başarısızlık noktası elde edersiniz.
pQd

Çoğu (% 90 diyelim) SQL isabetleri önbelleğe alındı ​​çünkü disk I / O'olduğundan emin değilim. CPU bağlam anahtarları hakkında düşünüyordum ama bunun gerçekten önemli bir rol oynayabileceğini bilmiyorum.
Antoine Benkemoun

1

P kısmı için, APC ile opcode önbelleklemeyi düşünebilirsiniz . Bir de varsayılan mod_php yerine php ile mod_fastcgi düşünülebilir .


EAccelerator'ı gerçekten seviyorum. Sitelerim için en iyi performansı verir.
TheHippo
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.