本文提供您在 Azure SDK for Java 中使用事件中樞連結庫時可能會遇到之常見效能問題的解決方案。 如果您要尋找使用事件中樞時可能會遇到之其他常見問題的解決方案，請參閱 針對 Azure 事件中樞進行疑難解答。
使用 processEvent 或 processEventBatch
當您使用 processEvent 回呼函數時，每個 EventData 實例都會呼叫您的程式碼。 此流程在事件中樞中心處理低流量或中度流量時效果良好。
如果事件中樞預期會有高流量和高輸送量，持續呼叫回呼函數的匯總成本可能會妨礙 EventProcessorClient 的效能。 此時，使用 processEventBatch。
每次針對一個分割區，會叫用您的回呼函式。 回呼中的高處理時間會阻礙效能，因為 EventProcessorClient 不會繼續在下游推送更多事件，也不會向事件中樞服務要求更多 EventData 實例。
檢查點的成本
當您使用 Azure Blob 儲存體作為檢查點存放區時，檢查點作業會因發出 HTTP 要求並等候回應而產生成本。 此過程最多可能需要幾秒鐘，這是由於網路延遲、Azure Blob 儲存體的效能、資源位置等因素所致。
處理每個實例之後的 EventData 檢查點會因為提出這些 HTTP 要求的成本而阻礙效能。 如果您的回呼函式未處理任何事件，請勿建立檢查點；或者在處理完一定數量的事件後再建立檢查點。
使用 LoadBalancingStrategy.BALANCED 或 LoadBalancingStrategy.GREEDY
當您使用 LoadBalancingStrategy.BALANCED 時，EventProcessorClient 為每個負載平衡週期宣告一個分割區。 如果事件中樞中有 32 個分割區，則需要 32 個負載平衡反覆專案來宣告所有分割區。 如果使用者知道有一組 EventProcessorClient 實例正在執行，他們可以使用 LoadBalancingStrategy.GREEDY 在一個負載平衡週期中宣告其分割區的共用。
如需每個策略的詳細資訊，請參閱 azure-sdk-for-java 存放庫中LoadBalancingStrategy.java。
設定 prefetchCount
默認預先擷取值為500。 當AMQP接收連結開啟時，會將500點數投入該連結。 假設每個 EventData 實例都是一個鏈接點數， EventProcessorClient 請預先擷取 500 EventData 個實例。 當處理器客戶端消耗完所有事件時，會為連結增加 500 點數以接收更多訊息。 在 EventProcessorClient 仍然擁有分割區時，此流程會重複。
設定 prefetchCount 太低會影響效能。 每次AMQP接收連結點數時，遠端服務就會傳送ACK。 在高吞吐量情況下，發出數千個用戶端要求及服務確認回應所帶來的額外負擔，可能會影響效能。
設定 prefetchCount 太高會影響效能。 當 x 個點數在計算中時，事件中樞服務知道最多可以傳送 x 條訊息。 收到每個 EventData 實例時，它會放在記憶體內部佇列中，等待處理。 佇列中大量的 EventData 實例可能會導致記憶體使用量非常高。
後續步驟
如果本文的故障排除指引無法幫助你解決使用Azure SDK Java客戶端函式庫的問題，請在Java GitHub儲存庫的Azure SDK中提出問題。