針對Azure 事件中樞效能進行疑難排解

本文提供您在 Azure SDK for JAVA 中使用事件中樞程式庫時可能會遇到之常見效能問題的解決方案。 如果您要尋找使用事件中樞時可能會遇到之其他常見問題的解決方案，請參閱 疑難排解Azure 事件中樞 。

使用 processEvent 或 processEventBatch

當您使用回 processEvent 呼時，每個 EventData 實例都會收到呼叫您的程式碼。 此程式適用于事件中樞的低流量或中度流量。

如果預期事件中樞具有高流量和高輸送量，則持續呼叫回呼的匯總成本會阻礙 效能 EventProcessorClient 。 在此情況下，您應該使用 processEventBatch 。

針對每個分割區，會一次叫用一個回呼。 回呼中的高處理時間會阻礙效能，因為 EventProcessorClient 不會繼續在下游推送更多事件，也不會向事件中樞服務要求更多 EventData 實例。

檢查點的成本

當您使用 Azure Blob 儲存體 作為檢查點存放區時，檢查點的網路成本會因為發出 HTTP 要求並等候回應而產生網路成本。 此程式可能需要數秒的時間，因為網路延遲、Azure Blob 儲存體效能、資源位置等等。

處理每個實例之後的 EventData 檢查點會因為提出這些 HTTP 要求的成本而阻礙效能。 如果您的回呼未處理任何事件，或處理某些事件之後應該檢查點，則不應該檢查點。

使用 LoadBalancingStrategy.BALANCING 或 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 用戶端程式庫時解決問題，建議您 在 適用于 JAVA 的 Azure SDK GitHub 存放庫中 提出問題 。