Databricks Apps ajanınızı yük testi ile test edin

Yük testi, Databricks Apps aracınızın performans düşüşlerinden önce sürdürebileceği saniye başına en fazla sorgu sayısını (QPS) bulur. Bu sayfada aşağıdakileri nasıl yapabileceğiniz gösterilir:

  1. Altyapı aktarım hızını LLM gecikme süresinden yalıtmak için aracınızın sahte bir sürümünü dağıtın.
  2. Locust ile rampa-doygunluk yük testi çalıştırın.
  3. Etkileşimli bir panoyla sonuçları analiz edin.

Claude Code becerisini kullanarak yapay zeka destekli yolu izleyebilir veya her adımı el ile ayarlayabilirsiniz.

İşlem yapılandırmaları genelinde QPS, gecikme süresi ve rampa ilerleme grafiklerini gösteren yük testi panosunun animasyonlu önizlemesi.

Gereksinimler

Claude Code kullanıyorsanız, /load-testing beceri iş akışını otomatikleştirir. Aracı kodunuzu okur, sahte kod oluşturur, yük testi betikleri oluşturur ve dağıtımda size yol gösterir.

Tavsiye

Claude Code'a bunu sizin için gerçekleştirmesini söyleyin:

Clone https://github.com/databricks/app-templates and run the /load-testing skill against the {your-template} template.

Veya aşağıdaki adımları izleyin.

1. Adım: Bir aracı şablonunu kopyalayın.

Bu /load-testing beceri, databricks/app-templates deposuna, hem üst düzey bir agent-load-testing beceri olarak hem de her bir temsilci şablonuna önceden senkronize edilmiş olarak dahil edilir. Eğer zaten app-templates'den bir projeniz varsa, zaten beceriye sahipsinizdir.

Depoyu kopyalayın ve test yüklemek istediğiniz aracının şablon dizinine geçin:

git clone https://github.com/databricks/app-templates.git
cd app-templates/{your-template}

2. Adım: Yük testi becerisini çalıştırma

Claude Code'da şunu çalıştırın:

/load-testing

Beceri, aşağıdaki adımlarda size etkileşimli olarak yol gösterir. Gerçek aracınızı test etmek için test simülasyonunu atlayabilir veya uygulamalarınız zaten çalışıyorsa kullanıma almayı atlayabilirsiniz.

  1. Parametreleri toplama: Dağıtım durumunuz, işlem boyutlarınız, çalışan yapılandırmalarınız ve OAuth kimlik bilgileriniz hakkında bilgi ister.
  2. Yük testi betikleri oluşturma: Projenize uyarlanmış locustfile.py, run_load_test.py ve dashboard_template.py oluşturur.
  3. LLM Taktidi: SDK'nıza (OpenAI Agents SDK, LangGraph veya özel) özgü bir mock istemci oluşturur ve gerçek LLM çağrılarını yapılandırılabilir akış gecikmeleriyle değiştirir.
  4. Test uygulamalarını dağıtma: Farklı işlem boyutlarına ve çalışan sayısına sahip birden çok uygulama yapılandırması dağıtma konusunda size yol gösterir.
  5. Testleri çalıştırma: M2M OAuth kimlik doğrulaması ve doygunluğa ulaşma ile yük testini yürütür.
  6. Sonuç oluşturma: QPS, gecikme süresi ve hata ölçümleri içeren etkileşimli bir HTML panosu oluşturur.

El ile kurulum

Yapay zeka yardımı olmadan yük testlerini ayarlamak ve çalıştırmak için bu adımları izleyin.

1. Adım: (Opsiyonel) Aracınızın LLM çağrılarını taklit edin

Gerçek LLM gecikme süresi içeren uçtan uca sonuçlar istiyorsanız bu adımı atlayın. Databricks Apps altyapısının aktarım hızını yalıtılmış olarak ölçmek için, istek başına gecikme süresinin (genellikle 1-30 saniye) performans sorunu yaratmaması için LLM'i simüle edin.

Taklit, yapılandırılabilir bir akış gecikmesi ile hazır yanıtlar döndürerek tüm istek/yanıt süreç hatlarını (SSE akışı, araç dağıtımı, SDK çalıştırıcısı) korur ve sadece LLM ile değiştirir. Bu, Databricks Apps platformunun sunabileceği maksimum QPS'yi ortaya çıkartır ve yük testleri sırasında Temel Model API'sinin belirteç maliyetlerini önler.

Sahte zamanlama iki ortam değişkeni tarafından denetlenmektedir:

Variable Varsayılan Açıklama
MOCK_CHUNK_DELAY_MS 10 Akışlı metin öbekleri arasındaki milisaniye cinsinden gecikme
MOCK_CHUNK_COUNT 80 Yanıt başına metin öbeklerinin sayısı

Varsayılan değerlerle, her sahte yanıt yaklaşık 800 ms (10 ms x 80 öbek) sürer ve gerçek llm yanıtından (3-15 saniye) çok daha hızlıdır. Ardından aktarım hızı numaraları modeli değil platformu yansıtır.

Gerçek LLM istemcisinin yerini alan bir sahte istemci oluşturun. Aracı kodunuzun geri kalanı değişmeden kalır ve yaklaşım SDK'nıza bağlıdır. OpenAI için içindeki başvuru uygulamasınamock_openai_client.pydatabricks/app-templatesbakın. Aynı desen diğer SDK'lara uyarlanmıştır.

OpenAI Aracıları SDK'sı

agent_server/mock_openai_client.py oluştur — akışla uygulamayı gerçekleştiren bir MockAsyncOpenAI sınıfı olan chat.completions.create(). Araç çağrı öbeklerini anında döndürür (LLM'nin bir aracı çağırmaya karar verdiği benzetimini yapar) ve MOCK_CHUNK_DELAY_MS ve MOCK_CHUNK_COUNT ortam değişkenlerinden yapılandırılabilir gecikmeli metin yanıt parçaları döndürür.

Ajanınıza entegre edin.

from agent_server.mock_openai_client import MockAsyncOpenAI
from agents import set_default_openai_client, set_default_openai_api

set_default_openai_client(MockAsyncOpenAI())
set_default_openai_api("chat_completions")

Aracı kodunuzun geri kalanı (işleyiciler, araçlar, akış mantığı) değişmeden kalır.

LangGraph

ChatDatabricks Modeli önceden oluşturulmuş AIMessage nesneleri döndüren bir sahte modelle değiştirin:

# Before:
# model = ChatDatabricks(endpoint="databricks-claude-sonnet-4")

# After:
from agent_server.mock_llm import MockChatModel
model = MockChatModel()

Mock, ilk çağrıda araçları çağırmalı ve sonraki çağrılarda metin içeriği ile AIMessage nesnelerini döndürmelidir, yapılandırılabilir akış gecikmeleriyle.

Özel ajanlar

Ajanınızın yaptığı tüm dış API çağrılarını (LLM, AI Search, araç API'leri), yapılandırılabilir gecikmelerle gerçekçi yanıt yapıları döndüren mock uygulamalarla sarın.

2. Adım: Yük testi betiklerini ayarlama

Projenizde bir load-test-scripts/ dizin oluşturun. Yük testi çerçevesi, herhangi bir Databricks Apps ajanı ile çalışan ve çerçeve bağımsız olan üç betikten oluşur.

<project-root>/
  agent_server/                  # Your existing agent code
  load-test-scripts/             # Load testing scripts (create this)
    run_load_test.py             #   CLI orchestrator
    locustfile.py                #   Locust test with SSE streaming + TTFT tracking
    dashboard_template.py        #   Interactive HTML dashboard generator
  load-test-runs/                # Results (auto-created per run)
    <run-name>/
      dashboard.html             #   Interactive dashboard
      test_config.json           #   Test parameters for reproducibility
      <label>/                   #   Per-config Locust CSV output

Çerçeve aşağıdaki dosyaları içerir:

  • locustfile.py: Locust yük testi, POST /invocations istek gönderme ve stream: true ile SSE akışlarını ayrıştırma işlevine sahiptir ve özel bir ölçüm olarak ilk belirtece (TTFT) kadar olan süreyi izler, M2M OAuth belirteç değişimini otomatik yenileme ile kullanır ve kullanıcıları StepRampShape başlangıç düzeyinden step_size seviyesine artırarak max_users saniye boyunca her düzeyi sabit tutar.
  • run_load_test.py: Her uygulama URL'sini yapılandırma başına yalıtılmış ölçümlerle sıralı olarak test eden bir CLI düzenleyici. OAuth belirteci yeniler, her test öncesi bir sağlık kontrolü ve ön hazırlık yapar ve sonuçları load-test-runs/<run-name>/<label>/ öğesine kaydeder.
  • dashboard_template.py: KPI kartları, çubuk grafikler (QPS, gecikme süresi, yapılandırmaya göre TTFT), QPS rampa ilerleme çizgi grafikleri ve tam sonuç tablosu ile Chart.js kullanarak bağımsız bir HTML panosu oluşturur. Tek başına çalıştırılabilir: uv run dashboard_template.py ../load-test-runs/<run-name>/.

Bağımlılıkları yükleme

Yük testi betikleri, aracınızın üretim bağımlılıklarını kirletmemek için pyproject.tomlload-test-scripts/ içindeki kendi alanlarını kullanır. Oluştur load-test-scripts/pyproject.toml:

[project]
name = "load-test-scripts"
version = "0.1.0"
requires-python = ">=3.10"
dependencies = [
  "locust>=2.32,<2.40",
  "urllib3<2.3",
  "requests",
]

Note

locust'yı <2.40'ye sabitle. Daha yeni sürümlerin (>=2.43) uzun yük testlerini bozan bilinen bir RecursionError sorunu vardır.

Dizinin içinden load-test-scripts/ yükleyin:

cd load-test-scripts/
uv sync

3. Adım: Farklı yapılandırmalara sahip test uygulamalarını dağıtma

İş yükünüz için en uygun yapılandırmayı bulmak için farklı işlem boyutlarına ve çalışan sayısına sahip birden çok Databricks Uygulaması dağıtın.

Aşağıdaki yapılandırmalar, önceki testlerden tanımlanan tatlı noktaya odaklanır. Daha geniş bir kapsam istiyorsanız, her iki tarafa da bir yapılandırma ekleyin (örneğin, medium-w1 veya large-w12), ancak aşağıdaki altı yapılandırma genellikle yeterlidir.

Boyutu hesapla Işçi Önerilen uygulama adı
Medium 2 <your-app>-medium-w2
Medium 3 <your-app>-medium-w3
Medium 4 <your-app>-medium-w4
Büyük 6 <your-app>-large-w6
Büyük 8 <your-app>-large-w8
Büyük 10 <your-app>-large-w10

İşlem boyutunu yapılandırma

Uygulama oluştururken veya güncelleştirirken işlem boyutunu ayarlamak için Databricks CLI'yı kullanın:

# Create a new app with Medium compute
databricks apps create <app-name> --compute-size MEDIUM

# Update an existing app to Large compute
databricks apps update <app-name> --compute-size LARGE

Bildirim temelli Otomasyon Paketleri ile çalışan sayısını yapılandırma

start-server (aracılığıyla AgentServer.run()) doğrudan bir --workers bayrak kabul eder. DAB değişkeni kullanarak dizideki command çalışan sayısını geçirin:

variables:
  app_name:
    default: 'my-agent-medium-w2'
  workers:
    default: '2'

resources:
  apps:
    load_test_app:
      name: ${var.app_name}
      source_code_path: .
      config:
        command: ['uv', 'run', 'start-server', '--workers', '${var.workers}']
        env:
          - name: MOCK_CHUNK_DELAY_MS
            value: '10'
          - name: MOCK_CHUNK_COUNT
            value: '80'

targets:
  medium-w2:
    default: true
    variables:
      app_name: 'my-agent-medium-w2'
      workers: '2'
  large-w8:
    variables:
      app_name: 'my-agent-large-w8'
      workers: '8'

Dağıtma ve doğrulama

Databricks CLI ile her hedefi dağıtın:

databricks bundle deploy --target medium-w2
databricks bundle run load_test_app --target medium-w2

Yük testlerini çalıştırmadan önce uygulamaların etkin olduğunu doğrulayın:

databricks apps get <app-name> --output json | jq '{app_status, compute_status, url}'

Note

Devam etmeden önce tüm uygulamaların ACTIVE durumuna ulaşmasını bekleyin. Çalışmaya devam eden uygulamalar yanıltıcı sonuçlar üretir.

4. Adım: Yük testlerini çalıştırma

Kimlik doğrulamayı ayarlama

Ne kadar süreyle çalıştırmayı planladığınız temelinde kimlik doğrulamanızı seçin:

  • Kısa testler (yaklaşık 1 saatten az): 'den databricks auth loginmevcut kullanıcı kimlik bilgilerinizi kullanın. Ek kurulum gerekmez.
  • Uzun testler (örneğin, gece boyunca gerçekleştirilen yaklaşık 1 saatten fazla süreli testler): bir hizmet ilkesi ile M2M OAuth kullanın. U2M belirteçlerinin süresi dolar ve testinizin ortasında bozulabilir. Hizmet sorumlusu oluşturmak için çalışma alanı yöneticisi erişimi gerekir.

M2M OAuth için, testleri çalıştırmadan önce hizmet sorumlusu kimlik bilgilerini dışarı aktarın:

export DATABRICKS_HOST=https://your-workspace.cloud.databricks.com
export DATABRICKS_CLIENT_ID=<your-client-id>
export DATABRICKS_CLIENT_SECRET=<your-client-secret>

Parametreler rehberi

Parametre Zorunlu Varsayılan Açıklama
--app-url Yes — Test etmek için uygulama URL'leri (yinelenebilir)
--client-id Uzun testler için DATABRICKS_CLIENT_ID Env Hizmet sorumlusu istemci kimliği (M2M OAuth)
--client-secret Uzun testler için DATABRICKS_CLIENT_SECRET Env Hizmet sorumlusu istemci gizli anahtarı (M2M OAuth)
--label Hayır URL'den otomatik olarak türetilen Uygulama başına insan tarafından okunabilir etiket (yinelenebilir)
--compute-size Hayır Otomatik algılanan veya medium Uygulama başına işlem boyutu etiketi: medium, large (yinelenebilir)
--max-users Hayır 300 En fazla eşzamanlı simülasyon kullanıcısı
--step-size Hayır 20 Rampa adımı başına eklenen kullanıcılar
--step-duration Hayır 30 Rampa adımı başına saniye sayısı
--spawn-rate Hayır 20 Kullanıcı oluşturma oranı (kullanıcılar/sn)
--run-name Hayır <timestamp> Bu çalıştırmanın adı — kaydedilen sonuçlar load-test-runs/<run-name>/
--dashboard Hayır Off Testler tamamlandıktan sonra etkileşimli HTML panosu oluşturma

Örnek komutlar:

Hızlı tek uygulama testi (kısa çalıştırma — oturumunuzu databricks auth login kullanır):

cd load-test-scripts/

uv run run_load_test.py \
    --app-url https://my-app.aws.databricksapps.com \
    --dashboard --run-name quick-test

Önerilen 6 yapılandırmada tam matris (uzun süreli operasyon — M2M kimlik bilgilerini iletme). --compute-size bayraklarını --app-url: ile aynı sırada geçirin

uv run run_load_test.py \
    --app-url https://my-app-medium-w2.aws.databricksapps.com \
    --app-url https://my-app-medium-w3.aws.databricksapps.com \
    --app-url https://my-app-medium-w4.aws.databricksapps.com \
    --app-url https://my-app-large-w6.aws.databricksapps.com \
    --app-url https://my-app-large-w8.aws.databricksapps.com \
    --app-url https://my-app-large-w10.aws.databricksapps.com \
    --compute-size medium --compute-size medium --compute-size medium \
    --compute-size large --compute-size large --compute-size large \
    --client-id $DATABRICKS_CLIENT_ID \
    --client-secret $DATABRICKS_CLIENT_SECRET \
    --dashboard --run-name overnight-sweep

İstatistiksel tutarlılık için birden çok çalıştırma:

for RUN in r1 r2 r3 r4 r5; do
  uv run run_load_test.py \
      --app-url https://my-app.aws.databricksapps.com \
      --client-id $DATABRICKS_CLIENT_ID \
      --client-secret $DATABRICKS_CLIENT_SECRET \
      --max-users 1000 --step-size 20 --step-duration 10 \
      --run-name my_test_${RUN} --dashboard || break
done

Çalıştırma sırasında ne olur?

  1. Healthcheck: Uygulama akışlarını doğru şekilde doğrular (alır [DONE]).
  2. Isınma: Uygulamayı ısıtmak için sıralı istekler gönderir.
  3. Rampadan doygunluğa: eşzamanlı kullanıcı sayısını her step_duration saniyede artırır.
  4. Saturation detection: Kullanıcı sayısı artırılsa da QPS sabit kaldığında, aktarım hızı tavanına ulaşıldığını gösterir.

Tahmini süre

Test altındaki her uygulama kendi rampasında çalışır, bu nedenle toplam çalışma süresi matrisinizdeki yapılandırma sayısıyla ölçeklendirilir. Çalıştırma pencerenizi planlamak için aşağıdaki formülü kullanın.

Uygulama başına süre: (max_users / step_size) * step_duration saniye.

Varsayılanlarla (--max-users 300 --step-size 20 --step-duration 30):

  • 15 adım x 30 saniye = uygulama başına yaklaşık 7,5 dakika
  • Önerilen 6 yapılandırma matrisi için: çalıştırma başına yaklaşık 45 dakika

5. Adım: Sonuçları görüntüleme ve yorumlama

  1. Panoyu açın:

    open load-test-runs/<run-name>/dashboard.html

  2. (İsteğe bağlı) Mevcut verilerden panoyu yeniden oluşturma, örneğin şablonu güncelleştirdikten sonra:

    cd load-test-scripts/
uv run dashboard_template.py ../load-test-runs/<run-name>/

Kontrol Paneli Bölümleri

Etkileşimli pano şunları içerir:

  • KPI kartları: en iyi yapılandırma (en yüksek başarılı QPS ile), genel olarak en yüksek QPS, en düşük gecikme süresi ve sunulan toplam istek sayısı.
  • Yapılandırmaya göre QPS: Ortanca QPS'yi, hatalar hariç en yüksek QPS'yi ve her yapılandırma için en yüksek QPS'yi yan yana gösteren gruplandırılmış çubuk grafik.
  • Yapılandırmaya göre gecikme süresi: p50 ve p95 gecikme süresini gösteren gruplandırılmış çubuklar.
  • Yapılandırmaya göre TTFT: İlk belirtece ulaşma süresi (p50 ve p95).
  • Toplam Sunulan İstek Sayısı: Yapılandırma başına istek sayısı.
  • QPS Rampa İlerlemesi: QPS, QPS (hatalar hariç), Gecikme süresi ve Hatalar sekmeleri içeren çizgi grafikler. Daha düşük eşzamanlılık aralıklarına odaklanmak için kullanıcı sayısı kaydırıcısı içerir. Grafikler işlem boyutuna (orta ve büyük yan yana) göre gruplandırılır.
  • Tam Sonuç Tablosu: En yüksek QPS'ye sahip tüm yapılandırmalar, kullanıcılar en yoğun, gecikme süresi yüzdebirlik dilimleri ve hata oranı.
  • Test Parametreleri: Yeniden üretilebilirlik için yapılandırma özeti.

Sonuçları yorumlama

  • En yüksek QPS: Herhangi bir rampa adımında elde edilen maksimum QPS. Bu, bu yapılandırmanın aktarım hızı tavanıdır.
  • En Yoğun Kullanıcılar: En yüksek QPS'ye ulaşıldığında eşzamanlı kullanıcı sayısı. Bu noktadan sonra daha fazla kullanıcı eklemek aktarım hızını artırmaz.
  • Hata Oranı: 0% veya çok düşük olmalıdır. Yüksek hata oranı, uygulamanın bu eşzamanlılık düzeyinde aşırı yüklendiği anlamına gelir.
  • QPS Rampa Grafiği: Çizginin düzleştirilmiş olduğu yeri arayın. Bu doygunluk noktasıdır: Daha fazla kullanıcı eklemek aktarım hızını artırmaz.

Sentetik veri üzerinde referans kıyaslama çalıştırması

Bu bölümde, Azure Databricks içinde yürütülen bir iç kıyaslama testinin, her LLM çağrısının taklit edildiği sentetik bir aracı uygulamaya karşı hangi sonuçları ölçtüğü rapor edilir. Bu, kendi ajanınızın yük testinden ayrı bir çalışmadır: Bunu, bekleyebileceğiniz sonuçların nasıl görüneceğini görmek ve boyutlandırma için kabaca bir başlangıç noktası edinmek amacıyla kullanın.

Bu çalıştırmanın gösterdiği şey

  • Önerilen başlangıç noktası: Orta işlemde 2 çalışan veya Büyük'te 8 çalışan.
  • Daha fazla işçi her zaman daha iyi değildir. Orta düzeyde 2 işçi (155,1 QPS), 4 işçiyi (116,5 QPS) yaklaşık 33%yendi. Simüle iş yükü CPU ile sınırlıdır; bu nedenle 2 worker’ın üzerine çıkınca, ek paralelliğin getirisini ortadan kaldıran CPU/bellek kaynak çekişmesi yaşarsınız. Çoğunlukla bir model uç noktasından yanıt bekleyen gerçek bir G/Ç’ye bağımlı ajan, bu yapay örnekten daha iyi ölçeklenebilir; bu yüzden kendi ajanınızı mutlaka test edin.
  • İşlem boyutu: Büyük, orta (278,0 ile 123,5 ortalama en yüksek QPS) arasında kabaca 2,2 kat aktarım hızı sunar.
  • Gecikme süresi: Large, Medium’e kıyasla yaklaşık %20 daha düşük gerçekleşti (~906 ms’ye karşı 1,180 ms p50); TTFT ise Large’da ~1,100 ms, Medium’de 1,720-1,820 ms oldu.
  • Güvenilirlik: Hata oranı, 1.000 eşzamanlı kullanıcı bile olsa her yapılandırma için 0% veya yakınında kaldı.

LLM taklit edildiğinden (akış, öbek başına sabit gecikmelerle simüle edildi), bunlar uçtan uca ajan ölçümleri değil, altyapı çıktı işleme hızı ölçümleridir. Databricks Apps FastAPI'nin AgentServer gerçek bir modelin gecikme süresini değil paralel olarak işleyebileceği istekleri ölçer. Canlı LLM uç noktasını çağıran bir üretim aracısı, model yanıt süresinin hakim olduğu daha düşük QPS ve daha yüksek gecikme süresi görür. Değerleriniz, ajan karmaşıklığına, yükün boyutuna, araç çağrılarına, bölgeye ve çağırdığınız model uç noktasına bağlı olarak değişir. Doğru boyutlandırma için kendi ajanınıza karşı bir yük testi gerçekleştirin.

Aşağıdaki tablodaki sonuçlar yapılandırma başına dökümün tamamını gösterir.

Test koşulları

  • Referans çalıştırma: Her biri farklı bir uvicorn çalışan sayısına sahip 8 uygulama yapılandırmasının (4 Orta, 4 Büyük işlem gücü) genelinde 5 aynı tur.
  • Rampa: 20 ila 1.000 eşzamanlı kullanıcı, her biri 10 saniye boyunca tutulan 20 kullanıcının adımlarında (yapılandırma başına 50 adım).
  • Test aracısı: İstek başına yaklaşık 95 parçalık akış yanıtları sunarak LLM belirteçlerinin akışını simüle eder.
  • Hacim: tüm çalıştırmalar genelinde toplam yaklaşık 1,46 milyon istek.

Yapılandırmaya göre en yüksek QPS

En yüksek QPS, 5 çalıştırmadaki değerlerin ortalaması alınarak hesaplanır.

Boyutu hesapla Işçi Ortalama en yüksek QPS Zirve aralığı Hata oranı
Medium 2 155.1 137.0-166.6 0,0%
Medium 4 116,5 112.6-121.8 0,1%
Medium 6 111.9 102.6-117.5 0,0%
Medium 8 110,3 108.3-112.1 0,0%
Büyük 6 281,6 268.2-292.4 0,0%
Büyük 8 268,2 265.8-271.0 0,0%
Büyük 10 288.1 280.3-299.4 0,0%
Büyük 12 274,2 269.4-278.8 0,0%

İşlem boyutuna göre ortalaması alınır:

Boyutu hesapla Ortalama en yüksek QPS Ortalama QPS
Medium 123,5 45.5
Büyük 278.0 100.1

Bu çalıştırmada, Büyük işlem kabaca Orta işlem aktarım hızının yaklaşık 2,2 katını teslim etti.

Troubleshooting

Sorun Çözüm
Kimlik doğrulama belirtecinin süresi test ortasında doldu Yaklaşık 1 saatten uzun testler için, --client-id geçirerek U2M'den M2M OAuth'a geçin --client-secret
Durum kontrolü başarısız Uygulamanın ETKİN olduğunu doğrulayın: databricks apps get <name> --output json
0 QPS veya sonuç yok Hataları denetle load-test-runs/<run-name>/<label>/locust_output.log
Yüksek kullanıcı sayısına rağmen düşük QPS Uygulama doygundur. Daha fazla çalışan veya daha büyük işlem deneyin.
Yüksek hata oranı Uygulama aşırı yüklenmiş. Çalışanları veya işlem gücünü azaltın ya da artırın --max-users.
Panoda rampa verileri yok Her sonuç alt dizininde mevcut olduğunu doğrulayın results_stats_history.csv

Ek kaynaklar

  • Gerçek LLM çağrılarıyla test etme: Sahte adımı atlayın ve LLM yanıt süresi de dahil olmak üzere uçtan uca gecikme süresini ölçmek için gerçek aracınızı dağıtın.
  • Çalışan sayısını ayarlama: İşlem boyutunuz için en uygun çalışan sayısını bulmak için test matrisi sonuçlarını kullanın.
  • Rehber: Aktarım hızıyla birlikte doğruluğu, alaka düzeyini ve güvenliği ölçmek için bir GenAI uygulamasını değerlendirin ve geliştirin.
  • Databricks Apps aracınızı, AI Gateway dahil tam üretime hazırlık süreci için üretime alın.
  • Last updated on