There's something I really don't get about the new pricing. As far as I can see, I am now billed (amongst others) for the number of "instance/hours". On the other hand, a while back I've opted for the "Always on" feature, which since then effectively has 3 "Resident" instances of my application always running.
Now, A.F.A.I.C.S. , on the old pricing model, the one where I was charged by CPU Time used, the "always on" feature was great, not only did it made the app more responsive, but since the instances were no longer started-up/torn-down when traffic was scarce, the CPU Time was lowered (and indeed this is visible on the dashboard).
But now, since I'm billed by Instance/hours, the fact that I have this "always on" option active doesn't in fact add a lot of money to my bill, even when those instances are not actually doing anything (simply because they're just there, always on)?
I'm asking this because since the new pricing model was activated, I have whopping increase in Frontend Instance Hours (right now it's 29.21 for the last 9 hours), where before the CPU Time never really came close to depassing the free quota.
add a lot of money to my bill, even when those instances are not actually doing anything (simply because they're just there, always on)?add a lot of money to my bill, even when those instances are not actually doing anything ...
The problem is that they are doing something. They are occupying RAM. The new pricing model attempts to more accurately model the underlying costs to Google, or at least that's what they tell us. You can change how many instances are always on by going to the admin interface. If you aren't really using all 3, try going down to 2 or 1. If your traffic spikes, more instances will be started up. You can also set a value for how much latency you want users to endure before new instances are spun up.
The "Always On" feature does not exist as of 1.6.0. The equivalent replacement is setting the Min Idle Instances slider to 3 (and leaving the Max Idle Instances at "Automatic") in your Application Settings in the Admin Console.
The scheduler might be spinning up more than one instance to respond to threads.
Is this in Java? You could try to make it threaded, to make it more responsive to lower latency.
You could also tweak the scheduler parameters to discourage it from spinning up more instances.