{"action":"created","issue":{"url":"https://api.github.com/repos/NREL/api-umbrella/issues/273","repository_url":"https://api.github.com/repos/NREL/api-umbrella","labels_url":"https://api.github.com/repos/NREL/api-umbrella/issues/273/labels{/name}","comments_url":"https://api.github.com/repos/NREL/api-umbrella/issues/273/comments","events_url":"https://api.github.com/repos/NREL/api-umbrella/issues/273/events","html_url":"https://github.com/NREL/api-umbrella/issues/273","id":167872973,"number":273,"title":"Backend API Timeout","user":{"login":"noobfoot","id":12263583,"avatar_url":"https://avatars.githubusercontent.com/u/12263583?v=3","gravatar_id":"","url":"https://api.github.com/users/noobfoot","html_url":"https://github.com/noobfoot","followers_url":"https://api.github.com/users/noobfoot/followers","following_url":"https://api.github.com/users/noobfoot/following{/other_user}","gists_url":"https://api.github.com/users/noobfoot/gists{/gist_id}","starred_url":"https://api.github.com/users/noobfoot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/noobfoot/subscriptions","organizations_url":"https://api.github.com/users/noobfoot/orgs","repos_url":"https://api.github.com/users/noobfoot/repos","events_url":"https://api.github.com/users/noobfoot/events{/privacy}","received_events_url":"https://api.github.com/users/noobfoot/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-07-27T14:47:34Z","updated_at":"2016-08-02T03:47:52Z","closed_at":null,"body":"I've installed api-umbrella and added 3 APIs.  All of them forward requests to analytic services which vary in response times depending on the analysis request.  Some analysis could take up to a couple of hours...  My network connections are not the problem.  If I go directly to the analytic services the response times are about the same as if I were to go thru api-umbrella.  Initially I was receiving 504 errors from api-umbrella, so I updated the api-umbrella's proxy_connect_timeout: \r\n\r\n```\r\nnginx:\r\n  proxy_connect_timeout: 300\r\n```\r\n\r\nI'll probably have to come up  with a decision on what I consider to be a reasonable max time for a request going thru api-umbrella.  I'd like some feedback on a couple of things:\r\n\r\n- What does the api-umbrella team suggest as far as configurations for response times from backend APIs that vary.  Not necessarily only the proxy_connect_timeout value, but also any other configurations that I can adjust.\r\n\r\n- Is this the correct configuration setting to adjust when backend APIs take a while to respond?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/NREL/api-umbrella/issues/comments/236788011","html_url":"https://github.com/NREL/api-umbrella/issues/273#issuecomment-236788011","issue_url":"https://api.github.com/repos/NREL/api-umbrella/issues/273","id":236788011,"user":{"login":"GUI","id":12112,"avatar_url":"https://avatars.githubusercontent.com/u/12112?v=3","gravatar_id":"","url":"https://api.github.com/users/GUI","html_url":"https://github.com/GUI","followers_url":"https://api.github.com/users/GUI/followers","following_url":"https://api.github.com/users/GUI/following{/other_user}","gists_url":"https://api.github.com/users/GUI/gists{/gist_id}","starred_url":"https://api.github.com/users/GUI/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GUI/subscriptions","organizations_url":"https://api.github.com/users/GUI/orgs","repos_url":"https://api.github.com/users/GUI/repos","events_url":"https://api.github.com/users/GUI/events{/privacy}","received_events_url":"https://api.github.com/users/GUI/received_events","type":"User","site_admin":false},"created_at":"2016-08-02T03:47:52Z","updated_at":"2016-08-02T03:47:52Z","body":"Apologies for the delay in following up. There are 3 primary [timeout settings](https://github.com/NREL/api-umbrella/blob/v0.13.0/config/default.yml#L18-L20), with each one corresponding to the nginx configuration setting of the same name:\r\n\r\n- [`nginx.proxy_connect_timeout`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_connect_timeout)\r\n- [`nginx.proxy_read_timeout`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)\r\n- [`nginx.proxy_send_timeout`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout)\r\n\r\nEach of these defaults to 60 seconds. In your case, I think you'll probably want to adjust `proxy_read_timeout`, and not `proxy_connect_timeout`. The connection timeout is only relevant for establishing the initial connection to the backend server, which is usually very quick as long as the backend server is up (even if the backend takes a long time to start responding with data). The read timeout is what typically controls the timeout for long-running responses (but as the nginx docs note, this is the timeout between two successive chunks of data, so if your API streams back data in chunks, then the overall response time can exceed this timeout).\r\n\r\nI'm not sure I personally have any concrete recommendations for timeouts. Typically most APIs I see are quick and easily fit under the 60 second timeout. On some occasions we've tuned this upward to deal with APIs that might take a few minutes to respond. I don't have much experience with APIs that take hours to respond, but presumably if you tune the timeouts high enough, the network is stable, and the client doesn't drop the connection, then this should work.\r\n\r\nAlthough, for these type of long-running APIs, another approach I have seen is changing the API to be more of a polling/job model. In this case, the client might make an initial request to submit their job and immediately receive an identifier for their job back. They can then poll a different API endpoint to check the status of their job until it is complete. In this case, each of the requests can be quick, so you might not run into timeout issues. While it's a little more work for the client, an approach like this can sometimes be beneficial, since the task can continue to run in the background even if the client gets disconnected. But there's certainly other approaches, and depending on your use-case long running requests might be just fine."}}
{"actor":{"display_login":"GUI"}}