It is almost intolerable for user experience with 1 idle instances running

81 views
Skip to first unread message

Tapir

unread,
Sep 29, 2011, 7:25:56 PM9/29/11
to Google App Engine
and with "Max Idle Instances" set as 3.

There MUST be a bug in gae instance scheduler.
If it is not a bug, it MUST be a bad implementation.

After some researches, I find If there is only one instance is
running,
the scheduler always avoids using it to handle a new coming request,
even if the idle instance is idling.
Instead, the scheduler always tries to open a new instance to handle
the new coming request.
As a result, the visitor must wait 15s to load the page.

This problem is intolerable specially for websites with very small
traffic. Almost very visit will wait for 15 seconds.

How a good scheduler should do?
1. always use the current idle instance if it is available.
2. at the same time, create a new instance for potential new
concurrent requests.
It is just that simple.

Tapir

unread,
Sep 29, 2011, 7:29:57 PM9/29/11
to Google App Engine

On Sep 30, 7:25 am, Tapir <tapir....@gmail.com> wrote:
> and with "Max Idle Instances" set as 3.
>
> There MUST be a bug in gae instance scheduler.
> If it is not a bug, it MUST be a bad implementation.
>
> After some researches, I find If there is only one instance is
> running,
> the scheduler always avoids using it to handle a new coming request,
> even if the idle instance is idling.
> Instead, the scheduler always tries to open a new instance to handle
> the new coming request.
> As a result, the visitor must wait 15s to load the page.
>
> This problem is intolerable specially for websites with very small
> traffic. Almost very visit will wait for 15 seconds.
A spelling error here. It should be "Almost every visit"

Tim Hoffman

unread,
Sep 29, 2011, 8:23:46 PM9/29/11
to google-a...@googlegroups.com
I have a site, with max idle set to 1, and Min Pending Latency set to 500ms, and I find performance is great.

It takes 3-4 secs normally to start the full app up, but through smart caching (I can start a cold instance and serve many pages directly from memcache without starting the full stack in less than <200ms.)

I suggest you spend some time having a look at your app startup performance, and profiling your app, 
rather than spending your time posting the multitude of odd complaints all over the place.

Tim

Tapir

unread,
Sep 29, 2011, 8:30:28 PM9/29/11
to Google App Engine
This problem is non-app-optimization related.

Tapir

unread,
Sep 29, 2011, 8:41:43 PM9/29/11
to Google App Engine
with with "Max Idle Instances" set as 1 instead 3.
The user experience is better now. ^_^

On Sep 30, 7:25 am, Tapir <tapir....@gmail.com> wrote:

Tim Hoffman

unread,
Sep 29, 2011, 9:00:38 PM9/29/11
to google-a...@googlegroups.com
Unfortunately in all your posts, you provide little background.

So we have contextless complaints, its difficult to work out what you
have done, and I won't assume you have done things like optimisation.

Also are you handling warmup requests ?

T

Tapir

unread,
Sep 29, 2011, 9:18:19 PM9/29/11
to Google App Engine
This is really not an app optimization problem.

And about the app optimization,
I use struts2 framework, which makes reducing the startup time less
than 10 seconds is almost impossible.
And yes I haven't use memcache heavily, but which is almost helpless
for reducing the startup time.

>
> T

Tapir

unread,
Sep 29, 2011, 9:21:34 PM9/29/11
to Google App Engine
Yes I use the "warmup requests" feature,
but I think it will make the problem worse.

JH

unread,
Sep 29, 2011, 9:34:47 PM9/29/11
to Google App Engine
Tim,

Can you elaborate on what you mean by "smart caching" ? You start
serving pages before your full stack has started?

Tim Hoffman

unread,
Sep 29, 2011, 9:41:52 PM9/29/11
to google-a...@googlegroups.com
Maybe you shouldn't use struts, this is a serious suggestion, and should be considered seriously.
If you have a lightly used small app using a heavy framework then you have probably made a bad design choice.

If you have long startup times then warmup requests do help enormously, and in fact are about the only way you are
going to improve the use experience.

Also if you have such large startup times, then you should probably have more than one idle instance.

I would also examine you software stack and see if you can at least serve the home page/landing page 
directly from memcache without starting struts up.
The have on that same page some images that will be loaded after the html is loaded, and serve these from the 
full struts stack. This will mean the front page is loaded fast, and the images may well trigger additional instances 
to be loaded, if they don't load immediately it may not be the end of the world.

T

Tim Hoffman

unread,
Sep 29, 2011, 9:42:56 PM9/29/11
to google-a...@googlegroups.com
Think ?

Actually run tests and measure.  Too much thinking and not enough actual testing
won't solve your problems.

I can imperically say warmup requests help on all of my applications.

T

Tapir

unread,
Sep 29, 2011, 9:52:19 PM9/29/11
to Google App Engine


On Sep 30, 9:41 am, Tim Hoffman <zutes...@gmail.com> wrote:
> Maybe you shouldn't use struts, this is a serious suggestion, and should be
> considered seriously.
> If you have a lightly used small app using a heavy framework then you have
> probably made a bad design choice.
Could you recommend one?
My website traffic is small, but my app is not small.

>
> If you have long startup times then warmup requests do help enormously, and
> in fact are about the only way you are
> going to improve the use experience.
In fact, as the gae docs says, "warmup requests is not always
positive".
"warmup requests" will make the problem I mentioned in the first
comment worse.

>
> Also if you have such large startup times, then you should probably have
> more than one idle instance.
As I mentioned above, set "Max Idle Instances" with 1 instead 3 will
make page loading faster.
(Surely, I think this is a bug of gae)

>
> I would also examine you software stack and see if you can at least serve
> the home page/landing page
> directly from memcache without starting struts up.
> The have on that same page some images that will be loaded after the html is
> loaded, and serve these from the
> full struts stack. This will mean the front page is loaded fast, and the
> images may well trigger additional instances
> to be loaded, if they don't load immediately it may not be the end of the
> world.
I don't think loading images needs instances.

>
> T

Tapir

unread,
Sep 29, 2011, 9:59:17 PM9/29/11
to Google App Engine


On Sep 30, 9:41 am, Tim Hoffman <zutes...@gmail.com> wrote:
> Maybe you shouldn't use struts, this is a serious suggestion, and should be
> considered seriously.
> If you have a lightly used small app using a heavy framework then you have
> probably made a bad design choice.

I am really some regretting on using java instead of python.
I feels google doesn't put enough energy to solve some common problems
in java apps,
such as slow startup and high memory using.

Jeff Schnitzer

unread,
Sep 29, 2011, 11:54:20 PM9/29/11
to google-a...@googlegroups.com
On Thu, Sep 29, 2011 at 6:59 PM, Tapir <tapi...@gmail.com> wrote:
>
> I am really some regretting on using java instead of python.
> I feels google doesn't put enough energy to solve some common problems
> in java apps,
> such as slow startup and high memory using.

Honestly it's really hard to tell what you're asking from this thread.
If your app takes a long time to start up and spends most of its time
idle (thus gets shut down), consider paying for the "always on"
option.

Also, if you haven't yet, put <threadsafe>true</threadsafe> in your
appengine-web.xml. A single instance should be able to serve many
concurrent requests.

Jeff

Tapir

unread,
Sep 30, 2011, 12:55:38 AM9/30/11
to Google App Engine
I think I have described it clearly.
There is an idle instance running, but gae scheduler will still create
a new instance and use the new instance to handle a new coming
request.
This is not a right implementation. The right implementation is use
the idle instance to handle the new coming request and create a new
instance for potential other coming requests.

On Sep 29, 11:54 pm, Jeff Schnitzer <j...@infohazard.org> wrote:
> On Thu, Sep 29, 2011 at 6:59 PM, Tapir <tapir....@gmail.com> wrote:
>
> > I am really some regretting on using java instead of python.
> > I feels google doesn't put enough energy to solve some common problems
> > in java apps,
> > such as slow startup and high memory using.
>
> Honestly it's really hard to tell what you're asking from this thread.
>  If your app takes a long time to start up and spends most of its time
> idle (thus gets shut down), consider paying for the "always on"
> option.
My app don't need 3 always-on paid instances.
As I have mentioned above, I have set the "Max Idle Instances" to 1
instead of the old 3. Now the user experience is very happy.
Ironic? one "Max Idle Instances" is better than 3 "Max Idle
Instances". ^_^

>
> Also, if you haven't yet, put <threadsafe>true</threadsafe> in your
> appengine-web.xml.  A single instance should be able to serve many
> concurrent requests.
yes, I set it true, but this problem still exists.

>
> Jeff

Tapir

unread,
Sep 30, 2011, 1:14:29 AM9/30/11
to Google App Engine
I admit the title is misleading.
It should be "The user experience is intolerable for with Max Idle
Instances set as 3".
For when I started this thread, I hadn't found the real reason for my
app slow page loading problem.

On Sep 30, 11:54 am, Jeff Schnitzer <j...@infohazard.org> wrote:

Brandon Wirtz

unread,
Sep 30, 2011, 7:14:56 AM9/30/11
to google-a...@googlegroups.com

If you are loading extra libraries that can slow your load time.  Also look at storing variables and other start up information in memcache rather than datastore.  I knocked a lot of time off of my startup by trimming the fat and putting all of my start up variables in a single entity rather than having to grab several entities at startup.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/akZjr0DRILYJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

Tapir

unread,
Sep 30, 2011, 8:05:16 PM9/30/11
to Google App Engine

On Sep 30, 7:14 pm, "Brandon Wirtz" <drak...@digerat.com> wrote:
> If you are loading extra libraries that can slow your load time.  Also look
> at storing variables and other start up information in memcache rather than
> datastore.  I knocked a lot of time off of my startup by trimming the fat
> and putting all of my start up variables in a single entity rather than
> having to grab several entities at startup.
This is gae bug, not a app-optimization problem.

>
> From: google-a...@googlegroups.com
> [mailto:google-a...@googlegroups.com] On Behalf Of Tim Hoffman
> Sent: Thursday, September 29, 2011 5:24 PM
> To: google-a...@googlegroups.com
> Subject: [google-appengine] Re: It is almost intolerable for user experience
> with 1 idle instances running
>
> I have a site, with max idle set to 1, and Min Pending Latency set to 500ms,
> and I find performance is great.
>
> It takes 3-4 secs normally to start the full app up, but through smart
> caching (I can start a cold instance and serve many pages directly from
> memcache without starting the full stack in less than <200ms.)
>
> I suggest you spend some time having a look at your app startup performance,
> and profiling your app,
>
> rather than spending your time posting the multitude of odd complaints all
> over the place.
>
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine" group.
> To view this discussion on the web visithttps://groups.google.com/d/msg/google-appengine/-/akZjr0DRILYJ.
Reply all
Reply to author
Forward
0 new messages