Spitfire

Sürüm: 0.21.0Bu dokümantasyon Spitfire 0.21.0 içindir.

MQTT ve RabbitMQ

Bu sayfa iki mesajlaşma protokolünü anlatır: IoT ve cihaz trafiği için MQTT, kuyruk tabanlı servisler için RabbitMQ (AMQP 0-9-1). Kafka için ayrı sayfaya bakın: Kafka.

MQTT

Ne işe yarar

Her VU ayrı bir MQTT istemcisidir, tıpkı bir cihaz gibi: ilk çağrısında bağlanır, aboneliklerini koşu boyunca tutar ve bağlantı koparsa bir sonraki çağrıda yeniden bağlanır. Üç eylem vardır:

  • Yayınla (publish): bir topic'e mesaj gönderir. QoS 1/2'de süre broker onayına kadar ölçülür.
  • Mesaj bekle (subscribe): VU topic'e bir kez abone olur; her iterasyon sıradaki mesajı bekler.
  • İstek/yanıt: yanıt topic'ine abone olur, mesajı yayınlar ve yanıtı bekler; süre gidiş-dönüştür.

Ne zaman kullanılır

Binlerce cihazın aynı anda bağlanıp telemetri gönderdiği bir senaryoda broker'ın (Mosquitto, EMQX, HiveMQ, RabbitMQ MQTT eklentisi…) kapasitesini ve gecikmesini ölçmek için.

Bağlantı oluşturma

  1. Bağlantılar → Bağlantı ekle, Tür: MQTT.
  2. Broker'lar (virgülle): tcp://broker:1883, TLS için ssl://broker:8883, WebSocket için ws://broker:8083/mqtt. Zorunludur. Adrese parola yazmayın.
  3. Client ID: şablondur; varsayılan spitfire-{{__VU}}. Her VU'nun benzersiz bir client ID'si olmalı; aynı ID ile bağlanan iki istemciden birini broker düşürür.
  4. Kullanıcı ve Parola (secret).
  5. Keep-alive (sn): varsayılan 30.
  6. Clean session: varsayılan açık. Kapalıysa broker oturumu ve kalıcı abonelikleri saklar.
  7. TLS için TLS bölümünü açın.
  8. Kaydet, Test et.

Adım ekleme

  1. Adım ekle → Protokol: MQTT → Bağlantı seçin.
  2. Eylem seçin.
  3. Topic yazın. Joker karakterler (+, #) yalnızca Mesaj bekle (subscribe)'da geçerlidir; yayınlamada kayıt joker karakterler (+ #) yalnızca abonelikte geçerli hatasıyla reddedilir.
  4. Mesaj (payload) yazın; {{değişken}} kullanılabilir.
  5. QoS (0, 1 ya da 2) ve gerekiyorsa retain seçin.
  6. İstek/yanıt'ta Yanıt topic'i yazın.
  7. Bekleme süresi (varsayılan 10s): Mesaj bekle ve İstek/yanıt'ta süre dolarsa adım başarısız sayılır.
json
[
  {"id": "telemetry", "name": "Telemetri", "protocol": "mqtt", "connection": "iot-broker",
   "mqtt": {"action": "publish", "topic": "devices/{{__VU}}/telemetry",
     "payload": "{\"temp\": {{$randInt 18 30}}}", "qos": 1}},
  {"id": "command", "name": "Komut bekle", "protocol": "mqtt", "connection": "iot-broker",
   "mqtt": {"action": "subscribe", "topic": "devices/{{__VU}}/commands", "qos": 1, "wait": "10s"}}
]

Ürettiği metrikler

req_duration (publish: QoS 0'da gönderim, QoS 1/2'de broker onayına kadar; subscribe: sıradaki mesajı bekleme; istek/yanıt: gidiş-dönüş), req_failed, reqs, data_sent, data_received.

İpucu

Her iterasyonda yeni bir cihaz gibi bağlanmak istiyorsanız Seçenekler sekmesinde İterasyonlar arası bağlantı kapat'ı işaretleyin; bu MQTT istemcilerini de etkiler. Bağlantı kurma maliyetini ölçmek için kullanışlıdır.

RabbitMQ (AMQP)

Ne işe yarar

Bir exchange'e mesaj yayınlar, bir queue'dan mesaj alır ya da istek/yanıt (RPC) yapar. VU'lar runner başına tek bir bağlantıyı (kendi channel'larıyla) paylaşır; istenirse her VU ayrı bağlantı açar. Her yayın publisher confirm'i bekler; ölçülen süre broker'ın onay süresidir.

Ne zaman kullanılır

Siparişler, bildirimler, iş kuyrukları gibi RabbitMQ üzerinden akan iş yükünün broker'ı ve consumer'ları nasıl etkilediğini görmek için.

Bağlantı oluşturma

  1. Bağlantılar → Bağlantı ekle, Tür: RabbitMQ (AMQP).
  2. URL: amqp://rabbit:5672/ ya da bir vhost ile amqp://rabbit:5672/orders. TLS'li port için genellikle amqps://rabbit:5671/. Zorunludur; parolayı URL'ye yazmayın.
  3. Kullanıcı ve Parola (secret).
  4. Her VU ayrı bağlantı: işaretlerseniz her VU kendi TCP bağlantısını açar (çok sayıda istemciyi taklit etmek için). Varsayılan: runner başına tek bağlantı, VU başına channel.
  5. TLS için TLS bölümü.
  6. Kaydet, Test et.

Adım ekleme

  1. Adım ekle → Protokol: RabbitMQ (AMQP) → Bağlantı seçin.
  2. Eylem:
    • Yayınla: Exchange (boşsa (varsayılan) exchange) ve Routing key yazın. Hiçbir queue'ya gitmeyen (unroutable) mesaj hata sayılır.
    • Kuyruktan al: Kuyruk adını yazın. Queue önceden var olmalı; her iterasyon bir mesaj alır ve onaylar (ack).
    • RPC (istek/yanıt): istek direct reply-to ile gönderilir, eşleşen yanıt beklenir.
  3. Mesaj yazın; gerekiyorsa Content-Type ve Header'lar ekleyin.
  4. Mesajın broker yeniden başlasa da kalması için Kalıcı mesaj'ı işaretleyin.
  5. Bekleme süresi (varsayılan 10s): tüketme ve RPC için.
json
[
  {"id": "publish", "name": "Sipariş olayı", "protocol": "amqp", "connection": "rabbit",
   "amqp": {"action": "publish", "exchange": "orders", "routingKey": "orders.created",
     "body": "{\"id\": \"{{$uuid}}\"}", "contentType": "application/json", "persistent": true}},
  {"id": "take", "name": "Kuyruktan al", "protocol": "amqp", "connection": "rabbit",
   "amqp": {"action": "consume", "queue": "orders.created", "wait": "10s"}},
  {"id": "rpc", "name": "Fiyat sor", "protocol": "amqp", "connection": "rabbit",
   "amqp": {"action": "rpc", "routingKey": "pricing.rpc", "body": "{\"sku\": \"A-1\"}", "wait": "5s"}}
]
Dikkat

Kuyruktan al gerçek bir queue'dan mesajı alır ve ack'ler; o mesaj artık gerçek consumer'ınıza gitmez. Production queue'larında kullanmayın; test için ayrı bir queue bağlayın.

Ürettiği metrikler

req_duration (yayın: publisher confirm'e kadar; tüketme: mesajı bekleme; RPC: gidiş-dönüş), req_failed, reqs, data_sent, data_received.

Sık karşılaşılan sorunlar

Belirti: MQTT Test et başarısız, connection refused ya da not authorized. Neden: Broker adresi/portu yanlış ya da kullanıcı/parola reddediliyor. Çözüm: Şemayı (tcp://, ssl://, ws://) ve portu kontrol edin; parolayı yeniden yazın.

Belirti: MQTT VU'ları sürekli kopup yeniden bağlanıyor. Neden: Client ID'ler çakışıyor (ör. sabit bir Client ID); broker aynı ID'li eski bağlantıyı düşürür. Çözüm: Client ID'de {{__VU}} kullanın (varsayılan spitfire-{{__VU}}).

Belirti: Mesaj bekle her seferinde zaman aşımı. Neden: Topic'e mesaj gelmiyor ya da topic adı/joker yanlış. Çözüm: Topic'i kontrol edin; aynı testte bir yayın adımı ekleyin; Bekleme süresini artırın.

Belirti: RabbitMQ ACCESS_REFUSED - Login was refused. Neden: Kullanıcı/parola yanlış ya da kullanıcının vhost'a erişimi yok. Çözüm: Parolayı yeniden yazın; kullanıcıya URL'deki vhost üzerinde izin verin.

Belirti: Yayın adımı publish: unroutable: 312 NO_ROUTE. Neden: Exchange'e bağlı, routing key'e uyan bir queue yok. Çözüm: Exchange adını ve routing key'i kontrol edin; queue binding'ini oluşturun.

Belirti: Kuyruktan al NOT_FOUND - no queue. Neden: Queue yok; Spitfire queue oluşturmaz. Çözüm: Queue'yu RabbitMQ'da önceden oluşturun.

İlgili sayfalar