Uç noktalara hizmet için yük testi

Bu makale, mozaik yapay zeka modeli sunma uç noktalarınızın üretim iş yüklerini etkili bir şekilde işleyebilmesini sağlamak için temel yük test sürecinde size yol gösterir. Ayrıca, uç noktalarınızı doğru boyutlandırabilmeniz ve iş gereksinimleriniz için modelleri güvenle dağıtabilmeniz için saniye başına istekler ve eşzamanlılık sınırları gibi önemli performans ölçümlerinin nasıl ölçülebileceğini göstermek için Locust yük testi çerçevesini kullanarak pratik örnekler, gerçek dünya benzetimleri ve adım adım yönergeler sağlar.

İpucu

Yük testi, üretim iyileştirmesinin temel bileşenlerinden biridir. Altyapı, model ve istemci tarafı iyileştirmeleri dahil olmak üzere iyileştirme stratejilerine yönelik kapsamlı bir kılavuz için bkz. Üretim için Model Sunma uç noktalarını iyileştirme.

Yük testi nedir?

Yük testi, gecikme süresi veya saniye başına istekler gibi üretim gereksinimlerinizi karşıladığından emin olmak için uç noktalar sunan Mozaik yapay zeka modelinin gerçek dünya kullanımını simüle eden bir testtir. Yük testi, uç noktanızın performansını farklı trafik düzeyleri altında ölçer ve gecikmelere neden olmayacak şekilde uç noktanızı doğru boyutlandırmanıza yardımcı olur.

Şunu hayal edin: Hafta içi saat 08:00 ve şehrin kalbindeki popüler bir kafe yeni açılıyor. Taze kahvenin aroması havayı doldurur. Barista hazır, makineler ısındı ve kafein eksikliği çeken müşterilerin sırası oluşmaya başladı.

İlk başta, işler sorunsuz çalışır. Birkaç müşteri öne çıkıp siparişlerini verdi ve barista içkilerini hazırlamaya başladı. Bazı içecekler 30 saniye, bazıları ise karmaşıklık durumuna bağlı olarak bir dakika sürer. Barista, pratik bir şekilde birden çok siparişi yönetir.

Ama yakında, daha fazla insan geliyor. Beş müşteri 10'a, sonra 20'ye dönüşür. Her biri sipariş ediyor, içkilerini bekliyor ve belki de tezgahta biraz sohbet ediyor. Barista baskı altında. İkinci bir baristanın sıçramasıyla bile sistem zorlanmaya başlar; hat büyür, siparişler birikir ve müşteriler daha uzun süre beklemeye başlar.

Şimdi müşterilerin hayal kırıklığına uğramadan önce kafenin dakikada kaç içki sunabileceğini ölçmeye çalıştığınızı düşünün. Bu yük testidir.

Bu benzetmede:

• Her müşteri, istek gönderen bir istemcidir .
• Baristalar, model çıkarımlarını tek tek veya paralel olarak işleyen sunucunuzu temsil eder.
• Sipariş verme ve içkiyi servis etme süresi, model uygulama süresidir.
• Ağ ek yükünüz, konuşma, ödeme veya siparişi bulma gecikmeleridir.
• Aynı anda gelen daha fazla müşteri , istemci eşzamanlılığıdır.
• Daha fazla barista veya daha fazla makine eklemek , sunucu eşzamanlılığınızı artırmaya benzer.

Herhangi bir iyi kafede olduğu gibi, personelin aynı anda ne kadar işleyebileceğinin bir sınırı vardır. Önceden planlamıyorsanız ( örneğin yoğun saatlerde daha fazla barista getirerek) insanlar mutsuz olarak ayrılır. Aynı durum yük altındaki sistemleriniz için de geçerlidir. Yük testi, performans sorunlarının nerede olduğunu, sisteminizin ne kadar trafiği işleyebileceğini ve daha sorunsuz bir hizmet için yapmanız gereken değişiklikleri belirlemenize yardımcı olur.

Uç noktanızda yük testi çalıştırmadan önce şunları yapmanız gerekir:

• Yük testiyle ilgili bileşenleri ve kavramları anlayın.
• Üretim gereksinimlerinize karar verin ve tanımlayın.
• Uç noktanızı kıyaslarken yük testi çerçevesi için kullanılacak temsili bir yük bulun.

Yük testi kavramları ve tanımları

Aşağıdaki tablo yük testiyle ilgili kavramları tanımlar:

Konsept	Açıklama
İstemci eşzamanlılığı (istemci sayısı)	Bir uç noktaya paralel olarak istekleri aynı anda gönderen toplam istemci sayısı. Yukarıdaki örnekteki kafeye gelen müşterileriniz bunlardır. Üretim: Model sunum uç noktasına trafik gönderen istemcilerin toplam örnek sayısı. Yük testi: Locust'ta, yük testi uygulanan model sunucu uç noktasına trafik gönderen oluşturulan kullanıcıların sayısıdır.
Uç nokta eşzamanlılığı	Gelen istekleri işleyebilen çıkarım işlemlerinin veya model örneklerinin sayısı. Ayrıca uç noktanız tarafından aynı anda işlenebilen istek sayısı olarak da ifade edilebilir. Yukarıdaki örnekte yer alan barista sayısıdır. Mozaik Yapay Zeka Modeli Sunma: İşlem ölçeği genişletme boyutları için model sunum uç noktaları yapılandırılabilir. Örneğin, CPU uç noktalarının Small boyutunun kullanılması, modelinizin uç noktada dört örneğini oluşturur.
Gecikme	Tam gidiş dönüş isteğinin tamamlanması için geçen süre (milisaniye cinsinden). İstemci yanıt alınana kadar istek gönderdikten sonra uç nokta çalışma süresi ve ağ gecikme süresi dahil olmak üzere toplam sürenin ölçüsü.
PXX (P50,P90,P99) gecikme süresi	XX yüzdelik dilimindeki isteklerin daha hızlı tamamlandığı gecikme süresi (milisaniye cinsinden). Örneğin, 30ms P90, tüm isteklerin 90% 30ms veya daha kısa sürede tamamlandığını gösterir.
Saniye başına istek sayısı (RPS)	Saniye başına tamamlanan istek sayısı. Tamamlandı, uç noktadan istemciye bir yanıt döndürülür.

Gecikme gereksinimleri

İş ve müşteri gereksinimlerinize göre sisteminizin ideal performansını tanımlayın. Uç noktaya hizmet veren bir modelde gecikme süresi, istemcinin çıkarım için veri gönderirken yaşadığı gidiş dönüş süresini içerir. Buna ağ gecikme süresi ve çıkarım süresi dahildir. Gereksinimlerinizin gerçekçi olduğundan emin olmak önemlidir. Örneğin, modeliniz belleğe yüklendiğinde çıkarım yapmak 15 ms sürerse, bir model sunum uç noktasında sunulduğunda ağ gecikmesini de hesaba katmak için ek süre tanımanız gerekir.

RPS, gecikme süresi ve eşzamanlılık arasındaki ilişki nedir?

Bir işletme, sisteminin başarısı için bazı tanımlanmış ölçütlere sahiptir. ML sistemleri için iş ölçütleri genellikle yüksek kaliteli sonuçlar, düşük gecikme süresi ve yüksek aktarım hızıdır. Sonuçların kalitesi özellikle modelin kendisiyle ilişkiliyken, uçtan uca gecikme süresi ve aktarım hızı hizmet verme sisteminin özellikleridir. Uçtan uca gecikme süresi, model yürütme süresinden ve ağ yükünden oluşur. Aktarım hızı (veya saniye başına istekler veya sorgular), gecikme süresiyle ters orantılıdır ve eşzamanlılıkla doğrudan ilgilidir.

• Eşzamanlılık ne kadar yüksek ise aktarım hızı da o kadar yüksektir.
• Gecikme süresi ne kadar yüksekse, veri aktarım hızı o kadar düşüktür.

Genel olarak, herhangi bir uygulama için istemci tarafı eşzamanlılığının sunucu tarafı eşzamanlılığıyla en uygun oranı vardır. Örnek olarak, "bir hat şefinin aynı anda kaç hamburger üzerinde çalışabileceğini". Pişirme işleminde birçok paylaşılan adım olabileceğinden, çizgi şefi aynı anda yalnızca bir hamburger pişirmek yerine aynı anda dört hamburgeri en iyi şekilde pişirebilir. Bu paralelleştirmenin bir sınırı vardır, bir noktada birçok paralel eylem gerçekleştirme eylemi, şefin 1000 burgere peynir eklemesi gerektiği gibi çok fazla gecikme süresi ekler.

Yük testinin ana hedeflerinden biri, uygulamanız için en uygun oranı belirlemektir. En uygun oran RPS'yi en üst düzeye çıkarır, gecikme süresi gereksinimlerinizi karşılar ve kuyruğa alma işlemini önler. Bu oran, uç noktanızı en zorlu yüklerinizi karşılayacak şekilde doğru şekilde boyutlandırmak için kullanılabilir.

Uç nokta istekleri yeterince hızlı işleyemiyorsa, bir satır oluşmaya başlar. Buna kuyruk adı verilir. Bir kuyruğun oluşturulması genellikle çok daha uzun uçtan uca gecikme süresine neden olur. Artık her isteğin işlenmeden önce beklemeye harcadığı ek süre vardır. İstekler işlenebilen isteklerden daha hızlı gelmeye devam ederse kuyruk büyür ve bu da gecikme süresini artırır. Bu nedenle uç noktanızın ne tür bir yoğun taleple karşılaşabileceğini anlamak ve yük testi ile doğru boyutlandırılmasını sağlamak önemlidir.

Yük testi senaryosu örnekleri

Yük testinde ve gerçek dünyadaki sistemlerde istemci eşzamanlılığı, sunucu eşzamanlılığı ve gecikme süresi arasındaki ilişki dinamik ve birbirine bağlıdır. Şimdi bu ilişkiyi basit bir örnekle görelim:

Senaryo 1: Basit kurulum

Bu kurulumda, tek bir istemci istekleri sıralı olarak gönderir; sonraki isteği göndermeden önce yanıt bekler. İstek başına toplam süre model yürütme ve ek yük gecikme süresi (40 ms + 10 ms) toplamı olduğundan ölçülen uçtan uca gecikme süresi 50 ms'dir.

• İstemci sayısı: 1
• Sağlanan eşzamanlılık: 1
• Ek yük gecikme süresi: 10 ms
• Model yürütme süresi 40 ms

Sonuç olarak, istemci her 50 ms'de bir isteği tamamlar ve bu da saniyede 20 istek veya saniye başına sorguya eşittir.

Senaryo 2: Sağlanan eşzamanlılığı artırma

Bu durumda, sağlanan eşzamanlılığı iki katına çıkarmış olursunuz ve tek bir istemci sırayla istekte bulunur. Bu, toplam gecikme süresinin hala 50 ms (40 ms + 10 ms) olduğu ve sistemin saniyede yalnızca 20 istek (QPS) gördüğü anlamına gelir.

• İstemci sayısı: 1
• Sağlanan eşzamanlılık: 1 -> 2
• Ek yük gecikme süresi: 10 ms
• Model yürütme süresi 40 ms

Senaryo 3: Sisteme başka bir istemci ekleyin.

Artık sağlanan iki eşzamanlılığa sahip bir uç noktaya istekte bulunan iki istemciniz var. Bu durumda, her istemcinin isteği uç nokta tarafından aynı anda bağımsız olarak işlenebilir (mükemmel yük dengeleme varsayılarak). Bu nedenle toplam gecikme süresi hala 50 ms (40 ms + 10 ms) olsa da, her istemci 20 qps gönderdiğinden sistem saniyede 40 istek gözlemler.

• İstemci sayısı: 1 -> 2
• Sağlanan eşzamanlılık: 2
• Ek yük gecikme süresi: 10 ms
• Model yürütme süresi 40 ms

Sağlanan eşzamanlılığı ve istekte bulunan istemci sayısını artırmak, sisteminizde gözlemlenen toplam QPS sayısını artırır ve gecikme süresine bir ceza uygulanmaz.

Senaryo 4: Sağlanan eşzamanlılığı azaltalım

Bu son senaryoda, istemci sayısı sağlanan eşzamanlılık değerinden daha fazladır. Bu kurulum, sisteme kuyruk ve bunun QPS ve gecikme üzerindeki etkisi olan başka bir değişken ekler.

• İstemci sayısı: 2
• Sağlanan eşzamanlılık: 2 -> 1
• Ek yük gecikme süresi: 10 ms
• Model yürütme süresi: 40 ms

Burada, aynı anda istekte bulunan iki istemciniz vardır. Ancak uç nokta tek seferde yalnızca tek bir isteği işleyebilir. Bu, ikinci isteği ilk istek işlenmeden önce beklemeye zorlar. İkinci isteğin beklemesi veya daha doğru bir şekilde kuyruğa alınması sistemin gecikme süresini olumsuz etkileyebilir. Sunucunun kuyruğa alma işlemine izin verdiği varsayıldığında (Databricks Model Sunma'da varsayılan olarak etkindir), ikinci istemci 90 ms: 10 ms (ağ yükü) + 40 ms (kuyruğa alma bekleme süresi) + 40 ms (model yürütme süresi) gecikme süresi görür. Bu, daha önce görülen 50 ms'den önemli ölçüde daha kötüdür.