Bunun diğer bir güzel örneği CPU’larla ilgili dengedir. Çoğu durumda MySQL hızlı CPU’larla güzel çalışacaktır çünkü her bir sorgu tek bir izlekte (thread) çalışır ve CPU’lar arasında paralel yürütülemez.
Sıra problem çözümüne geldiğinde tüm dört kaynağın performans ve kullanımını dikkatli bir biçimde kontrol edin; performansları zayıf mı ya da çok fazla iş yapması mı isteniyor? Bu bilgi problemlerin hızlıca çözülmesine yardımcı olabilir.
MySQL performans ipuçları No. 3: MySQL’i bir kuyruk olarak kullanmayın
Kuyruklar ve kuyruk benzeri erişim kalıpları siz farkında olmadan uygulamanızın içine gizlice sızabilir. Örneğin, bir nesnenin durumunu öyle ayarladınız ki belirli bir çalışan süreci onu kullanabilmeden önce talep giriyor; işte siz farkında olmadan bir kuyruk oluşturuyorsunuz. E-postaları gönderilmemiş olarak işaretlemek, sonra göndermek ve ardından bunları gönderilmiş olarak işaretlemek yaygın bir örnektir.
Kuyruklar iki temel nedenden dolayı problem çıkartır: İş yükünüzü seri olarak yürütür, görevlerin paralel olarak yapılmasını önler ve sıklıkla uzun süre önce işlenmiş olan işlerin geçmiş verileriyle birlikte yürütülmekte olan işleri içeren bir tablo oluşturur. Her ikisi uygulamada gecikme ve MySQL üzerinde yüke neden olur.
MySQL performans ipuçları No. 4: Sonuçları kolay olanlar önce gelecek şekilde filtreleyin
MySQL’i optimize etmenin harika bir yolu zahmetsiz, kesin olmayan işleri önce ardından da sonuçlanan daha küçük veri setleri üzerinde kesin olan işi yapmaktır.
Söz gelimi, belirli bir coğrafi noktanın çapı dahilindeki bir şeyi arıyorsunuz. Birçok programcının alet kutusundaki ilk araç bir dairenin yüzeyi boyunca bilgiişlem mesafesi için olan büyük-daire (Haversine) formülüdür. Bu teknikteki problem formülün çok fazla trigonometrik operasyona ihtiyaç duymasıdır ki bunlar CPU’yu yoğun bir biçimde kullanır. Büyük daire hesaplamaları yavaş çalışma eğilimindedir ve makinenin CPU kullanımını aşırı yükseltir.
Büyük daire fomülünü uygulamadan evvel, kayıtlarınızı toplamın küçük bir alt kümesine indirin ve sonuç setlerini kesin bir daireye ayarlayın. Daireyi kapsayan bir kare (kesin veya kesin olmayan) bunu gerçekleştirmenin kolay bir yoludur. Bu şekilde karenin dışındaki dünya hiçbir zaman o masraflı trigonometrik fonksiyonlarla buluşmaz.
MySQL performans ipuçları No. 5: İki Ölçeklenebilirlik tuzağını bilin
Ölçeklenebilirlik sizin inanıyor olabildiğiniz gibi belirsiz bir şey değil. Haddi zatında ölçeklenebilirliğin denklem olarak ifade edilen kesin matematik tanımları mevcut. Bu denklemler sistemlerin neden olması gerektiği kadar ölçeklenmediğini işaret ediyor.
Evrensel Ölçeklenebilirlik Kanunu’nu ele alın; bu bir sistemin ölçeklenebilirlik karakterinin ifadesi ve ölçülmesinde kullanışlı olan bir tanım. Bu kanun ölçekleme problemlerini iki temel maliyet anlamında açıklıyor: serileşme ve parazit.
Gerçekleşmek için serileşen bir şey için durması gereken paralel süreçlerin ölçeklenebilirliği kaçınılmaz olarak kısıtlıdır. Benzer biçimde, eğer paralel süreçler işlerini koordine etmek üzere sürekli birbirleriyle konuşmaya gereksinim duyuyorsalar onlar birbirlerini kısıtlar.
Serileşme ve parazitten kaçının; böylelikle uygulamanız çok daha iyi ölçeklenecektir. Peki bunun MySQL’deki tercümesi ne? Duruma göre değişiyor ancak sıralardaki özel kilitlerden kaçınmak örnek olarak gösterilebilir. No. 3’deki Kuyruklar, işte bu nedenden ötürü kötü bir biçimde ölçeklenme eğiliminde.
MySQL performans ipuçları No. 6: Konfigürasyona fazla odaklanmayın
DBA’ler hassas ayarlamalarda çok fazla zaman harcama eğilimindedir. Bunun sonucu genellikle büyük bir ilerleme değildir ve bazı zamanlarda fazlasıyla zarar verici olabilir. “Optimize” edildiği halde sık sık çöken, belleği taşan ve iş yükü biraz yoğunlaştığında performansı kötüleşen sunucularla karşılaştım.