I recently migrated to endpoints framework version 2 and started paying
closer attention to latency. In my case I have a very low traffic app. I
even tried just using the standard python echo example found here:
looks like the pending MS logs mystery was solved:
https://groups.google.com/forum/#!topic/google-appengine/8mHxjsSCOYc so if
you don't see that in your logs you can rule that out as a problem.
On Friday, July 29, 2016 at 10:04:47 AM UTC-7, Christian F. Howes wrote:
>
> A helpful stat would be
A helpful stat would be the "pending latency" (the amount of time that
the request waited for an available instance to run on). This was part
of the logs in the old log viewer and is missing is the new log viewer.
i believe someone has filed an issue requesting that it be re-added.
if any of
We have our application
Java, flexible env - autoscaling
Almost all of our logs show the following statistics
ms=346 cpu_ms=0 cpm_usd=1.32769e-7 loading_request=0 instance=-
app_engine_release=1.9.42 trace_id=-
Our users face front end latency. Is it any server issue Or any corrective
measures
but my latency is only below 1.5 seconds when i looked at the log that's ok
for me, i have an issue with the time taking for the prepossessing or is it
the same thing, i will start a new thread with issue anyway
On Wednesday, July 27, 2016 at 9:35:18 AM UTC+5:30, Trevor wrote:
>
> I simply
I simply followed the advice kindly offered in this thread and experimented
with lowering the max concurrent requests. Our best settings ended up being 2
max concurrent requests with 2 max idle instances.
I think an important part is that before this tweaking, we separated our
front-end and
can you explain what did you do to reduce the latency, i have the same
issue?
On Thursday, June 30, 2016 at 3:14:34 PM UTC+5:30, Trevor wrote:
>
> Well, I have to say thank you very, very much. Thanks to your advice we
> have our lowest latency in 3 years! Sub 300ms average. As expected
Hi,
Our team has the same issue, and it is still bothering us a lot.
Please see the issue.
https://code.google.com/p/googleappengine/issues/detail?id=12564
It was raised with the Google Appengine production team.
To support the Google team for the evidence, our team slimmed down our
project and
Thank you so much for this! We also got bitten hard by this problem
seemingly out of nowhere in the last few weeks. The same request latency
varying from 200ms to over 10,000ms in some cases, with no obvious reason
except mysterious gaps in the traces. It's a hard one to debug - there's no
2 thoughts:
- remember that when servicing multiple simultaneous requests the CPU is
switching between them. I bet the pauses are (in part) due to waiting for
a turn on the CPU - your request got "paused" while the memcache call was
made, and then had to wait for CPU once the memcache
Hey Folks,
As for the amount of concurrent requests an instance can handle, it depends
on the CPU usage on the instance, and the number of concurrent requests the
instance can handle is dependent on that, and the distribution of requests
to instances is also dependent on statistical trends in
One thing I noticed is that the first request(s?) served by a fresh
instance will always be really slow. Not that they stay in the request
queue for a longer time (which is expected behaviour of course), but they
have long "pauses" in the middle of the request as you mentioned before,
usually
Great to hear that it helps. Actually, if you are using F4s, I might try a
slightly higher max_concurrent_requests , say 4. Again, test and compare to
be sure.
Finally, to reduce costs, I would recommend to set max_idle_instances to 1.
Keep min_idle_instances to what you need for your
Well, I have to say thank you very, very much. Thanks to your advice we
have our lowest latency in 3 years! Sub 300ms average. As expected though,
we are now sitting on 21 billed f4 instances, which will potentially cost
us in the order of 3x our current ($30-40 -> $100+), but we will tweak
Right, you should definitely test and see what the results are. My first
inclination was also to increase max_concurrent_requests, but because then
all those requests have increased latency, the actual QPS per instance
decreased! Lowering max_concurrent_requests decreased request latency, so
Thanks for the advice! I hadn't considered setting it that low because we
are on F4 instances and I would really, *really* hope that they could
handle at least the default 8 concurrent requests. That being said, I will
throw the front-end on those settings this evening and monitor until noon
I recommend trying to set max_concurrent_requests to 2. As you said, higher
values only makes latency (much) worse. In our experience, a value of 2
gets the best latency results without an increase in cost.
We still have some of those pauses mid-request in a trace, and I really
would like to
17 matches
Mail list logo
