Bu gerçekten (db) sunucularının kurulum bağlıdır. Mümkün olduğunca bilgilerin çoğu önbelleğe ve en az db aramaları azaltmak için deneyin. Sitenizin kullanımı yüksek - Bir veritabanı (hemen hemen her durumda) hizmet darboğaz olacaktır. Yani ne olursa olsun gerçekten gerekli değil sanki bir sorgu fireing önlemek için deneyin.

Ben sayfa başına en fazla 10 db çağrıları kullanmamaya çalışın, ama bu gerçekten altyapı ve sağlamak istediğiniz bilgilere bağlıdır.

Ben sunucu yüküne bağlıdır söyleyebilirim. Dakika başına 1 ziyaretçi varsa, o zaman sayfa başına 1-10 db aramalar sadece iyi olurdu. Sunucu yük daha yüksek ise, saniyede 10 sayfa istekleri, o zaman db sunucu üzerindeki yükünü en aza indirmek için önbelleğe almayı düşünmelisiniz söylüyorlar.

Ben. Com patlaması www.boxman.com proje üzerinde çalışırken, farklı etki altında 9 farklı dil / ülke siteleri gibi göründü bir web sitesi vardı. Metin her parçası DB gibi vb ürünleri gibi olağan şeyler çekildi .. Her sayfası genellikle 200 küsur DB isteklerini içerecektir, ama esas olarak bir tek id, string combo dönen. Biz bir anda sistemdeki kullanıcıların 100 vardı.

DB 16 yolu RS6000 unix DB2 SQL koştu. Bu muhtemelen bir modern 3ghz DÖRTLÜ çekirdek intel kutusuna equivient edilir.

Hacimleri Ben artık DB hit çok web sunucusu sürücüye günlük bazda statik oldu verilerin taşınmasını senkronizasyon süreci yazma katılan bir önbellek uygulamaya aldı olarak sistem ... çalıştı.

Performans tamam ise Temelde ben o zaman tamam söyleyebilirim! ancak talebin genişletilmesi için izin ve ne zaman olur bunun için hazır olmalıdır.

Bir parça ipin ne kadardır? Bir adamın bacakları ne kadar olmalıdır? Eğer bir sayfa yük kaç DB sorgu yapmak gerekir?

Tek bir cevap yoktur. Açıkçası, gereksiz sorguları yapmak kötü bir fikirdir. Aşırı DB bağlantılarını başlayarak daha da kötüdür. Değişmeyen değerleri önbelleğe iyidir. Bunu yapmak için çalışıyoruz ne bağlıdır ve - Bunun ötesinde, gerçekten keyfi bir sayfada "Sadece $ N sorgular kullanmak gerekir" diyemeyiz performans hedefleri ne vardır.

Teorik olarak, herhangi bir uygulama tek bir DB sorgusu kullanmak için yazılmış olabilir - bu sorgu büyük bir 20-yönlü Sıralanmayan full tablo taramaları içeren katılmak ve çoğunlukla bellek ve zaman gülünç kestirmeniz alacağını nulls olduğu satır binlerce dönüş olsa bile Bu uygulama için alır sonra işlemek. Açıkçası, bu çok kötü bir şey olurdu. Genel olarak, (bir döngü içinde tek satır sorgu bir demet yapıyor gibi) açıkça savurgan ve daha sonra performansı hakkında endişe şeyler yapıyor önlemek.

Donald Knuth sözleriyle "Biz küçük verimliliği hakkında unutmak gerektiğini, zaman yaklaşık% 97 söylüyor: Prematüre optimizasyonu tüm kötülüklerin köküdür." Twitter muhtemelen ilk kapı dışarı bir ürün kazanılmış olurdu asla, şimdi olduğu kadar büyük olmasına odaklanmış olsaydı onlar gerçekten, gerçekte, sonraki heyecan olacak ama konum gibi herkes 'ölçeklenebilirlik' bahsediyor yer.

Bu sonuçta kullanıcı beklediği deneyim bağlı sonuna kadar gidiyor. Bu sayfada göstermek için kapsamlı veri bekliyoruz, 1). Sitesi ne miktarda veri db çekiliyor verilen, yük altında hareket edebilmek ve 2 olacak bazı beklenti olması zorunludur.) sayfa yüklenirken zaman-maliyet, genel sunucu yükü üzerine söz konusu sayfa için veri yüke bağlı olacak, ve değildir.

Db aramaları kabul edilebilir bir sayıdır ne büyük bir savunucusu, hem de altta yatan db tasarım olmalıdır. Düzenli nedeniyle sadece altta yatan db yapının karmaşıklığı, yukarı (uncached) sayfa başına yükü aramaların 100'ler yapmak orada kurumsal sınıf e-ticaret siteleri vardır.

Genel olarak, db aramaları bakmak için iyi bir yoldur yükleme süresi ve işlemci ve bellek kullanımını optimize etmek için stratejiler orada bakmak zaman kabul edilebilir bir miktarda, belirli bir sayfa yükler ve gelen olup olmadığını belirlemektir.

Önbelleğe alma dışında bir başka önemli konu hazırlanmış deyimleri kullanmaktır. Eğer bir sorgu çalıştırdığınızda, db 1) sorgu analiz ve 2) çalıştırmak zorundadır. Eğer hazır deyimleri kullanıyorsanız, db son kez kullanılan sorgu planı önbelleğe alabilir, böylece her sorgu DBMS üzerinde küçük bir yük olacaktır. Eğer yürütmek kaç sorgular yük saymak, ancak dbms koymak ne kadar stres yapmayın. 100 hazırlanan sorguları yürütme kodu reklam-hoc oluşturulan 50 sorguları yürütme daha hızlı olabilir.

100,000 sayfa isteklerini hatırlıyorum 24 saat boyunca sadece sadece 1 üzerinde bir ikinci. Sürece tek seferde talep yok gibi.

Don't forget

1. depolanan procs kullanımı - hızlı çalıştırmak.
2. Taze onları çalıştırmak - Haftada bir kez. (Veritabanı mevcut durumunu kullanarak saklı procs optimize., Bu daha sonra depolama işlemi optimial olmaktan çıkacak değiştirirse).
3. Gerçekten SP'leri ne yaptığını anlamak için "show planı" gibi komutları kullanabilirsiniz.
4. Saklanan kaçırmamasını bu ağ trafiği keser birden fazla veri setleri (datatables) dönebilirsiniz. Tek bir saklı yordam birden fazla şeyler yapabilirsiniz.

Tony

Bir ya da daha az zaman en iyisidir. İki genellikle çok biridir.

Eğer tek bir sorguda birden çok sonuç kümeleri döndüren, sonra bunu. Bilgi oldukça statik ise, o zaman önbelleğe ve önbellek çekin.

10 ayrı veritabanı çağrıları iyi değil, ama onun düşük kullanım siteyi öldürecek değil.