Dear all, I've found this in the FAQ: http://code.google.com/intl/en/appengine/kb/java.html#Can_I_Pay_To_Reserve_My_JVM
"Can I pay to keep a JVM reserved for my application? We've seen this request from some developers with low-traffic applications who'd like to reduce the percentage of loading requests they receive. Although we have many improvements in the pipeline to improve loading request performance, we'd like to gauge the general interest in this feature. If you'd like to be able to reserve a JVM at a price, please star this issue: http://code.google.com/p/googleappengine/issues/detail?id=2456. If there's a particular pricing scheme you're interested in, let us know." Cheers, Guillermo. On 22 mar, 10:21, Guillermo Schwarz <guillermo.schw...@gmail.com> wrote: > > My wild guess is that Google still has some work to do in terms of balancing > > the load and preventing poorly written code in one app from causing pain for > > other apps. > > Not really. The load balacer is working fine. When the application is > loaded it is incredibly fast, so the load balancer must be working > right. The problem is when the app is being loaded. > > In order to load the app, a kind of core file must be read from disk > in order to represent the app state in RAM. That process takes too > long (used to be up to 3 secs, now it is up to 12 seconds AFAIK) > because: > > 1. Some applications can't be unloaded at all (they are using the > queue to ping themselves) which leaves less free RAM. When apps ping > themselves GAE shouldn´t take those pings into account in order to > free some memory. > 2. The disk reading takes a lot of time. Probably this shouldn't take > longer than 500 ms. Let me explain. Even if the war file is huge, it > can be divided in multiple disks and loaded very fast. Probably using > SSDs would speed things up a bit. > > I haven't seen the logs of GAE (not of the apps but of GAE itself) but > I guess one of those problems is consuming most of the time. > > Cheers, > Guillermo. > > On 22 mar, 09:30, "James Koch" <jamesk...@gmail.com> wrote: > > > Jake, > > > I don't know enough about the GAE internals to do anything more than > > speculate on root causes and interactions between the symptoms I've seen. > > Unfortunately Google staff have their lips sealed. Don Schwartz engaged > > with me for a few hours, asked me some questions, then went silent for two > > weeks now and hasn't responded to my follow-up. > > > My wild guess is that Google still has some work to do in terms of balancing > > the load and preventing poorly written code in one app from causing pain for > > other apps. > > > James > > > -----Original Message----- > > From: google-appengine-java@googlegroups.com > > > [mailto:google-appengine-j...@googlegroups.com] On Behalf Of Jake > > Sent: Friday, March 19, 2010 8:56 AM > > To: Google App Engine for Java > > Subject: [appengine-java] Re: App instance recycling and response times - is > > there solution? > > > Hey James, > > > Also thanks for the clarification. It hadn't occurred to me that what > > appeared to be frequent restarts could be an additional JVM. I'm > > still not entirely familiar with that concept, but I get the basic > > idea that requests served to the same client may not always come from > > the same instance of my application. As the only traffic I've seen > > is...me...I just assumed it was all one instance. > > > Anyways, are issues #1-4 really linked together? I'm less concerned > > about slow startup than constant startup. Also, while I haven't read > > the ENTIRE thing, Issue #2456 talks about paying to keep a warm JVM, > > which I'm not interested in... I don't mind a 6-10 (or 15 second) > > delay on the first request in, say, the span of an hour. I just mind > > it when it's every single request. > > > Jake > > > On Mar 18, 1:44 pm, "James Koch" <jamesk...@gmail.com> wrote: > > > In my short time using GAE I've seen several issues discussed under the > > > label "response times". The lines between these issues are fuzzy, and we > > > aren't all talking about "response times" using the same semantics. As an > > > example, Jake, you might not be seeing frequent restarts, you could also > > be > > > seeing spinup of additional JVMs (even though you're low-traffic like me). > > > > Maybe enumerating them will help us all pull in the same direction? Here > > > are the issues I've seen mentioned: > > > > 1 - Slow JVM startup speed (5-7s for something that uses JDO and no other > > > frameworks) > > > > 2 - Not affecting me personally, but startup cost of other frameworks > > > (Struts, etc.) has definitely been mentioned. > > > > 3 - Frequent JVM restarts (after 1 min of inactivity) - This interval > > feels > > > too short to me, as a small app developer. > > > > 4 - Frequent "server overload" caused by OTHER apps, which cause a request > > > to be re-routed to a new JVM instead of a warm one, thus incurring the > > > startup penalty regardless of user activity levels. > > > > 5 - "Request was aborted after waiting too long" on normally fast-loading > > > pages. Presumably similar to #3 (caused by "server overload" from OTHER > > > apps) but something else is awry here as these occurs often occur after > > only > > > 10s, not the expected 30s. If you've got a 7s JVM spinup, that doesn't > > > leave you a lot of wiggle room. Also, this only shows up in logs as a > > > "warning". IMO, if a user can't receive a response, that's an "error". > > > > Issue tracking: > > > #5 covered by Issue #2396. > > > #1-4 all munged together in massive Issues #2456 > > > > James > > > > -----Original Message----- > > > From: google-appengine-java@googlegroups.com > > > > [mailto:google-appengine-j...@googlegroups.com] On Behalf Of Jake > > > Sent: Thursday, March 18, 2010 12:56 PM > > > To: Google App Engine for Java > > > Subject: [appengine-java] Re: App instance recycling and response times - > > is > > > there solution? > > > > Hey, > > > > So, I've noticed several users complaining about *frequent* restarts, > > > not long restarts. I created this issue awhile back but no one has > > > starred it. My impression from the Google developers I've talked to > > > is that this is not common enough to become a priority. If you > > > disagree, star the issue. > > > >http://code.google.com/p/googleappengine/issues/detail?id=2931 > > > > If it truly isn't common, then I'll probably just end up creating > > > another account and redeploying since it has been established that my > > > application isn't the cause. > > > > Jake > > > > On Mar 17, 11:35 pm, James Koch <jamesk...@gmail.com> wrote: > > > > As a followup, today (3/17) from 1-3PM PST I received several > > > > instances of "Request > > > > was aborted after waiting too long to attempt to service your request." > > > This > > > > is on my app w/ zero users, just 3 requests/minute of a blank page as a > > > test > > > > load. > > > > > On Thu, Mar 11, 2010 at 1:50 PM, Don Schwarz <schwa...@google.com> > > wrote: > > > > > Can you respond privately with your app id? > > > > > > On Thu, Mar 11, 2010 at 10:10 AM, James <jamesk...@gmail.com> wrote: > > > > > >> I setup some pings of my add a few minutes ago, and I'm still seeing > > > > >> recycling :( > > > > > >> My ping setup can't go lower than 60s intervals, so I have two > > running > > > > >> concurrently. Here's a sample of 20 log entries over 10 minutes, > > > > >> with . Three recyclings occur, and they happen less than 10s after a > > > > >> previous request. Really Google, you're killing my JVM after TEN > > > > >> SECONDS? And I get to pay you for the ton of CPU each startup uses? > > > > >> Sounds like the more recycling, the more profitable the App Engine > > > > >> becomes. > > > > > >> - > > > > >> * 03-11 08:02AM 38.506 /?Pragma=no-cache 200 2158ms 2235cpu_ms 0kb > > > > >> Site 24 X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 08:02AM 23.144 /?Pragma=no-cache 200 53ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 08:01AM 06.134 /?Pragma=no-cache 200 75ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 08:00AM 51.707 /?Pragma=no-cache 200 49ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 08:00AM 05.823 /?Pragma=no-cache 200 49ms 58cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:59AM 51.499 /?Pragma=no-cache 200 56ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:59AM 05.584 /?Pragma=no-cache 200 47ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:58AM 51.274 /?Pragma=no-cache 200 61ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:58AM 05.371 /?Pragma=no-cache 200 64ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:57AM 51.025 /?Pragma=no-cache 200 74ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> * 03-11 07:56AM 57.327 /?Pragma=no-cache 200 7835ms 2119cpu_ms 0kb > > > > >> Site 24 X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:56AM 50.784 /?Pragma=no-cache 200 75ms 58cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:55AM 57.008 /?Pragma=no-cache 200 50ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> * 03-11 07:55AM 46.384 /?Pragma=no-cache 200 4250ms 2060cpu_ms 0kb > > > > >> Site 24 X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:54AM 56.782 /?Pragma=no-cache 200 70ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:54AM 46.157 /?Pragma=no-cache 200 54ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:53AM 56.586 /?Pragma=no-cache 200 52ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:53AM 45.934 /?Pragma=no-cache 200 51ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:52AM 56.240 /?Pragma=no-cache 200 62ms 38cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> 03-11 07:52AM 45.718 /?Pragma=no-cache 200 57ms 19cpu_ms 0kb Site 24 > > > > >> X 7 RPT-HTTPClient/0.3-3E,gzip(gfe) > > > > >> - > > > > > >> On Jan 30, 11:02 pm, Alyxandor <a.revolution.ultra.b...@gmail.com> > > > > >> wrote: > > > > >> > If you are experiencing failed requests on your long-running / > > > > >> > requests, consider performing some kind of "pre-warming" procedure > > of > > > > >> > your own... If you are getting timeout errors, Ping a do-nothing > > > url, > > > > >> > and wait for it to return before running the big job. If it's a > > big > > > > >> > job, users should expect to wait anyway {and you should tell them > > > they > > > > >> > are waiting!}, so the ping ensures {almost} that a warm JVM is > > > running > > > > >> > in the server nearest said users, and then the big /request can > > > > >> > {usually} avoid > > ... > > leer más » -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
