查询优化和API限制 [英] Query optimization and API throttling
问题描述
我们正在跟踪一些客户的Facebook Page和Post指标，我们对于CPU强度和POST /评论的呼叫数量有一些疑问 - 根据开发人员洞察控制台（Insights - >开发者 - >活动与错误）。对于Graph API的限制和限制，文档有些不清楚，我们只想确保我们对我们可用的资源有正确的了解。
We are tracking Facebook Page and Post metrics for a number of clients, and we have some questions regarding high CPU intensity and too many calls for Post/comments - according to what is being reported by the developer insights console (Insights -> Developer -> Activity & Errors). The documentation is somewhat unclear on the limits and restrictions for the Graph API, and we'd simply like to make sure we have the correct understanding of what resources we have available.
我们正在努力优化我们的软件和查询，以减少错误率和请求数量。与这项工作相关，我们有几个问题：
We are working on optimizing our software and queries to decrease the error rate and number of requests. Related to this work we have a few questions:
-
我们已经更改为使用FQL查询，而不是常规的Graph API请求发表评论，这使我们能够为每个请求的几个帖子提取评论。这导致请求数量大幅度减少。我们使用page_id IN（PAGE_ID_1，PAGE_ID_2，....）的查询。这会增加CPU的强度吗？
We have changed to use FQL queries instead of regular Graph API requests for fetching Post comments, which enables us to fetch comments for several posts per request. This have lead to a significant decrease in number of requests. We use a query with page_id IN (PAGE_ID_1, PAGE_ID_2, ....). Will this increase the CPU intensity compared with a regular Graph API request?
我们还实施了节制请求，以确保我们分发我们的请求随着时间的流逝，并没有大爆发。对于Page评论，我们确保在10分钟内最大请求数不超过300。换句话说，我们将页面评论请求的数量限制在每秒0.5次或每分钟30次。这是否仍然很高？
We have also implemented throttling of requests on our end to make sure we distribute our requests evenly over time and not in big bursts. For Page comments, we make sure the maximum number of request do not exceed 300 over a 10 minute period. In other words, we are limiting the number of Page comment requests to 0.5 per second or 30 per minute. Is this still to high?
一旦超出了请求限制，我们假设这是一个访问令牌，而不是APP ID？所以如果我们的客户之一过度使用资源，我们的APP仍将继续代表其他具有不同访问权限的客户端工作？
Once request limits are exceeded, we assume this is for an access token, not APP ID? So if one of our clients has been over-using resources, our APP will still continue working on behalf of our other clients which have different access tokens?
开发人员控制台，在Insights - >开发人员 - >活动&我们的应用程序的错误页面，API Throttling表有一个上面的时间。例如1小时14分钟。这个时间表示什么，这个表更新多久，数字多大？
In the developer console, under the Insights -> Developer -> Activity & Errors page for our app, the API Throttling table have a time above it. As an example 1 hour, 14 minutes. What does this time indicate, how often is this table updated, and how old are the numbers?
我们收到了少量的错误，响应代码为500这些错误通常是超出请求和/或CPU限制的结果吗？如果没有，有什么办法来确定实际造成的是什么，如果有什么我们可以做的，我们可以做些什么来解决它？
We are getting a small amount of errors with response code 500. Are these errors typically a result of exceeding request and/or CPU limits? If not, are there any ways to determine what is actually causing them, and if there is something we can do on our end to fix it?
我们很乐意对我们的假设做出任何意见和确认。
We'd appreciate any input on and confirmation of our assumptions.
推荐答案
您的问题的一些答案：
- 图形API请求的Facebook限制是每600秒600个请求...但是批处理请求在每个请求中被计为一个请求批次...我认为FQL限制是一样的...
- 这个限制是一个IP和一个访问令牌，如果你有很多令牌和/或IP可以调整这个限制
- 我没有实例，但是当你打破速度限制时，错误消息就是太多请求，而不是错误500 ...不知道whas可以导致这在你的情况下
有些问题我不明白：
- 当你谈到CPU强度时，做你的意思是在你身边或FB一面呢？在FB方面，我从来没有看到这样的限制，唯一的是600 req / 600秒...
Some questions I don't understand : - When you speak about "CPU intensity", do you mean on your side or FB side? On FB side I never see such a limit, the only one is 600 req / 600 sec...
更多信息：
Facebook图API速率限制和批量请求
什么是Facebook的Graph API通话限制？
这篇关于查询优化和API限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
