Yes, it is the same scheduler (this is all on GAE Standard, right?) Of
course, that scheduler has lots of knobs.
If you can build a repro, can you work with support? If anything, the
concurrency of GAE Python 3 should be better than GAE Python 2.
On Fri, Nov 5, 2021 at 3:36 PM Joshua Smith
I don't have threadsafe in my 3.7 app's app.yaml. Just runtime and instance
class. (I do have it in my 2.7 app, of course.)
I'll try playing with max concurrent threads, but if I bump it from 10 (the
default) to 16, that really just changes it from 6 request to start an
instance, to 9. Hard to
The scheduler is the same.
This might have to do with `threadsafe` in app.yaml, which is complicated
and confusing. I'd suggest removing `threadsafe` if it's present, then try
setting the max_concurrent_requests to something higher (like 2x your
number of workers):
I figured out from the logs (since it prints a message for each worker it
starts) that 3.7 is starting 8 workers by default. So adding the entrypoint
with defaults has no effect.
However, I did some experiments and I think I can characterize the difference
between 2.7 and 3.7 when it comes to
We'll work to open source the launcher source. In the meantime, the default
logic looks like this:
workerCount := 8
if memoryMb <= 128 {
workerCount = 1
} else if memoryMb <= 256 {
workerCount = 2
} else if memoryMb <= 512 {
workerCount = 4
}
The number of workers to use is highly dependent on
I think it's telling me that since my P3.7 app has a F4_1G instance, I should
be configuring it to run gunicorn with 8 workers. I don't see any information
about the default number of workers. I guess I can do an experiment to see what
explicitly setting that does...
> On Nov 5, 2021, at 3:17
It sounds like there might be some differences due to concurrency between
2.7 and 3.7/8/9. There are some notes on how to tweak the number of worker
processes started for Python 3
here:
https://cloud.google.com/appengine/docs/standard/python3/runtime#entrypoint_best_practices
On Friday, 5
There is no official description, somewhere, of "how the scaling has
changed" or "how it has been implemented differently", as there is no
change in scaling behavior, and no different implementation. This is an
assumption while we investigate the situation described by Joshua above. I
could
Hello David,
>There’s not an official way of forcing the scaling to behave like it used
to be on python 2.7.
Is there an official description, somewhere, of "how the scaling has
changed" or "how it has been implemented differently" ?
Or this change just a side effect of technical choices that