本文提供了在 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 实例可能会导致内存使用率非常高。
后续步骤
如果本文中的故障排除指南在使用 Azure SDK for Java 客户端库时无法解决问题，建议在 Azure SDK for Java GitHub 存储库中提出问题。