On 13 October 2011 19:46, Jeff Schnitzer <j...@infohazard.org> wrote: > I'm afraid you are still confused.
Possibly not. > You have ignored the entire point > of the "max idle instances" slider in the first place. I might be accused of ignoring its intended function and focusing on its practical function. > GAE keeps idle > instances around so that sudden bursts of traffic don't cause users to > sit around waiting while your django/spring app spends 5+ seconds > loading. Sure, so that's going to matter if traffic is very bursty, and you need to service it immediately. True of some apps, not true of all by any means. For instance, a lot of my work is with systems whose major work is in the background in tasks. Latency is a non-issue there. Also, that's only loosely related to the Max Idle Instances setting. > Will turning max-idle-instances down to 1 reduce your bill? Of > course. But only at the expense of user experience. Only true if I have no idle instances ready in reality. > The second user > to arrive is going to wait for five seconds. Maybe you'll get lucky > and Google will actually leave your idle instances running for longer > than you've decided you're willing to pay for. Or maybe they won't > and your users will wonder why your site is broken and go to your > competitor's site instead. If you have a lot of idle instances > running, it's because you're lucky that memory pressure hasn't evicted > your spares, not because you're paying for service. True. I've tuned based on testing, not based on theory. The current scheduler seems to kick off instances like crazy, no matter how you set Max Idle Instances. So having enough idle instances to service requests isn't currently a problem. Note that I'm not actually recommending setting Max Idle Instances to 1, but setting it to a fixed number. How high? It depends on the size of traffic bursts you absolutely must service immediately. How big is that number? Up to your situation. I bet it's smaller than infinity (which is what Automatic means). > My point in the "unofficial faq" is that this slider does not have a > single "correct" setting, and if there was, it would certainly not be > 1. You're basically paying for RAM. If you have a single-threaded > server, your 128 MB frontend will run one concurrent request at a > time. If you have an efficient multi-threaded server, your 128 MB > frontend can serve an order of magnitude more requests - possibly more > depending on how I/O bound your process is. I haven't seen anyone's numbers from the java side (and I haven't tried python 2.7 yet); is there actual data floating around on how many requests you can expect to serve concurrently per instance, using multi-threading? I guess what's crucial here is, if you use multi-threaded request processing code, do you see a serious decrease in the number of instances the scheduler wants to kick off? - If Max Idle Instances is set to Automatic, a serious decrease will mean a serious billing decrease, because you are paying for all of those instances - If Max Idle Instances is set to a fixed number which lands Active Instances + Max Idle Instances lower than Total Instances, then you are paying for that setting + your activity, ie: no difference even if your code is multi-threaded. Am I right that you are proposing that multi-threaded request handling will seriously lower your total instance count (in reality, not just in theory), and that you will therefore pay much less, with Max Idle Instances set to Automatic, than a single threaded app with a low Max Idle Instances setting would pay under the same load? > I'm not saying you shouldn't set your max-idle-instances to 1 right > now. For the time being, it *might* give you great performance at a > great price. I'm just saying this isn't any kind of a real solution - > you won't be able to complain when your latency goes to hell. Maximizing future complaint possibilities is not the same as actually lowering your bill. Right now, it's absolutely a great solution to set that number low. Everyone should do it. Everyone should also monitor their total instance count and keep an eye out for a change in scheduler behaviour that will render this advice incorrect, of course. But you should do that anyway, because Google could change their scheduler's behaviour without warning. If Max Idle Instances is set to Automatic, you'd pay real money for that. > Put it this way: If your multi-threaded system has an avg concurrency > of 10, setting max-idle-instance to 1 is the equivalent of setting it > to 10 on a single-threaded system. If you care about your user > experience, you want that number high. > > Jeff Sure, if you can get average concurrency of 10, then that's excellent. But that's a performance consideration, not a price consideration. Note that we are in a context where people are not complaining about poor performance, they're complaining about increased costs. Also, testing would indicate that moving Max Idle Instances around does not, in practice, at the moment, change the actual performance of actual apps significantly, only the guaranteed performance. People's needs vary, but I'd hazard a guess that actual price is higher on most dev's radars (particularly smaller devs) than performance guarantees, especially while actual performance is good. For those of us who are price sensitive (and we are talking about price), lowering max idle instances (with the current scheduler behaviour) is a no brainer. Meanwhile, for python users, multi threading is only just becoming an option, and may still not be ready for production use (I don't know, I haven't tried it yet). Also, modifying existing apps to work correctly in a multi-threaded environment is non-trivial (read: tricky and risky) development work. It's something we should all do eventually, but do the benefits as of right now actually warrant the costs and the risks? I'm not convinced that they do. So I'll stand by this on pricing: Theoretically, multi-threaded apps are superior on AppEngine and you should go that way. But in practice, as of right now, and especially for Python, they are not, particularly given that a good pragmatic solution to the issue of instance pricing is available at the touch of a slider. This pragmatic situation may (likely will) change, but right now it is absolutely the case. Note that I'm not saying that multi-threaded code is a bad idea. It's a good idea for all kinds of other reasons. But currently, pricing is not one of those reasons. Reading back over this, if I were on the AppEngine team I would be thinking "he's saying we should aggressively clean up idle instances above Max if we want people to move to Python 2.7 and write more efficient multi-threaded code". I may have shot myself in the foot ;-) > > On Thu, Oct 13, 2011 at 1:21 AM, Emlyn <emlynore...@gmail.com> wrote: >> np Johan. >> >> I was confused earlier on by posts such as >> >> http://blorn.com/post/10013293300/the-unofficial-google-app-engine-price-change-faq >> >> which focuses on multithreading to get pricing down, which I think is >> just wrong. There are lots of good reasons to write multithreaded >> code, but AppEngine pricing isn't really one of them. >> >> On 13 October 2011 18:22, Johan Euphrosine <pro...@google.com> wrote: >>> Hi Emlyn, >>> >>> Thanks for sharing those articles, it is very nice that you were able >>> to backup the billing formula with hard facts. >>> >>> As it was discussed in the groups during the pricing model change the >>> billing formula under the new model will be: >>> billable_instances_rate = min(active_instances_rate + >>> max_idle_instances, total_instances_rate) >>> >>> where in the dashboard: >>> - active_instances_rates is the yellow line >>> - total_instances_rate is the blue line >>> - max_idle_instances is the upper bound of "Idle Instances" performance >>> settings >>> >>> If you set max_idle_instances to automatic, it's equivalent to setting >>> it to a very large number making the formula essentially become: >>> billable_instances_rate = total_instances_rate >>> >>> See the following threads where Jon McAlister commented about the >>> billing formula: >>> https://groups.google.com/d/msg/google-appengine/zuRXAphGnPk/UiTgTIIesL0J >>> https://groups.google.com/d/msg/google-appengine/W-17IhgwrLI/05Wti7I39EUJ >>> https://groups.google.com/d/msg/google-appengine/T-dJtXmOO8U/npM69XZAJFcJ >>> >>> On Wed, Oct 12, 2011 at 3:10 PM, Emlyn <emlynore...@gmail.com> wrote: >>>> I've been testing this hypothesis: >>>> >>>> Hypothesis: Ignoring the 15 minute cost for spinning up new instances, >>>> the price we pay is the moment by moment minimum of (total instances) >>>> and (active instances + Max Idle Instances). If Max Idle Instances is >>>> set to Automatic, then we pay for the moment by moment total >>>> instances. >>>> >>>> It holds. That is, if you leave the default Max Idle Instances setting >>>> (Automatic), you'll be billed for every bit of instance time the >>>> scheduler chooses to run. If you set it to a fixed number, you'll have >>>> a fixed cost cap based on the actual work you are doing (a lot more >>>> like cpu time), in most cases a lot lower. >>>> >>>> Here are a couple of posts in detail, with graphs, billing numbers, >>>> pictures! >>>> >>>> The Spiny Norman Test >>>> http://appenginedevelopment.blogspot.com/2011/10/spiny-norman-test.html >>>> >>>> Go Spiny Norman, Go >>>> http://appenginedevelopment.blogspot.com/2011/10/go-spiny-norman-go.html >>>> >>>> -- >>>> Emlyn >>>> >>>> http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google >>>> Buzz posts, >>>> comments and all. >>>> http://point7.wordpress.com - My blog >>>> Find me on Facebook and Buzz >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Google App Engine" group. >>>> To post to this group, send email to google-appengine@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> google-appengine+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-appengine?hl=en. >>>> >>>> >>> >>> >>> >>> -- >>> Johan Euphrosine (proppy) >>> Developer Programs Engineer >>> Google Developer Relations >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine" group. >>> To post to this group, send email to google-appengine@googlegroups.com. >>> To unsubscribe from this group, send email to >>> google-appengine+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine?hl=en. >>> >>> >> >> >> >> -- >> Emlyn >> >> http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google >> Buzz posts, >> comments and all. >> http://point7.wordpress.com - My blog >> Find me on Facebook and Buzz >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to google-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- Emlyn http://my.syyn.cc - Synchonise Google+, Facebook, WordPress and Google Buzz posts, comments and all. http://point7.wordpress.com - My blog Find me on Facebook and Buzz -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
