Min Pending Latency -- does it really do anything?

[dloomer]

I have a simple webcam app used by a maximum of maybe 3 people at any time, which also handles requests from a batch process initiated from my house which uploads a new image to my app every 15 seconds via HTTP call to my app's frontend.  My goal is to get the app running on just a single frontend instance at all times, making this as close to a free app as possible, but this is proving much more difficult than I thought it would.

When no one is connected to my app, all the uploads go to a single instance.  All the requests complete with around 200ms latency.

However, as soon as one user accesses the main page of my app, a new instance spins up.  This in spite of the fact that a browser request to my app typically completes in well under a second, and Min Pending Latency is set to 15 seconds.

What is it that would make the scheduler think that one instance won't handle both sets of requests, when the Min Pending Latency is set so high and none of the requests come anywhere near this threshold? One theory: I remember reading on these forums a while back, under a topic regarding keeping an instance "always on", that the scheduler has strategies to prevent you from keeping an instance "always on" by constantly pinging it. My 15-second periodic upload is similar to a ping in this sense.  I don't intend anything nefarious, but the scheduler wouldn't know this, and maybe is just trying to close a loophole that someone else could exploit.

I'd use a backend to handle the image uploads, but I need it running 24 hours and a 24-hour backend isn't free.

I don't think this would work as a "free" app by Google's billing terms (which I believe would restrict me to a single frontend by default), as it's likely I'll go over quota on datastore operations farily regularly.

Any ideas on how I can keep my app as cheap as possible without sacrificing functionality?

[Rishi Arora]

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  Remember that "max_idle_instances=1" doesn't mean "max_instances=1".  I do agree your concerns, and I'm curious to know too, why the scheduler is starting a second instance, even though min_latency is set to 15 seconds.  Nevertheless, you should still be able to stay under the free quota of 28 instance hours.  The periodic image uploads will take up 24 instance hours, and any extra processing time that those uploads require, and any user-facing requests require will most likely fit into the remaining 4 instance hours.  Any idle time for the second (or third, or fourth) instance will not be billed to you (only the processing time of the extra instances will be billed).  This was in fact the motivation behind increasing the free instance hours from 24 to 28.

--
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/-/-OicXg1wyQIJ.
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.

[Joseph Lebel]

Have you looked into using the Blobstore? You can serve the images
without using instances (or cpu).

On Sep 13, 5:30 pm, dloomer <dloo...@gmail.com> wrote:
> I have a simple webcam app used by a maximum of maybe 3 people at any time,
> which also handles requests from a batch process initiated from my house
> which uploads a new image to my app every 15 seconds via HTTP call to my
> app's frontend.  My goal is to get the app running on just a single frontend
> instance at all times, making this as close to a free app as possible, but
> this is proving much more difficult than I thought it would.
>
> When no one is connected to my app, all the uploads go to a single instance.
>  All the requests complete with around 200ms latency.
>
> However, as soon as one user accesses the main page of my app, a new

> instance spins up.  *This in spite of the fact that a browser request to my

> app typically completes in well under a second, and Min Pending Latency is

> set to 15 seconds.*

[dloomer]

Interesting.  I didn't know about the 28 instance hours, since under the "Estimated Charges Under New Pricing" section of my billing history it still shows 24 free instance hours.  Thanks for that info.

[dloomer]

Serving the images by itself isn't much of an issue.  But every request to my page is still going to need a call to a regular webapp handler to serve up the HTML surrounding the images.  And if I use blobstore for the uploads, that still will require HTTP requests.  So I think I'd end up using the same number of HTTP requests for both the web pages and the uploader as I'm currently using (and actually the uploader might require an extra round trip to get the blobstore upload URL).

[Rishi Arora]

It was announced just 4 days ago, in response to developer concerns for small size apps.

http://googleappengine.blogspot.com/2011/09/few-adjustments-to-app-engines-upcoming.html

On Tue, Sep 13, 2011 at 5:52 PM, dloomer <dlo...@gmail.com> wrote:

Interesting.  I didn't know about the 28 instance hours, since under the "Estimated Charges Under New Pricing" section of my billing history it still shows 24 free instance hours.  Thanks for that info.

--

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/-/bT9ppc6NQPcJ.

[Tapir]

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

[Barry Hunter]

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum

[Tapir]

Do you mean set it 'automatic' will charge you less?

 

https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum

This document doesn't mention 'automatic'.

I feel I really can't understand many GAE documents very well.

I don't think my English reading is bad.

 

[Barry Hunter]

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute. 

 

 

https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum

This document doesn't mention 'automatic'.

Its telling you what enabling 'idle instances' does. Going back to 'automatic' in effect turns the feature off. 

(glossing over a few details) 

 

I feel I really can't understand many GAE documents very well.

One of the main issue, is they leave a lot unsaid, you have to infer. Read between the lines. 

Plus the inevitable case that things change, and the docs are not always in sync. 

 

[Kristopher Giesing]

I have yet to talk to a GAE user who *didn't* misunderstand this part of the docs on first read.  It's one of the most common issues people have when they first come to this group.

- Kris

[Tapir]

On Thursday, February 20, 2014 2:26:52 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute.  

 

 

https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum

This document doesn't mention 'automatic'.

Its telling you what enabling 'idle instances' does. Going back to 'automatic' in effect turns the feature off. 

So you mean set max_odle_instances as 1 can't prevent more than 1 instance, but set it 'automatic' will?

:(, I'm some mad about this design.

ok, I will try it for two days.

 

(glossing over a few details) 

 

I feel I really can't understand many GAE documents very well.

One of the main issue, is they leave a lot unsaid, you have to infer. Read between the lines. 

Plus the inevitable case that things change, and the docs are not always in sync. 

I never has any problems on understanding the docs of Heroku and DigitalOcean.

 

 

[Tapir]

On Thursday, February 20, 2014 9:18:50 AM UTC+8, Kristopher Giesing wrote:

I have yet to talk to a GAE user who *didn't* misunderstand this part of the docs on first read.  It's one of the most common issues people have when they first come to this group.

- Kris

I'm an old user of GAE, I read many GAE docs may times.

The problem is the more I read them, I more I'm confused.

[Tapir]

On Thursday, February 20, 2014 2:26:52 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute. 

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

[Tapir]

On Thursday, February 20, 2014 2:26:52 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute. 

 

 

https://developers.google.com/appengine/docs/adminconsole/performancesettings#minimum

This document doesn't mention 'automatic'.

Its telling you what enabling 'idle instances' does. Going back to 'automatic' in effect turns the feature off. 

(glossing over a few details) 

Ok, I uploaded a version with the 'automatic' max_idle_instance.

This is initial instances statistics: http://imgur.com/bIC0BB0

It is very clear the scheduler will always try to use the dynamic instance instead of the resident one to handle requests.

Would this increase my front end hours?

[Tapir]

:(, not like what a big company should do.

 

 

[Tapir]

On Thursday, February 20, 2014 2:26:52 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute. 

Sorry, I must reject your suggestion right now and restore the value from automatic to 1.

Here is why (today's front hour usage)

http://imgur.com/buYXfak

[Tapir]

On Thursday, February 20, 2014 3:49:53 PM UTC+8, Tapir wrote:

On Thursday, February 20, 2014 2:26:52 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 6:07 PM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 1:44:35 AM UTC+8, barryhunter wrote:

On Wed, Feb 19, 2014 at 5:05 AM, Tapir <tapi...@gmail.com> wrote:

On Wednesday, September 14, 2011 6:04:15 AM UTC+8, Rishi Arora wrote:

It really doesn't matter it a second instance kicks in to process your user-facing requests.  If your max_idle_instances is set to 1, then you're only paying for one idle instance at any given time.  

Really?!  Any googler can confirm this? I set max-idle-instances as 1, but I am still charged more than 28 hours often recently.

Can still have one idle instance. So one active instance, and one idle, means would use up the quota. 

Or a spike where say three instances are started, and immidiately become idle. They sill still be 'charged' for 15 minutes. 

If at the end of the 15 minutes, they are not shutdown you will still be 'charged' for 1 idle instance. But max_idle_instances means those two other ones become free. 

 

If you want to avoid appengine keeping (and charging you for!) idle instances, best to set max_idle_instances, back to 'automatic'

Do you mean set it 'automatic' will charge you less?

In general yes. But it's not absolute. 

Sorry, I must reject your suggestion right now and restore the value from automatic to 1.

Here is why (today's front hour usage)

http://imgur.com/buYXfak

Today still doesn't ends.

I really can't understand why GAE team is not wailing to admit their java runtime has big problems.

[Barry Hunter]

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

In general there isn't one. Other than disabling billing, so you can't use anything outside the free quota :)

All you can do is optimize stuff, to make it unlikly but can't stop it. 

Frankly if the app is small enough that you can be worrying about the cost of one instance, AppEngine is not really your ideal platform. 

AppEngines sweetspot is 'midscale'. Its difficult to artificially 'limit' an app to keep it small scale. And at some point growth may mean it makes sence to go back to homegrown. 

[Tapir]

On Thursday, February 20, 2014 6:45:43 PM UTC+8, barryhunter wrote:

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

In general there isn't one. Other than disabling billing, so you can't use anything outside the free quota :)

For free account can't create resident instance, disabling billing means many warmup requests.

Really fell helpless. :(

Why there is no a "disable_dynamic_instances" setting? I really think the only resident instance is enough for my app.

[Tapir]

On Thursday, February 20, 2014 6:45:43 PM UTC+8, barryhunter wrote:

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

In general there isn't one. Other than disabling billing, so you can't use anything outside the free quota :)

All you can do is optimize stuff, to make it unlikly but can't stop it. 

Frankly if the app is small enough that you can be worrying about the cost of one instance, AppEngine is not really your ideal platform. 

I think my app is small enough, I think the free hours are enough for my app, but the scheduler doesn't think so. :(

AppEngine is never my ideal platform, I use AppEngine is just for the BigTable.

[Barry Hunter]

On Thu, Feb 20, 2014 at 11:03 AM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 6:45:43 PM UTC+8, barryhunter wrote:

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

In general there isn't one. Other than disabling billing, so you can't use anything outside the free quota :)

For free account can't create resident instance, disabling billing means many warmup requests.

Well if you want to use a resident instance, then by definition you pretty much can't fit in the free limit!

You can't have your cake and eat it you know. 

 

Really fell helpless. :(

Why there is no a "disable_dynamic_instances" setting? I really think the only resident instance is enough for my app.

 

Because Appengine is designed to scale, artificial limits are sort of the antithesis. 

Having said that, there is an option to disable the automatic scaling, by way of modules

https://developers.google.com/appengine/docs/java/modules/#Java_Instance_scaling_and_class

but again you can't do that within the free quota. Only get 8 hours worth. 

[Tapir]

On Thursday, February 20, 2014 7:22:05 PM UTC+8, barryhunter wrote:

On Thu, Feb 20, 2014 at 11:03 AM, Tapir <tapi...@gmail.com> wrote:

On Thursday, February 20, 2014 6:45:43 PM UTC+8, barryhunter wrote:

 

My app is still in the development stage. It has a small traffic now (< 1000 pageviews/day).

I really need a workable configuration which will make sure it will never be charged more than 28 hours.

In general there isn't one. Other than disabling billing, so you can't use anything outside the free quota :)

For free account can't create resident instance, disabling billing means many warmup requests.

Well if you want to use a resident instance, then by definition you pretty much can't fit in the free limit!

Why? 24 hours is rally ok for my app.

In fact, I have another python paid app, its front end hours is exactly 24 for every day.

 

You can't have your cake and eat it you know. 

 

Really fell helpless. :(

Why there is no a "disable_dynamic_instances" setting? I really think the only resident instance is enough for my app.

 

Because Appengine is designed to scale, artificial limits are sort of the antithesis. 

Having said that, there is an option to disable the automatic scaling, by way of modules

https://developers.google.com/appengine/docs/java/modules/#Java_Instance_scaling_and_class

but again you can't do that within the free quota. Only get 8 hours worth. 

I had been ever excited by this until I noticed it is 8 hours free. :) :(

 

[Kristopher Giesing]

Because by definition, resident instances don't serve any traffic.  That means you are eating up 24 instance hours of idle time each day, leaving you only four hours each day to serve traffic.

I had this exact problem while my app was in development, and I couldn't figure out why Java developers weren't screaming bloody murder about it.  Then I did three things:

1) I gave up on trying to configure residency and latency, and just left everything at the default values

2) I rewrote the app away from JDO and started using Objectify

2) I optimized my app to use fewer API calls and less CPU

When I did those two things, the problems I was seeing with the scheduler magically disappeared.  I believe that the scheduler was behaving the way it did because it was reacting to the CPU, memory usage, and API call pattern of my app - that is, it assumed that due the combination of those metrics, my app's single instance was incapable of handling any more traffic and kept trying to spin up more instances.  Before I was using Objectify this spin-up cost was prohibitive; after Objectify it was still noticeable, but manageable.  Then after I was done with my optimizations the spin-up attempts stopped.  I'm now below the free quota for instance hours every day, and only end up paying anything for read ops (which I'm fine with because I know where all those ops are going, and they're all necessary for my traffic levels).

- Kris

[Tapir]

On Friday, February 21, 2014 1:11:12 AM UTC+8, Kristopher Giesing wrote:

Because by definition, resident instances don't serve any traffic.  That means you are eating up 24 instance hours of idle time each day, leaving you only four hours each day to serve traffic.

Resident instances do serve traffic. All the traffic of my paid python app are served by the resident instance. Part of the traffic of my paid java app are also served by the resident instance.

 

I had this exact problem while my app was in development, and I couldn't figure out why Java developers weren't screaming bloody murder about it.  Then I did three things:

1) I gave up on trying to configure residency and latency, and just left everything at the default values

2) I rewrote the app away from JDO and started using Objectify

2) I optimized my app to use fewer API calls and less CPU

Does Objectify depend on the core GAE SDK lib?

If it is true, I think it is no hope to decrease the warm up time to under 5 seconds.

The warmup time of the guestbook example on git is 7-10 seconds.

[Vinny P]

On Thu, Feb 20, 2014 at 11:22 AM, Tapir <tapi...@gmail.com> wrote:

Resident instances do serve traffic. All the traffic of my paid python app are served by the resident instance. Part of the traffic of my paid java app are also served by the resident instance.

Resident instances do serve traffic, but most of the traffic is intended to be taken up by dynamic instances. 

-----------------

-Vinny P

Technology & Media Advisor

Chicago, IL

App Engine Code Samples: http://www.learntogoogleit.com

[Tapir]

On Friday, February 21, 2014 2:58:35 PM UTC+8, Vinny P wrote:

On Thu, Feb 20, 2014 at 11:22 AM, Tapir <tapi...@gmail.com> wrote:

Resident instances do serve traffic. All the traffic of my paid python app are served by the resident instance. Part of the traffic of my paid java app are also served by the resident instance.

Resident instances do serve traffic, but most of the traffic is intended to be taken up by dynamic instances. 

So for the app with warmup problems, to avoid the warmup the problem, the real free hours would be only a little more than 4 hours, right?

And for the 15 minutes tax design, the "a little more than 4 hours" is about several minutes in fact, right?

Ok, I see why one hour compute hour is enough for my app but my app is still often counted more than 28 hours now.

So you help me confirm again using Java on GAE is really not a good choice. Thanks!

[Vinny P]

On Fri, Feb 21, 2014 at 1:23 AM, Tapir <tapi...@gmail.com> wrote:

So for the app with warmup problems, to avoid the warmup the problem, the real free hours would be only a little more than 4 hours, right?

And for the 15 minutes tax design, the "a little more than 4 hours" is about several minutes in fact, right?

Ok, I see why one hour compute hour is enough for my app but my app is still often counted more than 28 hours now.

So you help me confirm again using Java

The 15 minute rule is not confined only to the Java runtime, it exists for all runtimes. It's not a tax; it's there so you avoid the overhead of a second warmup request if another request comes in soon after the first. 

If you wanted to avoid keeping instances up for the extra 15 minutes, you could always cause the instance to terminate; for example, exceed the memory allocated to your instance.

[Tapir]

On Friday, February 21, 2014 3:29:37 PM UTC+8, Vinny P wrote:

On Fri, Feb 21, 2014 at 1:23 AM, Tapir <tapi...@gmail.com> wrote:

So for the app with warmup problems, to avoid the warmup the problem, the real free hours would be only a little more than 4 hours, right?

And for the 15 minutes tax design, the "a little more than 4 hours" is about several minutes in fact, right?

Ok, I see why one hour compute hour is enough for my app but my app is still often counted more than 28 hours now.

So you help me confirm again using Java

The 15 minute rule is not confined only to the Java runtime, it exists for all runtimes. It's not a tax; it's there so you avoid the overhead of a second warmup request if another request comes in soon after the first. 

I really admire the design of GAE instance scheduler and billing.

According what you say, at an extreme case

1. to avoid warmup request, a resident instance is created,

2. the website get a request every 15 minutes, 96 request a day.

So the scheduler doesn't like let the resident instance to handle the requests and let another dynamic instance to handler the requests.

By what you say above, the total counted hours for the dynamic instance is 24 hours!

The total front end hours is 24 dynamic instance hours + 24 resident instance hours = 48 hours!

So cool! The cooler thing is someone like it and think it is great!

[Rafael]

The scheduler logic doesn't make any sense for java apps. For frontend serving I would rather just use a scheduler that boots one instance at time and would spread traffic linearly through all instances. This would be more reliable due to the issues with warm up.

I have to keep 6 useless instances running, just because when a instance is idle for a long time its very probable its in a zombie state, so even if you are paying high costs for resident instances there's a high probability it won't be able to serve requests when you need it.

The real and only problem is that we are stuck into this senseless scheduler due to the fact that its the only one who have discounted hours. It almost seems that google uses the resident instances to serve other traffic when they become idle (even if I'm paying for it)

On Feb 21, 2014 12:47 AM, "Tapir" <tapi...@gmail.com> wrote:

On Friday, February 21, 2014 3:29:37 PM UTC+8, Vinny P wrote:

On Fri, Feb 21, 2014 at 1:23 AM, Tapir <tapi...@gmail.com> wrote:

So for the app with warmup problems, to avoid the warmup the problem, the real free hours would be only a little more than 4 hours, right?

And for the 15 minutes tax design, the "a little more than 4 hours" is about several minutes in fact, right?

Ok, I see why one hour compute hour is enough for my app but my app is still often counted more than 28 hours now.

So you help me confirm again using Java

The 15 minute rule is not confined only to the Java runtime, it exists for all runtimes. It's not a tax; it's there so you avoid the overhead of a second warmup request if another request comes in soon after the first. 

I really admire the design of GAE instance scheduler and billing.

According what you say, at an extreme case

1. to avoid warmup request, a resident instance is created,

2. the website get a request every 15 minutes, 96 request a day.

So the scheduler doesn't like let the resident instance to handle the requests and let another dynamic instance to handler the requests.

By what you say above, the total counted hours for the dynamic instance is 24 hours!

The total front end hours is 24 dynamic instance hours + 24 resident instance hours = 48 hours!

So cool! The cooler thing is someone like it and think it is great!

 

If you wanted to avoid keeping instances up for the extra 15 minutes, you could always cause the instance to terminate; for example, exceed the memory allocated to your instance.

 

 

-----------------

-Vinny P

Technology & Media Advisor

Chicago, IL

App Engine Code Samples: http://www.learntogoogleit.com

--
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-appengi...@googlegroups.com.

To post to this group, send email to google-a...@googlegroups.com.

Visit this group at http://groups.google.com/group/google-appengine.
For more options, visit https://groups.google.com/groups/opt_out.

[Tapir]

On Saturday, February 22, 2014 2:22:56 AM UTC+8, Rafael Sanches wrote:

The scheduler logic doesn't make any sense for java apps. For frontend serving I would rather just use a scheduler that boots one instance at time and would spread traffic linearly through all instances. This would be more reliable due to the issues with warm up.

I have to keep 6 useless instances running, just because when a instance is idle for a long time its very probable its in a zombie state, so even if you are paying high costs for resident instances there's a high probability it won't be able to serve requests when you need it.

The real and only problem is that we are stuck into this senseless scheduler due to the fact that its the only one who have discounted hours. It almost seems that google uses the resident instances to serve other traffic when they become idle (even if I'm paying for it)

I want the scheduler always use the only resident instance to handle requests. :)

Yes, we need more settings for the scheduler to define the beviour of the scheduler.

Otherwise, it make you feel your fate is controlled by scheduler instead of yourself. :D

[Vinny P]

On Fri, Feb 21, 2014 at 12:22 PM, Rafael <mufu...@gmail.com> wrote:

The scheduler logic 

Regarding the scheduler, this is my favorite thread regarding the subject: https://groups.google.com/d/msg/google-appengine/sA3o-PTAckc/T2eA64xZ1m0J 

It's a bit long (over 100+ posts) but it has some interesting discussion.

[Tapir]

On Saturday, February 22, 2014 2:04:44 PM UTC+8, Vinny P wrote:

On Fri, Feb 21, 2014 at 12:22 PM, Rafael <mufu...@gmail.com> wrote:

The scheduler logic 

Regarding the scheduler, this is my favorite thread regarding the subject: https://groups.google.com/d/msg/google-appengine/sA3o-PTAckc/T2eA64xZ1m0J 

It's a bit long (over 100+ posts) but it has some interesting discussion.

After the reading, I replaced my app settings from

min_idle_instances=1 , max_idle_instances = 1 and min_pending_latency = 3s

to

min_idle_instances=automatic, max_idle_instances = 1 and min_pending_latency = 3s

Surprisingly, almost all requests are handled faster.

For the old settings, most request handling time is longer than 0.5s.

But with the new settings, the handling time is about 0.3s.

And the most important, now there is always no resident instance, only one dynamic instance there.

What is the hell? A settings looks less powerful and less cost gets a better performance?