5 ms·

> Finally, App Engine has a hard 30 second limit on frontend requests. For the most part, this was fine. But certain requests started to take longer than 30 sec

by pilif 13y ago

> Finally, App Engine has a hard 30 second limit on frontend requests. For the most part, this was fine. But certain requests started to take longer than 30 seconds, particularly when empires started getting larger This is a very sensible limit. As your game is growing, more and more of these requests will pile up and will take resources away from quicker requests, making the game slower for everybody and crashing your architecture. Adding limits like this is one of the very basic things you do when you need to scale. Changing platforms in order to get rid of limits like this will only mean that you'll have to re-add them at some point. The correct fix for not running into such limits is to fix the code, not remove the limits.

yarrel 13y ago
Agreed. You don't want frontend requests tied up for a fraction of that. If you have long-running tasks then this is what task queues are for.
- themstheones 13y ago
  Or run partial computations throughout the day when possible.
twistedpair 13y ago
Sounds like they're prohibiting worst practices. A fine idea.
- waps 13y ago
  That seems like a rather arrogant attitude. You cannot force (what you consider) good practices on users/customers and expect them to be happy about it.
- twistedpair 13y ago
  If your requests need more than 30s, something is wrong. Most apps strive for <200ms responses. If you need a long time, rearchitect it. Run a background thread. Poll for completion or email the user when complete. Again, annoying, but your app will be better for it. Saying that a legacy product sucks, but that you still need it to run is not an effective mindset. These platforms have constraints. Work within them and the app will scale and perform very well.
RivieraKid 13y ago
No. The developers are clever enough to decide for themself whether the code needs to be fixed. There may be some situations where it may actually mae sense to have 30+ s long requests.
- specialp 13y ago
  No, when utilizing a REST protocol it is not desirable to have long requests. The correct way to do something that could potentially take a long time would be to process it in the background queued and then have the client poll the server until complete or to push it to the client when complete. Having an open connection for 30 seconds + is bad practice, and App Engine is a shared resource. Arbitrary limits are sometimes bad but in this case it will deter poorly designed APIs from starting in the first place.
  - jbeda 13y ago
    You can see how we implemented this in the GCE API with our operations resource. We had earlier versions that required long HTTP calls and it was generally less reliable if something should happen during the call.
  - RivieraKid 13y ago
    But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ seconds requests are not always bad. It has a cost (it takes time to fix it) and value (users won't have to wait). The developer has more information than Google to decide whether cost or value is higher.
    - yid 13y ago
      Out of curiosity, can you describe a situation where 30+ second requests on a large-scale, high-traffic system is acceptable (in the sense that it is better to hold the connection waiting rather than erroring out)? EDIT: long-polling aside, and even then, 30 seconds is a perfectly acceptable limit.
Strom 13y ago
Additionally, the 30 second limit was increased to 60 seconds in October 2011. [1] [1] http://googleappengine.blogspot.com/2011/10/app-engince-155-sdk-release.html http://googleappengine.blogspot.com/2011/10/app-engince-155-...
bridiver 13y ago
That is a very narrow-minded attitude. Not all apps have to scale and not all parts of an app have to scale. It may not make sense or be worthwhile to spend the effort to make a long running request shorter if it's used infrequently or by a small number of users or if the system as a whole does not require a high level of concurrency. Not every company is Google.

by pilif 13y ago

yarrel 13y ago

Agreed. You don't want frontend requests tied up for a fraction of that. If you have long-running tasks then this is what task queues are for.

themstheones 13y ago
Or run partial computations throughout the day when possible.

twistedpair 13y ago

Sounds like they're prohibiting worst practices. A fine idea.

waps 13y ago
That seems like a rather arrogant attitude. You cannot force (what you consider) good practices on users/customers and expect them to be happy about it.
twistedpair 13y ago
If your requests need more than 30s, something is wrong. Most apps strive for <200ms responses. If you need a long time, rearchitect it. Run a background thread. Poll for completion or email the user when complete. Again, annoying, but your app will be better for it. Saying that a legacy product sucks, but that you still need it to run is not an effective mindset. These platforms have constraints. Work within them and the app will scale and perform very well.

RivieraKid 13y ago

No. The developers are clever enough to decide for themself whether the code needs to be fixed. There may be some situations where it may actually mae sense to have 30+ s long requests.

specialp 13y ago
No, when utilizing a REST protocol it is not desirable to have long requests. The correct way to do something that could potentially take a long time would be to process it in the background queued and then have the client poll the server until complete or to push it to the client when complete. Having an open connection for 30 seconds + is bad practice, and App Engine is a shared resource. Arbitrary limits are sometimes bad but in this case it will deter poorly designed APIs from starting in the first place.
- jbeda 13y ago
  You can see how we implemented this in the GCE API with our operations resource. We had earlier versions that required long HTTP calls and it was generally less reliable if something should happen during the call.
- RivieraKid 13y ago
  But the developer is in the best position to decide whether he should fix the code. Perhaps he's just testing something, that will be rewritten later. 30+ seconds requests are not always bad. It has a cost (it takes time to fix it) and value (users won't have to wait). The developer has more information than Google to decide whether cost or value is higher.
  - yid 13y ago
    Out of curiosity, can you describe a situation where 30+ second requests on a large-scale, high-traffic system is acceptable (in the sense that it is better to hold the connection waiting rather than erroring out)? EDIT: long-polling aside, and even then, 30 seconds is a perfectly acceptable limit.

Strom 13y ago

Additionally, the 30 second limit was increased to 60 seconds in October 2011. [1] [1] http://googleappengine.blogspot.com/2011/10/app-engince-155-sdk-release.html http://googleappengine.blogspot.com/2011/10/app-engince-155-...

bridiver 13y ago

That is a very narrow-minded attitude. Not all apps have to scale and not all parts of an app have to scale. It may not make sense or be worthwhile to spend the effort to make a long running request shorter if it's used infrequently or by a small number of users or if the system as a whole does not require a high level of concurrency. Not every company is Google.