本文提供您在 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。 針對高輸送量案例，發出數千個用戶端要求和服務 ACK 的額外負荷可能會妨礙效能。
prefetchCount如果數位太高，設定可能會對效能造成影響。 當 x 個點數在計算中時，事件中樞服務知道最多可以傳送 x 條訊息。 收到每個 EventData 實例時，它會放在記憶體內部佇列中，等待處理。 佇列中大量的 EventData 實例可能會導致記憶體使用量非常高。
後續步驟
如果您在使用適用於 Java 的 Azure SDK 用戶端連結庫時，本文中的疑難解答指引無法解決問題，建議您