Gelişmiş performans için 10 işaretçi yükleyin

İnsanlar genellikle yük testini performans testiyle eşitler. Yük testi, soruyu yanıtlamanın bir yolu olarak görülüyor Sistem ne kadar hızlı yanıt veriyor? Bu görüş, yük testinin proje etkinliğinin sonu olarak görülmesi anlamına gelir. Sadece geliştirmenin sonunda performans testi için son uygulamaya sahip olacağız ve bu nedenle gerçek dünyada yeterince hızlı çalıştığını ve canlı hizmete sorunsuz bir şekilde geçtiğini ancak o zaman onaylayabiliriz.

Yanlış yaklaşım! Bu son derece risklidir ve yük testine erken başlamanın ve proje boyunca uygulamanın birçok faydasını gözden kaçırır. Bu yaklaşımla, sistem yük testinden geçiyor ve sorunsuz bir şekilde hizmete geçiyor mu? Bazen evet. Ancak, hacimdeki küçük artışlarda bile, yük uygulanmaya başladıkça sistem daha sık başarısız olmaya başlar. İlk kez sistem üzerinde eşzamanlı talepler vardır ve kaynaklar üzerinde tahkim gereklidir. Hiç çalıştırılmamış koddan geçen yollar tetiklenir, kimsenin gerçekten düşünmediği durumlar ortaya çıkar. İşlemler başarısız. Sistemler çöküyor. Bu sorunlar giderildikten ve bir testte daha fazla yük uygulandıktan sonra, kaynak tükenmesi, arabellek taşmaları, zaman aşımları ve tutarsız davranışlar gibi sorunlarla karşılaşırız. İşlevsel bir üretim öncesi sistemi sağlam bir çözüme dönüştürmek için gereken gerçek çalışma daha yeni başladı.

Yük testi başladığında başarısız olan ve çok fazla çaba, stres ve harcamadan sonra rafa kaldırılan çok sayıda ürün örneği. Daha da kötüsü, yük testini tamamen kaçıran ve canlı çalışma sırasında önemli ölçüde başarısız olanlardır. Bir internet portalı geliştiricisi, kısa süre önce, yük testi, kötü performans gösteren ve kararsız bir sisteme yol açan temel yapısal sorunları ve verimsiz kodlamayı ortaya çıkardığında, işlevsel gelişimini tamamlamış yeni bir hizmetin geliştirilmesini durdurdu.

Peki bu risklerden kaçınmak için ne yapmalısınız? Hepimiz arızaları erken bulmanın daha ucuza mal olduklarında daha iyi olduğunu biliyoruz, ancak yük testi hala mümkün olduğu kadar geç kalmıştır. Bulduğu hata türleri, genellikle mimari değişikliklere ve büyük yeniden yazımlara ihtiyaç duyar ve bunlar o zamana kadar uygulanması oldukça pahalıdır. Cevap, erken başlamanız gerektiğidir. Sorunları erken tespit etmek ve sistemin yoldan çıkıp çıkmadığını kontrol etmek için proje boyunca farklı yük testi biçimleri tekrar tekrar uygulanmalıdır.

Bu, test odaklı geliştirme uygulamasının doğal bir uzantısıdır. Otomatik testlerin ilk önce yazıldığı ve kodun geliştirilirken bu testleri geçmesi gereken test odaklı geliştirme, büyük faydalar sağlar. Ancak, mevcut haliyle, bu testin odak noktası işlevselliktir. Geliştikçe, yazılımın işlevsel durumu her zaman bilinir ve bu nedenle yönetilebilir, işlevsel hatalar, yüksek maliyetli düzeltmelerden kaçınarak tomurcuk içinde bertaraf edilir, işlevsel risk büyük ölçüde azalır. O kadar başka riskler değil. Bir proje erken ve sürekli yük testi yaparsa, çok daha geniş ve kapsamlı bir risk azaltımı elde eder. Bunu etkili kılmak için:

1. Sistemi inceleyin ve sisteme yönelik tehditlerin sıralanmasına yardımcı olmak için bir risk analizi yapın; bu, yük testi faaliyetlerine öncelik vermenize yardımcı olacaktır.
2. Farklı yapıların verimliliğinin karşılaştırılmasına olanak sağlamak için veri toplayın. Bu, uzun vadeli eğilimin izlenmesine izin verir. Sistem aynı işi yapmak için giderek daha fazla işlemci süresi mi kullanıyor? Bu veriler, farklı talep düzeylerindeki kaynak gereksinimlerini tahmin etmek ve böylece ölçeklenebilirlik tahminlerini desteklemek için kullanılabilir.
3. Sistemin davranışını değerlendirmeyi ve yük altında arızaları tetiklemeyi amaçlayan testleri yürütün. Sistemin toplu davranışını gözlemlemek için beklenen talep modellerini simüle eden iş yüklerini kullanın. Sistemin güvenlik açıklarını araştırmak için özel olarak hedeflenmiş aşırı iş yüklerini kullanın.
4. Tüm yük testleri spektrumunu test paketine dahil edin. Bu, tipik ve yoğun dönem iş yükleriyle performans testi anlamına gelir; hem atipik talep artışlarını hem de kaynak tükenmesi etkilerini kontrol etmek için stres testi; hem operasyonel periyodu hem de kümülatif operasyon testlerini kullanan dayanıklılık testi; çok sayıda işlem çalıştıran ve ardından ara sıra işlemlerin başarısız olup olmadığını kontrol eden güvenilirlik testi; Aynı hesapta aynı anda çalışan iki kullanıcının eşzamanlılık testi.
5. Bilim adamları bir deney tasarlarken, analiz edilebilecek veriler sağlamak için tasarlarken ölçüm faaliyetlerini tasarlayın. Enterpolasyonu desteklemek üzere birden çok veri kümesi sağlamak için sistemi farklı sabit durum iş yükleri altında örnekleyin. Her işlem türü için kaynak maliyetlerinin tahminine izin vermek için iş yüklerini seçin.
6. İlk olarak ara yazılımı hedefleyin ve işlevsellik geliştirildikçe paketi geliştirin. Erken başlayın ve ardından sistemin her artımlı sürümünü, önce önceki paketle ve ardından yeni işlevselliği ele alan değiştirilmiş bir paketle test edin.
7. Temsili bir ölçekte çalışmak için zaman ve kaynaklara yatırım yapın. Belki test yatağı tam ölçekli olamaz, ancak amaçlanan sistemden iki kat daha küçük olmamalıdır. Uygun ölçekli bir test yatağı sağlamak için kaynakları etkili bir şekilde kullanmak için akıllı ve yenilikçi olun. Bunun yapılmaması durumunda ortaya çıkacak maliyetler, test yatağı sağlama maliyetini çok aşacaktır.
8. Geciktirme; bir artışı mümkün olan en kısa sürede test edin. Birini atlamayın, yoksa hepsini atlarsınız. Ölçümleri ve davranışı bir öncekiyle karşılaştırın, daha mı iyi yoksa daha mı kötü?
9. Fonksiyonel test için bir arka plan yükü sağlayın. Yük aktarımı yapan özellikler, sistemin düşünmesi gereken başka şeyler olduğunda başarısız olabilir.
10. Sunucu arızaları ve sistemin yeniden yapılandırılması gibi ara sıra meydana gelen olayları göz önünde bulundurun. Bunların yük altında test edilmesi gerekiyor mu?

Sonuç olarak, geliştirme süreci boyunca yük testini dahil etmeniz gerekir. Yük testini son çalıştırmaya kadar canlı hizmete bırakmak felaket için bir reçetedir. Bu yaygın bir uygulama haline gelirse, çalışan çok daha fazla uygulama ve sistem zamanında ve bütçeye göre teslim edilirdi.

Acutest Ltd 2005 http://www.acutest.co.uk