The GAE classloader does some security checking that isn’t present in the dev container. Plus actual loading of classes from jars seems to be slower (probably some sort of network filesystem is involved). 5-10s startup time locally is quite long; a corresponding 30-60 server-side seems realistic, even with F4s. Things to avoid, if you can: Classpath scanning, AOP. Both seem to slow things down.
Also: I have always found Bad Things happen when trying to use resident instances. At lower traffic levels, it seems to produce _more_ cold start requests rather than less. I’ve had the best user experience leaving all automating scaling settings at their default - for both high traffic and low traffic apps. Jeff On Wed, Oct 26, 2016 at 9:11 PM, Vidya <vi...@thesilverlabs.com> wrote: > Let me try to understand this correctly. There is a general set of best > practices for being efficient with latencies - including trying to do batch > requests wherever possible and storing data in memcache to avoid a lot of > datastore queries and so on. > > And then there is the question of what causes the latency spikes at the > time of an instance starting up. We have observed specific spikes that > occur only when a new instance is started. If I understand what you wrote > correctly, you appear to be saying that if there are any external URL > fetches, those calls will need to wait for the instance to startup before > they can be handled - is that right? I am assuming any Image Service calls > will be considered external server calls as well? > > A separate question is why the instance takes 30-60s to come up when our > application startup times on a local machine or compute engine instance are > in the order of 5-10s - what could be causing a 6x increase in startup > times? Given we are on F4 instances, this sounds very strange. > > Thanks, > Vidya > > On Tue, Oct 25, 2016 at 7:54 AM, 'Jordan (Cloud Platform Support)' via > Google App Engine <google-appengine@googlegroups.com> wrote: > >> Resident Instances turning into Dynamic Instances to handle requests does >> not effect the time required to start an instance (it is actually designed >> to help it). When a new Idle Resident Instance is required, an >> '/_ah/warmup' will be sent to your application. This will trigger the >> creation of a new instance, and your code will begin to run. Therefore if >> you are seeing high latency during instance startup, it is likely your code >> that is the cause. >> >> You can use the Stackdriver Trace >> <https://cloud.google.com/trace/docs/viewing-details> tool to sort >> requests to your application over a period of time by highest latency. You >> can then select the requests with the highest latency which will show you >> the actual processes that ran during the request. If your code makes any >> URL Fetch requests to other applications or servers, this forces your app >> to wait for this external service to run, causing higher latency. Multiple >> individual calls to other Google services such as the Datastore may also >> cause latency. It is recommended to perform batch requests >> <https://cloud.google.com/datastore/docs/concepts/entities#batch_operations> >> to any Google service that supports it, in order to reduce the amount of >> calls your application makes. By optimizing the time needed to execute your >> code, the latency experienced by an incoming request will be reduced. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Google App Engine" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/google-appengine/0ZBLsyc51gk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> google-appengine+unsubscr...@googlegroups.com. >> To post to this group, send email to google-appengine@googlegroups.com. >> Visit this group at https://groups.google.com/group/google-appengine. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/google-appengine/d4baf583-826f-45b3-b139-1f47e699697e% >> 40googlegroups.com >> <https://groups.google.com/d/msgid/google-appengine/d4baf583-826f-45b3-b139-1f47e699697e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-appengine+unsubscr...@googlegroups.com. > To post to this group, send email to google-appengine@googlegroups.com. > Visit this group at https://groups.google.com/group/google-appengine. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/google-appengine/CADf2OP7eVBdg%3DfoNOpBfSU8dFdTV9BWS86bqGpM_ > jxpc%2Bb-fjw%40mail.gmail.com > <https://groups.google.com/d/msgid/google-appengine/CADf2OP7eVBdg%3DfoNOpBfSU8dFdTV9BWS86bqGpM_jxpc%2Bb-fjw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CADK-0uggbm4TnrPJR%3DfJpsRyYWN1mEk%3DJRew7xTV3z2cquKpkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
