With regarding to the experienced logging message stating: "After handling
this request, the process that handled this request reached the maximum
number of requests that may be handled in a single process' lifetime, and
exited normally."
See my comment in this thread:
Thanks for your replies, Adam and Marcel,
After a few days of experimenting with settings for the automatic scaling
all of a sudden the warm-up requests started to work for us. This is
something I can't really explain. My guess is that this has changed after I
set up some non-zero
Hi
I second Adam's suggestion to use manual scaling in order to not run into
any latency issues. We're running on manual scaling for several years now
and this proved the only scaling method guaranteeing no latency issues.
Eg. when we tried with basic-scaling, we discovered that:
1. There is
Since by your account the module hovers at about 8 instances which all get
proactively restarted at the same time, this suggests that scaling doesn't
happen gradually and that the load on that module is fairly constant.
Keeping a minimum number of idle instances will help with latency spikes
Sure. We use Java, here is the content of appengine-web.xml:
F2
0
6
60ms
120ms
true
true
On Monday, July 18, 2016 at 7:39:25 PM UTC+2, Adam (Cloud Platform Support)
wrote:
>
> Would you mind posting the details from your app.yaml?
>
> On Monday, July 18, 2016 at 11:37:29 AM UTC-4, Iliya
Documentation mention that behavior like so:
> "If warmup requests are enabled for your application, App Engine attempts
> to detect when your application needs a new instance and initiates a warmup
> request to initialize a new instance. However, these detection attempts do
> not work in
Would you mind posting the details from your app.yaml?
On Monday, July 18, 2016 at 11:37:29 AM UTC-4, Iliya Novikov wrote:
>
> Thanks for reply, Martin. I checked with the documentation and according
> to it we have warmup requests configured correctly. Though it reminded me
> of one thing. I
Thanks for reply, Martin. I checked with the documentation and according to
it we have warmup requests configured correctly. Though it reminded me of
one thing. I have never seen a warmup request sent to a running App Engine
application. I can see them only when I deploy a new version. It seems
We have experienced the same problem. It seems that Google changed the way
GAE handles Warmup requests. We solved our issues by adding a warmup
request handler to app.yaml and a small script just echoing an OK message.
The updated documentation page (for PHP runtime), with a working example:
Hi Rajesh,
This is a specific technical question, not a general discussion of the
platform / services and so is off-topic for this forum. It would be better
for you to post this question to stackoverflow http://stackoverflow.com.
Not only will it be on-topic there, but there are a lot more
As a general tip, don't specify *both* kinds of parameters to automatic
scaling: the ones trying to reduce costs (max_idle_instances,
min_pending_latency) *and* the ones trying to reduce latency/improve
scalability (min_idle_instances, max_pending_latency). We'll have a future
blog post about that
I have the following in the appengine-web.xml
instance-classF1/instance-class
automatic-scaling
min-idle-instances2/min-idle-instances
max-idle-instances2/max-idle-instances
min-pending-latency10s/min-pending-latency
max-pending-latency10s/max-pending-latency
/automatic-scaling
Still having these same issues nowadays, this is outrageous.
El lunes, 30 de julio de 2012 16:47:00 UTC+1, Mos escribió:
Anyone else seeing issue with GAE instance management?
In one minute - 10 requests - around 5 instances are started. Old ones
do not response. New instances are created
Sometimes it has happened to me that when I set the min idle instance to 1,
after some minutes it's again set as automatic.without any consent.
Other thing I have tried is to pause the defauls task queue, since
suddently starts to make a lot of requests, however doesn't look to be the
solution
What class of front end instance are you running. You memory use looks high
for a standard front end.
T
On Wednesday, July 3, 2013 4:55:11 PM UTC+8, Stefano Ciccarelli wrote:
I want to add another screenshot:
- why some instances are restarted every few hours?
- why the resident instance is
I'm using F1 and I never had a memory problem, as far as I know, all memory
intensive operations are handled by B2 backends because I had memory soft
limit errors that killed instances. But this is not the case, I think.
2013/7/3 timh zutes...@gmail.com
What class of front end instance are
I would double check that, each of the 3 new instances are all over 150MB,
which is usually where problems start.
An F1 instance memory limit from the docs is
F1 (default)128MB
On Wednesday, July 3, 2013 6:33:19 PM UTC+8, Stefano Ciccarelli wrote:
I'm using F1 and I never had a memory
Ok, as suggested, I've configured the app to use F2 instances, I've
shutdown all the existing instances to let them to upgrade to F2.
As stated in the attached screenshot, besides doubling my costs, I've had
the same problem.
Other ideas?
[image: Immagine in linea 1]
2013/7/3 timh
Ciao Stefano,
This is happening a lot to me this week too:
Appengine is highly unreliable for my app. Specially this week. Things like
this are happening all the time:
http://cl.ly/image/321F2o2o071P
http://cl.ly/image/1O1y3i2l3u3Y
This is just an example of problem that happened while I was
I'm having the same problems. GAE is non-functional for me right now.
On Tuesday, June 25, 2013 7:06:49 AM UTC-4, aswath wrote:
Hello Appengine Team,
http://accountingguru-india.appspot.com customers are facing the latency
issues, and are not able to login to the application.
Logs show
We are experiencing this same issue right now, every petition sent to the
server hosted in appengine is being thrown back with that error.
Could anyone explain why this happens? We have been working fine until
yesterday...
On Tuesday, June 25, 2013 1:06:49 PM UTC+2, aswath wrote:
Hello
+1, Also seeing multiple instance restarts and instance recycling taking
place on my end.
-
-Vinny P
Technology Media Advisor
Chicago, IL
App Engine Code Samples: http://www.learntogoogleit.com
On Wed, Jun 26, 2013 at 3:31 AM, Egolike sys...@egolike.com wrote:
We are
Datastore Errors:
2013-06-25 16:55:32.342
http://www.accounting-guru.net/tenantmgr/listTenant
javax.servlet.ServletException:
com.google.appengine.api.datastore.DatastoreFailureException: internal
error.
at
My Application has been charged TEN TIMES as much every week since mid
february. I have changed NOTHING and I have NO extra customers and NO extra
traffic everything has been stable apart from the fact that my CPU
times have dramatically increased since we started having these instance
Hi John,
Migrating my app to HDR has solved most of the issues! I would highly
recommend to migrate yours ASAP.
The whole migration process was waaay easier than expected. Due to the fact
that the old blobKeys are now alias to the new ones.
thanks
rafa
On Mon, Apr 1, 2013 at 2:34 AM, John V
Thanks Rafa (is this what you have been doing since you vanished from the
tennis scene!! LOL )
I was actually trying to migrate to HRD yesterday, the only trouble is I
wanted to migrate my current M/S appid (idebanet) over to an new appid
(diarybooker) that I already own, the problem is that
Dearest Rafael,
You are living in a dream world if you think migrating to HRD will stop
instances from dying prematurely.
This is not a criticism! Purposeful rejection of reality will save you!
Do not apply reason to the instance scheduler! Here, we call it a
faith-based scheduler.
Have you
Ever since I ported our app to Go, we have had no trouble with the
scheduler aggressively recycling dynamic Java instances (because we have
none).
This may be due to the Go runtime depending on Mermaids instead of Unicorns
and Skittles like the Java stack.
On Monday, April 1, 2013 5:58:05 AM
FWIW, it's probably unwise to feel so strongly about your appid. You have
your own domain, there's no reason for anyone to see the *.appspot.com.
Just use diarybooker-hrd.
There may actually be some advantage in an obscure appid; unless you've
built in precautions or have unguessable version
Good idea Jeff, never considered that.
The only real reason I wanted to use it, is because there have been times
in the past when I have needed to direct my customers direct to the appspot
url and its always a bit embarrassing to send them to my old idebanet
account as its just confusing! one
by the way... i wonder why you are spending 40k a yearit doesn't seems your
site got that much visitor
--
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
Rafael:
Here's the
notice:
http://googleappengine.blogspot.com.au/2012/04/masterslave-datastore-thanks-for-all.html
TOS for
deprecation: https://developers.google.com/appengine/terms#Deprecation
M/S will be turned off 20th April, 2015.
On Thursday, 14 March 2013 15:11:45 UTC+11, Rafael
Stuart,
The service and it's issues are getting worst and worst as we speak:
http://cl.ly/image/2t1y2O2S2U1h (68 dying instances, just starting up by
coincidence)
Can you please give us a word about the issues? Is this going to be
happening on a constant basis? Is it only M/S affected?
By 2015
seeing from your screen capture that the memory usage seems so high... perhaps
an new instance is started when there is no memory left to serve a new request?
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To unsubscribe from this group
Are you running M/S ?
I just had a look at a different app I have access to on M/S (has large
numbers of users) and it appears to be cycling instances fast, and long
startup times.
T
On Wednesday, March 13, 2013 3:58:22 PM UTC+8, Rafael Sanches wrote:
You are living the dream my brother.
You read the previous posts on this right?
You are complaining about instances lasting an hour?
I'd sacrifice my prize unicorn to get that!
When service goes pear shaped, instances last seconds!
Yes. This behavior will change.
No. You can't predict when the change will occur.
No. There's
Barry -
If you look through this message board and at the issue tracker, you'll see
that many people with HRD are also affected by this issue.
As often is the case, the big problem is not the crime - it's the cover-up.
Everyone here can understand technical issues, if people are working to
Or even if Google says that there is not a technical issue; that there have
been internal tweaks to the scheduler that make instances that (in my case)
would happily serve for days or weeks to now serve for less than 10-15
minutes (during a good part of the day); and that we should do a, b,
That's you projecting your hopes, that someone is calmly fixing the
problem.
But one of the attributes of competent leadership is effective
communication. When customers see that effective communication is lacking,
they a symptom of poor leadership. If appengine has poor leadership, this
This is my biggest concern. I don't care about technical problems, I care
about shipping high quality products. That was the reason why we picked
appengine 2 years ago.
The problem is that the service isn't working well and we can't predict for
how long. We need to have any insight on how long
I believe it would be less work to move out of appengine rather than
moving to HDR.
You will have to do one or the other soon anyway. M/S will be turned off.
--
You received this message because you are subscribed to the Google Groups
Google App Engine group.
To unsubscribe from this group
I am uncertain about GAE given recent history, but have hope. Certainly
given MS is deprecated, we cannot hold G. accountable for issues there.
They **clearly** recommend HR, so MS app are 100% caveat emptor. However,
the SO and Google Groups threads recently have been consumed with ire not
Do you have billing enabled ?
idle instance can be shut down at any point where their count is above min
idle. What sort of settings are you running ?
I have a low traffic site with billing usually 1 or 2 reserved instances
(depending on the time of the week.) All content is dynamic (though
Yes, I have a lot of traffic. Out of nothing the instances die and new ones
come up. Check out this screenshot: http://cl.ly/image/3e1W1a1d0V3A
Please, see that some instances are up for more than an hour and a half.
Although, many new ones are spawned.
You're running on HDR? The may be related
Quite some time ago I started a thread about instances for my paid app
shutting down quickly (almost immediately). Same issue I believe. Perhaps
it is working differently now, but I would be hesitant to conclude that
this will stop occurring once billing is activated. It seems quite
variable,
Can you screenshot an AppStats profile view of a sample request?
-Vinny
On Tuesday, March 12, 2013 12:23:35 AM UTC-5, Rafael Sanches wrote:
Hello,
I have the application yumyumlabs and all of my users are complaining
about slowness or broken connections.
To my surprise I went to the
Hi
I am using HRD and usually my resident instances are many days old, however
today I have one resident instance 2 hours old, 1 dynamic instance 2 hours
old, and a dynamic instance 1.5 days old ;-)
T
On Tuesday, March 12, 2013 6:06:15 PM UTC+8, Rafael Sanches wrote:
Yes, I have a lot of
Star this issue
http://code.google.com/p/googleappengine/issues/detail?id=8931
--
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
And never, ever, feed your unicorns Starburst candy.
David
On Tuesday, March 5, 2013 4:12:08 PM UTC-7, vlad wrote:
Star this issue
http://code.google.com/p/googleappengine/issues/detail?id=8931
--
You received this message because you are subscribed to the Google Groups
Google App Engine
To paraphrase johnP, This afternoon is a serving train-wreck.
My poor unicorns' tongues are raw from gorging on Sour Skittles(tm).
David
On Friday, March 1, 2013 7:32:29 PM UTC-7, Cesium wrote:
I'm sure you noticed the question on this forum that Takashi did respond
to.
On Friday,
Just watch http://www.youtube.com/watch?v=4vuW6tQ0218
Whenever you hear Dead Parrot, in your mind think Dead Instance.
It is a very accurate representation of Google's response to this issue to
date.
On Monday, March 4, 2013 4:35:32 PM UTC-8, Kiran Nanisetti wrote:
My app id is
Hello Takashi,
any feedback for us?
Cheers
Mos
On Thu, Feb 28, 2013 at 1:06 PM, Mos mosa...@googlemail.com wrote:
Trust me; Google has no clue what's going on.
The instance scheduler went crazy, people have downtimes and have
increased billing (for weeks!)
If Google would be able to track
I have sacrificed several unicorns and prayed fervently to the Google Gods,
but this morning instances are thrashing badly; living no more than a
minute or so.
Google really needs to figure out the underlying issue, and also start
communicating with their customers more effectively. The
This morning is a serving train-wreck here, too.
On Wednesday, February 27, 2013 7:50:47 AM UTC-8, Kinesh Patel wrote:
On Python 2.7 paid app. Setting an idle instance seems to mitigate this,
but every time a new dynamic instance is spawned or hit i get this problem.
Definitely not
I am porting to Go. Then I care much less about the instance scheduler
committing unicorn genocide.
Almost done.
RIP GAE/J, thanks for wasting my dev time replacing you!
On Friday, March 1, 2013 9:28:13 AM UTC-8, johnP wrote:
This morning is a serving train-wreck here, too.
On
I'm sure you noticed the question on this forum that Takashi did respond to.
On Friday, March 1, 2013 11:47:21 AM UTC-7, Carl Schroeder wrote:
I am porting to Go. Then I care much less about the instance scheduler
committing unicorn genocide.
Almost done.
RIP GAE/J, thanks for wasting
Trust me; Google has no clue what's going on.
The instance scheduler went crazy, people have downtimes and have
increased billing (for weeks!)
If Google would be able to track the problem (or would have a clue how
to fix it),
they would give a comment.
As I wrote. That's not the first time. Last
+1 to Mos
Trust me; Google has no clue what's going on.
The instance scheduler went crazy, people have downtimes and have
increased billing (for weeks!)
If Google would be able to track the problem (or would have a clue how
to fix it),
they would give a comment.
As I wrote. That's not the first
Mos makes some good points and states them clearly.
However, my idea of Faith Based Scheduler Maintenance seems to be yielding
pretty good results.
David
On Thursday, February 28, 2013 5:06:00 AM UTC-7, Mos wrote:
Trust me; Google has no clue what's going on.
The instance scheduler went
Starting about 16:30 Pacific time, my Java HRD Instances were shutting down
after just a few seconds.
Just as my rage reached class IV, serving returned to normal.
I know this is an overreaction, but I may have to sacrifice a unicorn.
Please, please, App Engine team, spare Mr. Sparkles.
Oh Joy,
Now the console charts have been erased.
I'm losing it.
Unicorn liver pate for dinner.
David
On Wednesday, February 27, 2013 6:10:37 PM UTC-7, Cesium wrote:
Starting about 16:30 Pacific time, my Java HRD Instances were shutting down
after just a few seconds.
Just as my rage
A couple hours later, all is well.
Instances are lasting.
Latency is low.
Thank you Mr. Sparkles. (burp).
On Wednesday, February 27, 2013 6:45:50 PM UTC-7, Cesium wrote:
Oh Joy,
Now the console charts have been erased.
I'm losing it.
Unicorn liver pate for dinner.
David
On
Many apps are hitting the same issue, starring the following may increase
chances of getting resolution. The app engine performance is unpredictable.
Right now, as far as we are concerned, the most effective solution is to
offer prayers very sincerely every morning.
Hi Jeff,
thanks for the feedback!
This looks like a startup request that is taking too long - is that the issue?
No, not really. It's an instance that is already up. It happens
suddenly from time
to time.
Please check (and star)
http://code.google.com/p/googleappengine/issues/detail?id=7982
There are other data storage technologies that are optimized for rapid
updates to atomic data. Redis, Mongo, and of course traditional
RDBMSes solve this problem pretty easily for most typical scaling
needs. There isn't an equivalent tool in the GAE toolbox.
CloudSQL. That is a
The last two days the instances kept unstable. Today I kill all
instances hopping this helps. But 3 instances spanned up again and now
every second request to the application fails with the known GAE
problem:
com.google.apphosting.api.DeadlineExceededException: This request
(9706ce3068c95802)
On Mon, Aug 20, 2012 at 9:43 AM, Barry Hunter barrybhun...@gmail.com wrote:
CloudSQL. That is a 'traditional RDBMS' :)
https://developers.google.com/cloud-sql/
Except as we've experimentally seen when testing Richard's game, Cloud
SQL has significant per-instance throughput limits. I don't
Is that the full stacktrace?!?
Jeff
On Mon, Aug 20, 2012 at 12:15 PM, Mos mosa...@googlemail.com wrote:
The last two days the instances kept unstable. Today I kill all
instances hopping this helps. But 3 instances spanned up again and now
every second request to the application fails with the
Is that the full stacktrace?!?
No, here is one example:
com.google.apphosting.api.DeadlineExceededException: This request
(681ae7cef438e16b) started at 2012/08/20 16:30:31.376 UTC and was
still executing at 2012/08/20 16:31:30.903 UTC.
at
This looks like a startup request that is taking too long - is that the issue?
If so, it could be yet another blip in startup times - as I (and
others) have complained many times in the past, there seems to be a
lot of variance in startup times. 20s today could be 60s deadline
failures tomorrow.
Oh, and if you haven't already, star these issues:
http://code.google.com/p/googleappengine/issues/detail?id=7706
http://code.google.com/p/googleappengine/issues/detail?id=7865
Jeff
Random not-so-amusing anecdote: My app, voo.st, is also down right
now - not because of appengine, but because
As a Spring user on GAE, the best thing I've done is disable the annotation
driven context:component-scan. It's a hassle migrating everything from
@Component and @Autowired to bean class=x.y.Z.../bean, but now
Spring's FrameworkServlet initializes in 15 seconds including Objectify
instead of
@pphalen just remember, you're reading replies from other developers, which
are often biased (e.g. to a specific programming language) or coming from a
different background; others wear mermaid costume; etc.
For instance,
Nothing in the datastore can change faster than once per second;
is
On Sun, Aug 19, 2012 at 4:47 AM, alex a...@cloudware.it wrote:
Nothing in the datastore can change faster than once per second;
is true only in case of a single entity group. So, you're better off reading
official docs.
Perhaps I wasn't clear enough - that's my entire point. No _single
Add again. The last 48 hours the scheduler creates and closes
instances without reason (traffic as usual, no software updates, no
special tasks)
That's definitely not a WorkAsIntended issue!
As a result instance hours go up and we have to pay again for GAE's
fault. Great business-model: Let
Have you set the _min_ idle instances to something other than
automatic? This setting seems to be especially catastrophic for a
low-traffic app.
Jeff
On Sat, Aug 18, 2012 at 8:56 AM, Mos mosa...@googlemail.com wrote:
Add again. The last 48 hours the scheduler creates and closes
instances
Hi Jeff,
min-idle instance is on automatic. Max is on two.
There is at least one request per minute for my low-traffic app,
From my perspective a very straight-forward application that shouldn't
have any problems on GAE. (Check: http://www.krisentalk.de/ if you
can speak German. ;) )
I'm
On Sat, Aug 18, 2012 at 2:21 PM, Mos mosa...@googlemail.com wrote:
I'm surprised that you are still go with GAE for new applications?
You had your own experiences from what I saw on this list. ;)
I'm not recommending GAE anymore. I tell my customer to go with other
platforms. After one year
Someday when I have more time I might write a short GAE Survival
Guide and sell it for a few bucks as an ebook.
That's seems to be a good motivation to invest so much time in GAE
issues. ;) I would had bought the book one year ago
On Sat, Aug 18, 2012 at 10:19 PM, Jeff Schnitzer
Apps with a lot of rapidly mutating aggregation are hard.
Hi, I'm new to app engine, so this is news to me. Could you please
characterize a bit more? E.g., what is a lot?
On Saturday, August 18, 2012 1:19:51 PM UTC-7, Jeff Schnitzer wrote:
On Sat, Aug 18, 2012 at 2:21 PM, Mos
On Sat, Aug 18, 2012 at 8:59 PM, pphalen patrick.pha...@gmail.com wrote:
Apps with a lot of rapidly mutating aggregation are hard.
Hi, I'm new to app engine, so this is news to me. Could you please
characterize a bit more? E.g., what is a lot?
Nothing in the datastore can change faster than
Subject: [google-appengine] Re: Instances/Java go crazy
Again a not very reliable GAE month:
Pingdom July
Uptime Downtime Outages Response time
99.90% 0h 43m 35s 27 466 ms
On Wed, Aug 1, 2012 at 11:50 PM, Mos
Again a not very reliable GAE month:
Pingdom July
Uptime DowntimeOutages Response time
99.90% 0h 43m 35s 27 466 ms
On Wed, Aug 1, 2012 at 11:50 PM, Mos mosa...@googlemail.com wrote:
And again I have to pay for GAE issues:
On Jul 30 the Frontend Instance
And again I have to pay for GAE issues:
On Jul 30 the Frontend Instance Hours goes beyond the free limit.
First time this week in my application history. Remember: The application was
unusable on this day because GAE starts instances like crazy (on low traffic).
Frontent Instance Hours were
On Monday, 21 November 2011 10:25:34 UTC-8, WallyDD wrote:
I am little confused with how these instances work.
How long does an instance stay alive?
A site in Python 2.5 (M/S) fires up an instance when it is accessed
and the instance stays alive for minutes after.
With Python 2.7(HRD) the
Hi Anand,
Thank you for the response.
I am not concerned with being charged for the full 15 minutes for when
instances start and stop (or as you described), what I am concerned
with is the start-up time it takes each time an instance is fired up.
A browsing session while testing looks something
this is entirely manageable.
-Original Message-
From: google-appengine@googlegroups.com
[mailto:google-appengine@googlegroups.com] On Behalf Of WallyDD
Sent: Tuesday, November 22, 2011 7:26 PM
To: Google App Engine
Subject: [google-appengine] Re: Instances - How do they work?
Hi Anand,
Thank you
I have logged this as two separate issues;
http://code.google.com/p/googleappengine/issues/detail?id=6391
http://code.google.com/p/googleappengine/issues/detail?id=6390
On Nov 21, 1:25 pm, WallyDD shaneb...@gmail.com wrote:
I am little confused with how these instances work.
How long does
Hey Simon,
I know it is documented on the backends page:
http://code.google.com/appengine/docs/python/backends/overview.html#Properties_of_Backends
I'm not sure it is documented anywhere else. They are aligning the
front-end instances with the most low-end backend instance:
There is a function, get_stats(), that gives you some data about your
memcache usage, including the total size of stored data. You might want to
run a test by starting as much as you can in memcache while watching the
total stored data and when that hits a ceiling, you'll know how much is
Robert, where did you get the 128MB limit from? Is this limit only in
effect when the new billing comes in?
I noticed in the recent IRC chat log that Ikai mentioned that they had
noticed more applications hitting a 180MB soft limit, reduced from 200MB,
with a 300MB hard limit.
--
You
Oh, I just read that memcache is constant across instances.
On Sep 9, 12:43 pm, jay kyburz@gmail.com wrote:
Quick question,
In my app users do work on some data. Every action they do I have to
pull the data out of the datastore, unpickle it, do the transform,
pickle it again and put it
Hi Jay,
Correct, memcache is global to your app. The same user's requests
could go to any of your instances. So caching user datain local
memory is probably not worth it.
Robert
On Thu, Sep 8, 2011 at 21:51, jay kyburz@gmail.com wrote:
Oh, I just read that memcache is constant
do we know how big the memcache is? It would be good to know roughly
how much data we can jam in there.
On Sep 9, 3:26 pm, Robert Kluin robert.kl...@gmail.com wrote:
Hi Jay,
Correct, memcache is global to your app. The same user's requests
could go to any of your instances. So caching user
Hi Robert,
After all, thank you for your recomendation of use Appstats. I'm going to
use it.
Undeploy application doesn't mean lose an instance because I see a lots of
loading request in my logs. We've developed a warm up servlet to start up
the application into dynamic instances when I've
Hey Eduardo,
Do you see lots of errors or warning messages in your logs?
Specifically about the instance being killed?
Robert
On Wed, May 4, 2011 at 02:18, Eduardo Perrino eduardo.perr...@gmail.com wrote:
Hi Robert,
After all, thank you for your recomendation of use Appstats. I'm going
On May 3, 11:55 am, Eduardo Perrino eduardo.perr...@gmail.com wrote:
Hi Robert,
I try to explain better:
Our application has 16 instances assigned by appengine automatically and
three of them are always on. It doesn't have many requests, in fact, the
time between them is large enough to
2011/5/3 Geoffrey Spear geoffsp...@gmail.com
On May 3, 11:55 am, Eduardo Perrino eduardo.perr...@gmail.com wrote:
Hi Robert,
I try to explain better:
Our application has 16 instances assigned by appengine automatically and
three of them are always on. It doesn't have many requests,
Hi Eduardo,
It sounds like you might benefit from using Appstats. I've heard
Java apps tend to have large startup times. However, from what you're
describing it sounds like your app is getting new instances spun up
(16 in total) but it is not serving requests quickly enough. At least
if I
Can anybody else explain me this pending_ms information especially for
task with cold start and how it is related to average latency ? If it
is somewhere explained could you provide me with links to it ?!
I remember times (two years ago) where group discussions were much
more dynamic and you
1 - 100 of 105 matches
Mail list logo
