Hayır iki site birbirine benzemez. Eğer gerçekten bir jmeter gibi araç ve sorun noktaları nerede olacağını görmek için kriter almak gerekir. Sen zamanında tahmin ve iyileştirilmesi çok fazla zaman harcamak, ancak ölçmek ve değişiklikleri karşılaştırmak kadar gerçek sonuçlar görmezsiniz.

Örneğin, uzun yıllar boyunca, MySQL sorgu önbellek performans tüm sorunları için çözüm oldu. Siteniz yavaş olsaydı, MySQL uzmanlar sorgu önbelleği dönüm önerdi. Bu yüksek bir yazma yükü varsa, önbellek aslında sakatlayıcı olduğunu çıkıyor. Eğer test olmadan açık varsa, asla bilemez.

Ve ölçeklendirme yapılır asla unutmayın. 10req / s kolları bir site 1000req / s destekleyen değişiklikler gerekecektir. 10.000 req / s desteklemesi gerekiyor yeterli Lucking eğer Ve, mimari belki de tamamen farklı olacak.

Databases

• Mysqli kullanmayınız - PDO 'modern' OO veritabanı erişim katmanı. Kullanmak için en önemli özelliği, sorgularda yer tutucuları. Bu sunucu tarafında hem de sizin için hazırlar ve diğer optimizasyonlar kullanmak için yeterince akıllı değil.
• Muhtemelen bu noktada veritabanı kırmak istemiyorum. Eğer bir veritabanı kesim olmadığını bulmak yaparsanız, sizin app bağlı büyütmek için çeşitli teknikler vardır. Daha fazla yazıyor okur varsa ek sunuculara kopyalayan genellikle iyi çalışır. Sharding birçok makine üzerinden veri bölmek için bir tekniktir.

Caching

• Muhtemelen veritabanında önbelleğe istemiyorum. Veritabanı genellikle tıkanıklık olduğunu, bu yüzden daha fazla GÇ ekleyerek genellikle kötü bir şeydir. APC ve Zend gibi benzer şeyler başarmak orada birkaç PHP önbelleklerini vardır.
• Ve kapalı önbelleğe alma ile sisteminizi ölçün. Ben önbellek düz sayfaları hizmet veren daha ağırdır bahis.
• Bu, db sizin yorumlarınızı ve makale veri oluşturmak sistem içine memcache entegre uzun zaman alırsa. Sen sorgu sonuçlarını önbelleğe ve memcached örneği saklayabilirsiniz. Bu memcache veri alınırken herhangi bir fayda görmek için veritabanından montaj daha hızlı olması gerektiğini hatırlamak önemlidir.
• Makaleler, dinamik değil, ya da oluşturulan oluyor sonra basit dinamik değişiklikleri varsa, diske html veya php dışarı yazma düşünün. Eğer varsa, o müşteri için akarsu, yazı için disk üzerinde görünen bir index.php sayfası olabilir. Değilse, bu madde oluşturur diske yazan ve istemciye gönderir. Diskten dosyaları silerek sayfaları yeniden yazılacak neden olur. Yorum bir makaleye ilave edilirse, önbelleğe alınmış kopyasını silmek - bu rejenere olur.

Re: PDO / MySQLi / MySQLND

@ gary

Sadece onlar farklı hedefleri var gibi "mysqli kullanmalısınız yok" diyemeyiz. PDO neredeyse bir soyutlama katmanı gibi (aslında olmasa da) ve MySQLi MySQL conections özgü ise kolay birden fazla veritabanı ürünlerini kullanmak yapmak için tasarlanmıştır. > Mysqli - - böyle değil> PDO beyanı ilerleme mysql olmuştur ima çünkü PDO MySQLi karşılaştırarak bağlamında modern bir erişim katmanı olduğunu söylemek yanlıştır.

MySQLi ve PDO arasındaki seçim basittir - Eğer birden fazla veritabanı ürünlerini desteklemek için gerekiyorsa o zaman PDO kullanabilirsiniz. Sadece MySQL kullanıyorsanız o PDO ve MySQLi arasında seçim yapabilirsiniz.

Peki neden PDO üzerinde MySQLi seçerdiniz? Aşağıya bakın ...

@ross

Sen ancak MySQLi için bir yedek değil, yeni MySQL çekirdek dil düzey bir kütüphane mysqlnd hakkında doğru. (PDO gibi) MySQLi size PHP kodu ile MySQL ile etkileşim olacaktır yolu kalır. Bunların her ikisi de PHP kodu arkasında C istemcisi olarak libmysql kullanın. Sorun şu ki libmysql çekirdek PHP motoru dışında olduğunu ve mysqlnd yani giriyor o bellek kullanımı söz konusu olduğunda, özellikle, verimliliği maksimize etmek için çekirdek PHP internals kullanan bir yerel Sürücüsü olmasıdır.

Mysqlnd MySQL kendileri tarafından geliştirilen ve son zamanlarda serbest bırakılması için hazır RC test, daha sonra bu yıl PHP 5.3 dalı üzerine indi. Daha sonra MySQLi ile mysqlnd kullanmak mümkün ... ama PDO ile olacaktır. Bu mysqli a performance boost birçok alanda (hepsi değil) verecek ve PDO yetenekleri gibi soyutlama gerekmez eğer MySQL etkileşim için en iyi seçim yapacak.

O dedi, mysqlnd is now available in PHP 5.3 PDO ve böylece PDO'ya ND performans geliştirmeleri avantajlar elde edebilirsiniz, ancak, PDO hala genel bir veritabanı katmanı olduğunu ve bu yüzden olacak unlikely to be able to benefit as much from the enhancements in ND as MySQLi can.

Some useful benchmarks can be found here Onlar 2006 den olmasına rağmen. Da this option gibi şeylerin farkında olmak gerekir.

MySQLi ve PDO arasında karar verirken dikkate alınması gereken hususlar bir yeri vardır. Bu gerçeklik bu isteği numaraları rediculously yüksek olsun ve bu durumda, bu şeyleri soyutlamaya ve MySQL sürücüsü sağlamak olur bir özel MySQL için dizayn edilmiştir uzantısı yerine birini kullanıyor olması daha mantıklı kadar önemli gitmiyor .

Her avantaj ve dezavantajları vardır çünkü iyi olduğu basit bir mesele değildir. Sen verdik bağlantıları okuyun ve kendi kararı ile gelip, daha sonra test ve öğrenmek gerekiyor. Ben geçmiş projelerde PDO'yu kullanmış ve iyi bir uzantısıdır ama saf performans için benim seçimim (PHP 5.3 yayınlandı) derlenmiş yeni mysqlnd seçeneği ile MySQLi olacaktır.

PHP tarafından desteklenen milyon / hit / ay almak bir kaç sitelerinde çalıştık MySQL. İşte bazı temel bilgiler şunlardır:

1. Önbellek, önbellek, önbellek. Caching web sunucunuza ve veritabanı yükü azaltmak için en basit ve en etkili yollarından biridir. Önbellek sayfa içeriği, sorgular, pahalı hesaplama, I / O bağlı olduğu bir şey. Memcache ölü basit ve etkilidir.
2. Eğer maxed kez birden çok sunucu kullanın. Sen (çoğaltma) ile birden çok web sunucuları ve çoklu veritabanı sunucuları var olabilir.
3. Lütfen webserverların istek genel # azaltın. Bu başlıkları sona kullanarak önbelleğe alma JS, CSS ve görüntüler gerektirir. Ayrıca kullanıcının deneyimini hızlandırmak hangi bir CDN için statik içerik taşıyabilirsiniz.
4. Tedbir & kriter. Üretim makineleri ve dev / qa sunucu üzerinde yük testi nagios çalıştırın. Sen bunu önlemek böylece sunucu ateşe yakalamak ne zaman bilmek gerekir.

I Building Scalable Websites, bu Flickr mühendislerinden biri tarafından yazılmış ve büyük bir referans oldu okumanızı tavsiye ederim.

Check out my blog post about scalability too, it has a lot of links to presentations about scaling with multiple languages and platforms: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

Ben 15M fazla kullanıcı ile bir sitede bir kurşun geliştirici değilim. Biz ERKEN bunun için planlı ve düşünceli ölçekli çünkü biz çok az ölçeklendirme sorunları vardı. İşte benim deneyimlerinden önerebilirsiniz stratejileri vardır.

SCHEMA First off, denormalize your schemas. This means that rather than to have multiple relational tables, you should instead opt to have one big table. In general, joins are a waste of precious DB resources because doing multiple prepares and collation burns disk I/O's. Avoid them when you can.

Burada ticaret-off gereksiz veri çekerek / depolama olacaktır olduğunu, ancak veri ve intra-kafes bant çoklu hazırlamak I / O (daha fazla sunucu) büyüklük emir daha pahalı ise (daha büyük diskler) çok ucuz olduğu için bu kabul edilebilir .

INDEXING Make sure that your queries utilize at least one index. Beware though, that indexes will cost you if you write or update frequently. There are some experimental tricks to avoid this.

Sen endekslidir sütunlarınıza paralel endeksli olmayan ek sütunlar eklemeyi deneyebilirsiniz. Sonra gruplar halinde endeksli sütun üzerinde olmayan endeksli sütunları yazar çevrimdışı bir süreç olabilir. MySQL endeksi recompute gerekecektir Bu şekilde, daha iyi kontrol edebilir.

Bir veba gibi bilgisayarlı sorguları kaçının. Bir sorgu hesaplamak gerekir, yazma zamanda bir kez yapmaya çalışın.

CACHING I highly recommend Memcached. It has been proven by the biggest players on the PHP stack (Facebook) and is very flexible. There are two methods to doing this, one is caching in your DB layer, the other is caching in your business logic layer.

DB katman seçeneği DB alınan sorgu sonucunu önbelleğe alma gerektirir. Sen md5 (kullanarak SQL sorgusu karma) ve veritabanına gitmeden önce bir arama anahtar olarak kullanabiliriz. Buna ters bunu uygulamak oldukça kolay olmasıdır. (Uygulamaya bağlı) olumsuz önbellek sona ermesi ile ilgili tüm önbelleklemeyi aynı davranıyorlar çünkü esneklik kaybetmek olduğunu.

Ben çalışmak dükkanda, bizim sistemde her beton sınıfı kendi önbelleğe şema ve önbellek zaman aşımı kontrol anlamına gelir iş katmanı önbelleğe kullanın. Bu bizim için oldukça iyi çalıştı, ama DB alınan ürün önbellek öğeleri olarak aynı olmayabilir unutmayın, bu yüzden birlikte önbelleği ve DB güncellemek zorunda kalır gelmiştir.

DATA SHARDING Replication only gets you so far. Sooner than you expect, your writes will become a bottleneck. To compensate, make sure to support data sharding early as possible. You will likely want to shoot yourself later if you don't.

Bu uygulamak oldukça basittir. Temel olarak, veri depolama anahtar yetki ayırmak istiyorum. Birincil anahtarlar ve küme kimlikleri arasında bir eşleme depolamak için bir küresel DB kullanın. Bir küme almak için bu eşlemeyi sorgulamak ve daha sonra verileri almak için küme sorgulayabilirsiniz. Bunu önemsiz işlemi yapacak olan bu arama işlemi defol önbelleğe alabilir.

Bunun dezavantajı birden fazla kırıkları gelen verileri bir araya getirmek zor olabilir olmasıdır. Ama, siz de bu yolunuzu mühendis olabilir.

OFFLINE PROCESSING Don't make the user wait for your backend if they don't have to. Build a job queue and move any processing that you can offline, doing it separate from the user's request.

General

• Eğer gerçek dünya yük görmeye başlamadan önce optimize kalkmayın. Eğer doğru tahmin olabilir, ama bunu yapmazsanız, size zaman kaybettim.
• jmeter, xdebug ya da kriter için başka bir araç sitesi kullanın.
• Yük bir sorun olmaya başlarsa, nesne veya veri önbelleğe ya olasılıkla dahil olacak, bu yüzden genellikle önbelleğe alma seçenekleri (memcached, MySQL önbelleğe alma seçenekleri) kadar okuyun

Code

• Darboğaz nerede olduğunu biliyor, böylece kod profil ve kodu veya veritabanı olsun

Databases

• Kullan MYSQLi diğer veritabanları için taşınabilirlik önemli değilse, PDO, aksi
• Kriterler veritabanı sorunu ortaya Eğer önbelleğe başlamadan önce, sorguları kontrol edin. Lütfen sorguları yavaşlatan nerede EXPLAIN görmek için kullanın.
• Sorguları optimize edilmiş ve veritabanı bir şekilde önbelleğe sonra, birden çok veritabanı kullanmak isteyebilirsiniz. (Birden fazla veritabanı / sunucular üzerinden verilerini bölerek) birden fazla sunucuya veya Sharding çoğaltılmasını ya verilere bağlı olarak, uygun olabilir, sorgular, ve okuma / yazma davranış türüdür.

Caching

• Yazma Bol önbelleğe alma kodu, nesneler ve veri üzerinde yapılmıştır. APC, Zend Optimizer, memcached, QuickCache, JPCache ile ilgili makaleler bakmak. Eğer gerçekten gereken önce bu bazı yapın ve unoptimized başlama konusunda daha az endişe olacak.
• APC ve Zend Optimizer onlar yeniden çözümleme ve kod recompilation kaçınarak PHP kodu hızlandırmak, kodu önbelleklerini vardır. Genellikle, yüklemek için basit erken yapmaya değer.
• Memcached Eğer önbellek sorgu PHP fonksiyonları ya da nesneler, ya da tüm sayfalara kullanabilirsiniz, bir genel önbellek. Kod özellikle oluşturma, güncelleme ve önbelleğe alınan nesnelerin silinmesini işlemek için hiçbir merkezi noktaları vardır eğer bir yer süreçtir olabilir ki, bunu kullanmak için yazılmış olmalıdır.
• QuickCache ve JPCache, Memcached aksi takdirde benzer dosya önbelleklerini vardır. Temel kavram basit, ama aynı zamanda bir kod gerektirir ve oluşturma, güncelleme ve silme merkezi noktaları ile daha kolaydır.

Miscellaneous

• Yüksek yük için alternatif web sunucularını düşünün. lighthttp ve nginx Apache daha az bellek trafik büyük miktarda işleyebilir gibi sunucular, Apache'nin gücü ve esnekliği (veya sadece don eğer kurban eğer 't sık sık, yok böyle şeyler,) gerekir.
• Bu donanım bu gün şaşırtıcı derecede ucuz olduğunu unutmayın, bu yüzden karşı kod büyük bir blok optimize etmek için çaba dışarı mal emin olun "adlı bir canavar sunucu ısmarlayayım."
• Bu soruya "MySQL" ve "ölçekleme" etiketleri ekleyerek düşünün

APC mutlak bir zorunluluktur. Büyük bir önbellek sistemi için yapmak, ancak otomatik olarak önbelleğe PHP dosyaları kazanç bir nimettir kalmaz. Birden çok veritabanı fikrine gelince, ben size aynı sunucuda farklı veritabanları olan çok çıkmak olacağını sanmıyorum. Bu size sorgu süresinde hız kazancı biraz verebilir, ama buna değer olacağını onlar senkronize olduğundan emin yaparken her üçü için kod dağıtmak ve korumak için alacağını çaba şüpheliyim.

Ben de çok Xdebug programınızda darboğazları bulmak için çalışan öneriyoruz. Bu optimizasyonu benim için bir esinti yaptı.

Öncelikle, ben düşünüyorum Knuth "Prematüre optimizasyonu tüm kötülüklerin köküdür" dedi. Şu anda bu sorunları ile uğraşmak zorunda değilsiniz o zaman, ilk düzgün çalışan bir şey sunmaya odaklanmak değil. Optimizasyonlar sabırsızlanıyorum eğer, söyleniyor.

Veritabanı sorguları profilleme çalışın, yavaş anlamaya ve çok ne ve bu bir optimizasyon stratejisi ile geldi.

Bu yüksek yük sitelerinde bir sürü verimli her türlü içeriği önbelleğe alma için kullanmak ne gibi Memcached araştırmak olur, ve buna PHP nesne arayüzü oldukça güzel.

Yarma kadar sunucular arasında veri tabanları ve (örneğin gerekli verileri ile 1 ve # gereksiz veritabanları arasında rastgele bir sayı üretmek - ve hangi veritabanı sunucusu bağlanmak için belirlemek için bu numarayı kullanmak) yük dengeleme tekniği çeşit kullanarak da artırmak için mükemmel bir yol olabilir verimlilik.

Bunlar bazı oldukça yüksek yük siteleri için geçmişte oldukça iyi çalıştı var. Bu size :-) başlamanıza yardımcı olur umarım

Xdebug gibi bir şey (gibi tj9991 önerilir) ile app profilleme kesinlikle bir zorunluluk olacak. Bu anlamda bir sürü sadece körü körüne şeyler optimize dolaşmak için yapmaz. Xdebug akıllıca optimizasyon vakit geçirmek ve aslında yavaş çıkışlar neden olan kod parçalarını düzeltmek böylece kodunuzda gerçek darboğazları bulmanıza yardımcı olacaktır.

Apache, test yardımcı olabilir başka bir programı kullanarak ediyorsanız olan Siege. Bu sizin sunucu ve uygulama gerçekten onun adım aracılığıyla koyarak yüksek yüke nasıl tepki vereceğini tahmin yardımcı olacaktır.

(APC veya diğerleri gibi) PHP opcode önbellek her türlü yanı sıra çok yardımcı olacaktır.

Ben 7-8 milyon sayfa ile bir web sitesi bir ay views çalıştırın. Korkunç çok, ama yeterli bizim sunucu yükünü hissettim. Yok Veritabanı düzeyinde Memcache: seçtik çözüm basitti. Veritabanı yük ana sorun ise bu çözüm iyi çalışır.

Biz tüm nesneleri ve en sık kullanılan veritabanı sonuçları önbelleğe Memcache kullanarak başladı. Bu iş yaptım, ama aynı zamanda (daha dikkatli olsaydı biz bu bazı kaçınabilirlerdi) hataları tanıttı.

Yani bizim yaklaşımı değişti. Biz bir veritabanı sarıcı inşa (bizim eski veritabanı olarak aynı yöntemlerle, bu yüzden geçiş kolay oldu), ve daha sonra biz memcached veritabanı erişim yöntemleri sağlamak için sınıflandırma.

Şimdi tüm yapmanız gereken bir sorgu önbelleğe kullanmak (ve muhtemelen güncel) sonuçları veya olup olmadığını belirlemek. Kullanıcılar tarafından çalıştırılan sorguları çoğu şimdi Memcache doğrudan getirilen edilmektedir. Istisnalar güncellemeleri ve ana web sitesi için sadece nedeniyle günlüğü olur ekler vardır. Bu oldukça basit önlem yaklaşık% 80 oranında bizim sunucu yükünü azalttı.

PHP'nin önbelleğe alma uzantıları tavsiye için teşekkürler - başka bir yere birini kullanarak nedenlerini açıklayabilir? Ben IRC üzerinden memcached hakkında harika şeyler duydum ama APC duymadım - onlara görüşleriniz nelerdir? Birden fazla önbelleğe alma sistemlerini kullanarak oldukça karşı etkili olduğunu varsayalım.

Aslında, many do use APC and memcached together ...

Bu I was wrong gibi görünüyor. MySQLi hala geliştirilmektedir. Fakat makaleye göre, PDO_MYSQL şimdi MySQL ekibi tarafından katkıda ediliyor. Makalesinden:

The MySQL Improved Extension - mysqli - is the flagship. It supports all features of the MySQL Server including Charsets, Prepared Statements and Stored Procedures. The driver offers a hybrid API: you can use a procedural or object-oriented programming style based on your preference. mysqli comes with PHP 5 and up. Note that the End of life for PHP 4 is 2008-08-08.

The PHP Data Objects (PDO) are a database access abstraction layer. PDO allows you to use the same API calls for various databases. PDO does not offer any degree of SQL abstraction. PDO_MYSQL is a MySQL driver for PDO. PDO_MYSQL comes with PHP 5. As of PHP 5.3 MySQL developers actively contribute to it. The PDO benefit of a unified API comes at the price that MySQL specific features, for example multiple statements, are not fully supported through the unified API.

Please stop using the first MySQL driver for PHP ever published: ext/mysql. Since the introduction of the MySQL Improved Extension - mysqli - in 2004 with PHP 5 there is no reason to still use the oldest driver around. ext/mysql does not support Charsets, Prepared Statements and Stored Procedures. It is limited to the feature set of MySQL 4.0. Note that the Extended Support for MySQL 4.0 ends at 2008-12-31. Don't limit yourself to the feature set of such old software! Upgrade to mysqli, see also Converting_to_MySQLi. mysql is in maintenance only mode from our point of view.

To me, it seems the article is biased towards MySQLi. I suppose I'm biased towards PDO. I really like PDO over MySQLi. It's straight forward to me. The API is a lot closer to other languages I've programmed in. OO Database interfaces seem to work better.

Ben PDO aracılığıyla mevcut değildi herhangi bir spesifik MySQL özellikleri rastlamak değil. Şimdiye kadar olsaydı sürpriz olurdu.

Bu değer ne için, önbelleğe alma hatta memcached gibi bir uzantısı / yardımcı paketi olmadan PHP DIRT BASİT.

Yapmanız gereken tüm () ob_start kullanarak bir çıkış tampon oluşturmak olduğunu.

Bir küresel önbellek işlevi oluşturun. Bir geri olarak işlev geçmek, ob_start diyoruz. Fonksiyonu, sayfanın önbelleğe alınmış bir sürümü için bakın. Varsa, bu hizmet ve biter.

O yoksa, komut işleme devam edecektir. Bu eşleştirme ob_end ulaştığında () belirttiğiniz işlevini çağırır. O zaman, sadece, çıkış tamponunun içeriğini almak bir dosya bunları bırakın, dosyayı kaydedin ve sonu.

Bazı erme / çöp toplama ekleyin.

Ve birçok kişi iç içe ob_start () / ob_end () çağrıları fark yoktur. Yani zaten, diyelim ki, sadece yuva başka ob_start / ob_end arama yapabilirsiniz, dizim ya da her neyse reklamlarda ayrıştırmak ya da yapmak için bir çıkış tamponu kullanılarak eğer.

PDO de çok yavaş ve onun API oldukça karmaşıktır. Taşınabilirliği bir endişe değil eğer onların aklı başında aklı başında hiç kimse bunu kullanmak gerekir. Ve en değil tüm webapps% 99, bunu kabul edelim. Sadece MySQL veya PostrgreSQL sopa ile, ya da birlikte çalıştığınız ne olursa olsun.

PHP sorusuna ise ve ne dikkate almak. Ben erken optimizasyonu tüm kötülüklerin kökü olduğunu düşünüyorum. Uygulama ilk yapılması alın ;) biraz dokümantasyon yapmak ve birim testleri yazmak, o programlama gelince temiz tutmaya çalışın. Yukarıdaki tüm ile zamanı geldiğinde kod üstlenmeden hiçbir sorunları olacaktır. Ama önce yapılmasını istediğinizi ve insanların buna nasıl tepki görmek için dışarı itin.

Tabii pdo güzel, ama artık sabit gibi görünüyor olsa da bu konuda var has been some tartışma, mysql ve mysqli'nin karşı performansları.

Eğer taşınabilirlik öngörülüyor eğer PDO kullanmanız gerekir, ama değilse, mysqli şekilde olmalıdır. Bu bir OO arayüze sahip, tablolar hazırlanmış, ve (iyi, taşınabilirlik, hariç) teklif pdo ne çoğu.

Ayrıca, performans gerçekten gerekli ise, (yerli mysql) çok daha sıkı daha iyi bir performans ile, php ile entegre ve performans ayarlama için geliştirilmiş bellek kullanımı (ve istatistik olacak PHP 5.3 'te MysqLnd sürücü için hazırlamak .)

Memcache güzel Sunucuları (ve YouTube gibi yük) kümelenmiş, ama ben ilk çok APC denemek istiyorum eğer.

Iyi yanıtlar bir sürü zaten verildi, ama ben XCache adında alternatif bir opcode önbellek size işaret etmek istiyorum. Bir lighty katılımcı tarafından oluşturulur.

Gelecekte veritabanı sunucusu yük dengeleme gerekebilir Ayrıca, eğer, MySQL Proxy çok iyi bunu başarmak için size yardımcı olabilir.

Bu araçların her ikisi de oldukça kolay olan bir uygulama içine fiş gerekir, böylece ihtiyacınız olduğunda bu optimizasyon çok fazla uğraşmadan, yapılabilir.

İlk soru gerçekten olması için ne kadar büyük bekliyorsunuz nedir? Ve siz altyapı yatırım ne kadar planlıyoruz. Burada soru sormak için ihtiyacı hissediyorum beri, sınırlı bir bütçe üzerinde küçük başlamak için beklediklerini tahmin ediyorum.

Site mevcut değilse performans ilgisizdir. Ve kullanılabilirlik için yatay ölçeklendirme gerekir. Eğer mantıklı paçayı en az 2 sunucuları, çalışan apache, php ve mysql hem de. Diğer bir köle gibi bir DBMS ayarlayın. Kalıptaki tüm yazma işlemleri yapmak, ve tüm (ne olursa olsun) yerel veritabanı okur - sürece sen sadece (kullanım efendi) okudum geri veri okumak gerekir nedense. Eğer otomatik olarak köle ve çit ana teşvik etmek yerine makine var emin olun. Köle düğüm için daha fazla afinite vermek için web sunucusu adresleri için round-robin DNS kullanın.

Bu aşamada farklı veritabanı düğümler arasında veri bölümleme çok kötü bir fikir - Eğer aynı sunucuda (Eğer facebook sollamak zaman düğümleri arasında bölümleme kolaylaştıracak olan) farklı veri tabanları arasında bölme düşünebilirsiniz ancak.

Eğer site performansını ölçmek ve darboğazları tespit etmek yerinde izleme ve veri analiz araçları var emin olun etmeyin. Çoğu performans sorunları veritabanı şemasını sabitleme / iyi SQL yazarak sabit olabilir.

Veritabanında şablon önbelleğini tutulması aptalca bir fikir - veritabanı için yapılandırılmış veri merkezi ortak bir depo olmalıdır. Lütfen webserver'lerin yerel dosya üzerinde şablon önbellek tutun - daha hızlı mevcut olacak ve veritabanı erişimi yavaşlatmak değildir.

Bir op-kod önbelleği kullanmak etmeyin.

Onun kadar yavaş gidiyor anlamak için sitenizi ve günlükleri okuyan bol zaman geçirin.

Istemci üzerine mümkün olduğunca önbelleğe itin.

Eğer her şeyi sıkıştırmak için mod_gzip kullanın.

C.

Tavsiye benim ilk parçası bu konuda düşünmek ve site tasarımı akılda tutmak için ama don't go overboard. Bu yeni sitenin başarısını tahmin etmek genellikle zordur ve ben zaman daha erken bitmiş kalkarken ve daha sonra optimize harcanacak.

In general, Simple is fast. Templates slow you down. Databases slow you down. Complex libraries slow you down. Layering templates over each other retrieving them from databases and parsing it in a complex library --> the time delays multiply with each other.

Eğer temel site up var ve çalışıyor do tests nerede çaba harcamak için size göstermek için bir kez. Nerede hedef görmek zordur. Genellikle kodun karmaşıklığı çözmek zorunda olacak şeyleri hızlandırmak için sadece gerekli yapmak istiyorum yani, bu, daha büyük ve korumak için daha zor hale getirir.

Benim durumumda veritabanı bağlantısını kurmak nispeten pahalı. Onunla uzak alabilirsiniz varsa, site ön sayfa gibi en trafficed sayfalarında genel ziyaretçiler için veritabanına bağlanmak gerekmez. Birden çok veritabanı bağlantıları oluşturmak çok az fayda ile delilik.

@ Gary

Mysqli kullanmayınız - PDO 'modern' OO veritabanı erişim katmanı. Kullanmak için en önemli özelliği, sorgularda yer tutucuları. Bu sunucu tarafında hem de sizin için hazırlar ve diğer optimizasyonlar kullanmak için yeterince akıllı değil.

Ben şu anda PDO üzerinde loking ve sen haklısın gibi görünüyor - ancak ben MySQL PHP mysqld uzantısı gelişmekte olduğunu biliyorum - Ben MySQL veya mysqli ya başarılı olmak için düşünüyorum - bu konuda ne düşünüyorsunuz?

@ Ryan, Eric, tj9991

PHP'nin önbelleğe alma uzantıları tavsiye için teşekkürler - başka bir yere birini kullanarak nedenlerini açıklayabilir? Ben IRC üzerinden memcached hakkında harika şeyler duydum ama APC duymadım - onlara görüşleriniz nelerdir? Birden fazla önbelleğe alma sistemlerini kullanarak oldukça karşı etkili olduğunu varsayalım.

Ben kesinlikle bazı profilleme test sıralama olacak - bu sizin önerileri için çok teşekkür ederim.

Kendimi yakın zamanda MySQL geçiş görmüyorum - bu yüzden ben PDO soyutlama yetenekleri gerek yok sanırım. Bu makaleleri DavidM için teşekkürler, bana çok yardımcı oldunuz.

ASP.NET 'te çıktı önbelleği simillar Apache web sunucusu için mod_cache, bir çıkış önbellek içine bak.

Evet, ben hala deneysel olduğunu görebilirsiniz ama son gün olacak.

Modülarizasyon ve Soyutlama: Hiç kimse zaten bu sözü inanamıyorum. Eğer site must, tasarım, makinelerin sürü büyümek zorunda olduğunu düşünüyorsanız bu yüzden olabilir! Böyle aptalca şeyler veritabanı localhost olduğunu varsaymak anlamına gelir. Ayrıca bir veritabanı soyutlama katmanı yazma gibi, ilk başta rahatsız olacak (PDO gibi, ama sadece bunu yapmak için gereken ne yapar, çünkü çok hafif çok) şeyleri ifade eder.

Ve bir çerçeve ile çalışmak gibi şeyler demektir. and the code doesn't have to know or care - Daha sonra bazı nesneler farklı bir veritabanında olduğu öğretilerek, örneğin, veri soyutlama katmanı üstlenmeden performansı elde edebilirsiniz böylece kodunuzu katmanları gerekir.

Son olarak, örneğin, gereksiz dize kopyalama bellek yoğun operasyonların dikkatli olun. PHP'nin bellek kullanımını tutabilirsek, o zaman sunucunuzun daha fazla performans alacak ve bu bir yük dengeli çözüm gittiğinizde dönüşebilecek bir şeydir.

Eğer büyük miktarda veri ile çalışıyorsanız ve önbelleğe alma Sfenks içine bakmak, bu kesim değil. Biz daha iyi bir metin arama için SphinxSearch değil sadece kullanarak mükemmel sonuçlar vardı, ama aynı zamanda MySQL için bir veri alma yerine büyük tablo uğraşırken ettik. Eğer SphinxSE (MySQL eklentisi) kullanırsanız, biz birkaç kez önbelleğe vardı bizim performans artışı aştı ve uygulama uygulanması sinch olduğunu.

Önbellek hakkında yapılan noktaları yer-üstünde; verimli bir uygulama binanın en karmaşık ve en önemli parçasıdır. Ben memcached büyük ise uygulama tek bir sunucu üzerinde yaşıyorsa, APC yaklaşık beş kat daha hızlı olduğunu eklemek istiyorum.

MySQL performans blog "Cache Performans Karşılaştırması" sonrası konuyla ilgili bazı ilginç kriterler var - http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/.