Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a cikk megoldásokat kínál azokra a gyakori teljesítményproblémákra, amelyek az Event Hubs-kódtár javaihoz készült Azure SDK-ban való használatakor merülhetnek fel. Ha az Event Hubs használatakor felmerülő egyéb gyakori problémákra keres megoldást, tekintse meg az Azure Event Hubs hibaelhárítását.
A processEvent vagy a processEventBatch használata
A processEvent visszahívás használatakor minden EventData példány meghívja a kódját. Ez a folyamat jól működik alacsony vagy mérsékelt forgalommal az eseményközpontban.
Ha az eseményközpont nagy forgalmú és magas átviteli sebesség várható, a visszahívás folyamatos meghívásának összesített költsége akadályozza a EventProcessorClient teljesítményét. Ebben az esetben a következőt kell használnia processEventBatch: .
Az egyes partíciók esetében a rendszer egyenként hívja meg a visszahívást. A visszahívás hosszú feldolgozási ideje hátráltatja a teljesítményt, mert a EventProcessorClient nem folytatja több esemény küldését lefelé, illetve nem kér több EventData példányt az Event Hubs szolgáltatástól.
Az ellenőrzőpontok költségei
Ha az Azure Blob Storage-t használja ellenőrzőpont-tárolóként, az ellenőrzés hálózati költséggel jár, mert HTTP-kérést küld, és vár a válaszra. Ez a folyamat akár több másodpercet is igénybe vehet a hálózati késés, az Azure Blob Storage teljesítménye, az erőforrás helye stb. miatt.
Az ellenőrzőpontok minden EventData példány feldolgozása után akadályozzák a teljesítményt a HTTP-kérések létrehozásának költsége miatt. Nem szabad ellenőrzőpontot létrehozni, ha a visszahívás nem dolgozott fel eseményeket, vagy ellenőrzőpontot kell létrehozni bizonyos számú esemény feldolgozása után.
A LoadBalancingStrategy.BALANCED vagy a LoadBalancingStrategy.GREEDY használata
Ha használja a LoadBalancingStrategy.BALANCED, a EventProcessorClient minden terheléselosztási ciklus során lefoglal egy partíciót. Ha egy eseményközpontban 32 partíció található, 32 terheléselosztási iteráció szükséges az összes partíció igényléséhez. Ha a felhasználók tudják, hogy meghatározott számú EventProcessorClient példány fut, akkor LoadBalancingStrategy.GREEDY használhatják a partíciók megosztására egy terheléselosztási ciklus során.
Az egyes stratégiával kapcsolatos további információkért lásd az azure-sdk-for-java adattárLoadBalancingStrategy.java.
PrefetchCount konfigurálása
Az alapértelmezett előbetöltési érték 500. Az AMQP fogadási hivatkozásának megnyitásakor 500 kreditet helyez el a hivatkozáson. Feltételezve, hogy minden EventData példány egy hivatkozási kredit, EventProcessorClient 500 EventData példányt előz meg. Az összes esemény felhasználásakor a processzorügyfél 500 kreditet ad hozzá a hivatkozáshoz, hogy további üzeneteket kapjon. Ez a folyamat ismétlődik, miközben a EventProcessorClient továbbra is a partíció tulajdonjogával rendelkezik.
A konfigurálás prefetchCount teljesítménybeli következményekkel járhat, ha a szám túl alacsony. Minden alkalommal, amikor az AMQP fogadási hivatkozás krediteket helyez el, a távoli szolgáltatás egy ACK-t küld. A nagy átviteli sebességű forgatókönyvek esetében az ügyfélkérések és a szolgáltatási ACK-k ezreinek többletterhelése akadályozhatja a teljesítményt.
A konfigurálás prefetchCount teljesítménybeli következményekkel járhat, ha a szám túl magas. Amikor x kreditek kerülnek a sorba, az Event Hubs szolgáltatás tudja, hogy legfeljebb x üzeneteket küldhet. Az egyes EventData példányok fogadásakor egy memórián belüli sorba helyezik őket, ahol feldolgozásra várnak. A sorban lévő EventData példányok nagy száma nagyon magas memóriahasználatot eredményezhet.
Következő lépések
Ha a cikkben található hibaelhárítási útmutató nem segít megoldani az Azure SDK for Java ügyfélkönyvtárak használatakor felmerülő problémákat, javasoljuk, hogy hibajegyet nyújtson be a Java-hoz készült Azure SDK GitHub-adattárban.