本文提供了在 Azure SDK for Java 中使用事件中心库时可能会遇到的常见性能问题的解决方案。 如果要查找使用事件中心时可能会遇到的其他常见问题的解决方案，请参阅故障排除Azure 事件中心。
使用 processEvent 或 processEventBatch
使用 processEvent 回调时，每个 EventData 实例都收到调用代码。 此过程适用于事件中心内的低流量或中等流量。
如果事件中心具有高流量和高吞吐量，则持续调用回调的总成本会阻碍性能 EventProcessorClient。 在这种情况下，应使用 processEventBatch。
对于每个分区，每次调用一个回调。 回调中的高处理时间会阻碍性能， EventProcessorClient 因为不会继续向下游推送更多事件，也不会从事件中心服务请求更多 EventData 实例。
检查指向的成本
使用 Azure Blob 存储 作为 检查point 存储时，检查点的网络成本是因为它发出 HTTP 请求并等待响应。 由于网络延迟、Azure Blob 存储的性能、资源位置等，此过程可能需要长达数秒的时间。
处理每个 EventData 实例后检查点会由于发出这些 HTTP 请求的成本而妨碍性能。 如果回调未处理任何事件，或者处理某些事件后应检查点，则不应检查点。
使用 LoadBalancingStrategy.BALANCING 或 LoadBalancingStrategy.GR企业版DY
使用 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 存储库中提出问题。