IssueTracker

10 is the limit for Go instances; I'm not sure what it is for other runtimes.

this limit should be determined dynamically, based on past performance. making it configurable is a second-best solution.

> 10 is the limit for Go instances; I'm not sure what it is for other runtimes.

According to Amy:
https://groups.google.com/d/msg/google-appengine/Wvco3AQR-AM/N1Y7S2HfukkJ

10 - Java
10 - Go
8  - Python

> this limit should be determined dynamically, based on past performance. making it configurable is a second-best solution.

That's seems reasonable. Actually, based on new information I'm wondering if the limited couldn't be removed entirely.

According to @proppy's answer on stackoverflow:
http://stackoverflow.com/a/11882719/236564

There are 4 factors that go into determining, whether or not an instance may take on an additional request.

1. The current number of requests is < 10 (8 with Python27)
2. Instance Memory utilization < soft Memory limit
3. Instance CPU utilization < class CPU limit
4. The instance is warming up

The original justification for the N=10 request limit was to prevent instance from out-of-memory death:
https://groups.google.com/forum/#!msg/google-appengine/y-LnZ2WYJ5Q/j_w13F4oSSkJ%5B1-25%5D

Since instance memory & CPU utilization are now determining factors; could the N=10 limit be removed? Are there other considerations? If the soft memory limit doesn't provide an adequate buffer - is there a way to determine average memory usage per request? If so, maybe that could be used to adjust the buffer.

Thoughts?

Is this limit documented anywhere? I couldn't find one.

Escalated the issue to the engineering team.

We have seen more than 50 requests/second on instances during load tests. So is this still an issue?

This limit is on the number of concurrent requests. As long as your average request runs for less than 160ms (Python) or 200ms (Go or Java), your result is consistent with the explanation above. This limit effects apps that require little compute time relative to the time they spend waiting for dependent requests, such as those to the datastore API, to complete.

@Ingo It's not necessarily an indication that it's fixed. The issue is how many concurrent requests an instance is allowed to handle.

Does that mean that GAE will put more than 10 concurrent requests on an instance if the expected latency is <= 200 ms? We have seen >70 requests/s for requests with 70 ms latency but only 5-7 requests/s for requests with 700 ms latency (see http://stackoverflow.com/questions/16925653/how-to-reduce-the-number-of-front-end-instances-launched-by-gae).

Where do those numbers come from for Python and Java? Are they documented anywhere?

Has this been fixed yet? My instances are not being used as efficiently as they could be because of this limit - if you have to do a load of requests with something blocking like a urlfetch but not CPU or Mem intensive then you should be able to have loads of concurrent requests on a single instance.

Currently I'm having to code around this (batch requests up so that each request spawns it's own background threads), but this is something that I shouldn't have to do.

I don't see any mention of this in 1.8.6 pre-release either. We have a tuned server that can process most responses in less than 20ms (most <17ms).
I'd like to set at 15 or 20 instead of spinning up new instances which then service 1 request each and shut down because the first and longest running instance is happily servicing further requests.
Alternatively if Google is improving the instance startup to prevent this issue, perhaps using past instance/server performance metrics (thus making this configuration option redundant) I'd like to know.

[Comment deleted]

I see for the GAE/J SDK version 1.8.7 dated 5th November 2013, one entry in the release notes is:

  "The max_concurrent_requests setting is now configurable per version/module. [link to this issue]"

I cannot see any mention of this new configuration either in my GAE/J Administration Console application settings or in the GAE/J documentation. Either it's there and I have missed it, or it isn't there yet.

I trust that, if missing, access to this new setting will be added and documented.

This was fixed with 1.8.7:
https://developers.google.com/appengine/docs/go/modules/#Go_Configuration
https://developers.google.com/appengine/docs/java/modules/#Java_Configuration
https://developers.google.com/appengine/docs/python/modules/#Python_Configuration

For the record, this issue is not fixed for me, but since it is marked as "fixed" then that is probably the end of the matter.

The Java configuration documentation link above concerns app modules, not apps in general, and in particular a new "max-concurrent-requests" tag.

I still cannot see a setting for my app in the Administration Console, nor can I see anything in the Java application (non-module) configuration documentation.

Why can't you use the module configuration? The old configuration is deprecated.

If by "old configuration" you mean "Java Application Configuration with appengine-web.xml", then according to the GAE/J documentation no mention is made that this configuration method is depreciated. (Do you know where it states in the documentation that GAE/J apps must use modules?)

Also, again according to the GAE/J documentation, modules and their configuration are still in preview, so it would seem a little strange to me that an existing configuration method is depreciated before its replacement is out of preview.

#19 you should be able to add this following configuration directive to your main application appengine-web.xml:
  <automatic-scaling>
    <max-concurrent-requests>50</max-concurrent-requests>
  </automatic-scaling>

What it will actually do is configure the 'default module' of your application. Note that those settings can't coexist with the Administration Console Performance settings, so once you do the switch: you will have to configure performance settings using appengine-web.xml.

I haven't used Java but if it is anything like the python one then it uses modules regardless of whether you specify them or not (if you don't it just creates one module called default for you) and thus by not using the new syntax all you are doing is depriving yourself of additional configuration.

Yeah. Just tried this with our java hdr app on the default module. Although my appengine-web.xml config tells GAE to allow 100 QPS per instance, it still levels all my instances out at 10 QPS. It seems like this setting is ignored for frontend instances.

+1 from me. I really need this feature.

+1 from me. I've to fallback my implementation to webview because of this graphic inconsistency.

Voting +1 for this feature.

Voting +1 for this feature.

Voting +1 for this feature.

Not being able to set a proper dark or light statusbar/toolbar icon color is breaking our app color design very bad.

+1 for this feature.

Voting +1 for this feature.

Estoy de acuerdo con este comentario, es molesto cuando el diseñador te levanta la mano porque no le convence el contraste de los colores y te es imposible responder con fundamento y suplir los criterios. Sería genial poder personalizar más esta sección.

This has been an issue for 6 years now. Why isn't Google dealing with it? If I'm to use  Custom Tabs, I need to be able to change the toolbar text and color at will.