我们跟踪的Facebook页面和邮政指标多家客户，我们有关于高CPU强度和邮政/评论太多调用一些问题 - 根据开发者的见解控制台被报道是什么（视点 - >开发 - >活性和错误）。 该文件是在限制和约束的图形API有些不清楚，我们想只是想确保我们有什么资源，我们拥有正确的认识。
我们正在努力优化我们的软件和查询降低请求的错误率和数量。 与此相关的工作中，我们有几个问题：
我们已经更改为使用FQL查询，而不是常规图形API请求获取发表评论，这使我们能够为每个请求的几个职位提取评论。 这都导致请求的数量显著下降。 我们使用的查询与PAGE_ID IN（PAGE_ID_1，PAGE_ID_2，....）。 这是否会增加与常规图形API请求相比，CPU强度？
我们还实施了我们的最终要求的限制，以确保我们随着时间的推移平均分配我们的要求，而不是在大爆发。 对于页的评论，我们要确保请求的最大数量不超过10分钟的时间内超过300。 换句话说，我们正在限制页注释的请求的数量到0.5每秒或每分钟30。 这仍然是高？
一旦要求在超过极限，我们假设这是一个访问令牌，而不是APP ID？ 所以，如果我们的一位客户已经使用的资源过，我们的应用程序仍将继续代表具有不同的访问令牌我们的其他客户的工作？
在开发者控制台，下洞察 - >开发 - >活动和错误页面，我们的应用程序，该API节流表有它上面的时间。 作为一个例子1小时14分钟。 这是什么时候表示，该表的更新频率，以及多大是数字？
我们正在错误少量响应代码为500。这些错误通常超过请求和/或CPU限制的结果呢？ 如果不是，有什么方法来确定什么是真正导致他们，如果有什么我们可以在我们这边做，以解决这个问题？
我们将不胜感激我们的假设对任何输入和确认。
