Re: [appengine-java] Re: Feelings about new pricing model
Hi coders, Could people please correct me as I am trying to understand all this, have read quite a few thread/pages but still a bit unsure what is going on exactly. This is what I get so far: - Being charged for instances means we should probably use multi-threading in our apps to avoid significant cost increases, so google is encouraging us to write apps that make more efficient use of memory. - Python developers are piddled off because they can't use multi-threading. Can anyone enlighten me as to when an application that doesn't use multi-threading would require a new instance - when more than 1 request is happening simultaneously? When one JVM can't handle more requests? I am totally confused. I still think GAE is well worth the money. People are complaining about $50/month but I want my app to be making way more than that and I think the tools and support they provide make it way worth it. I just want to make sure I take all these measures into account to make my app as efficient as possible. Drew -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
Let's say you have a sustained traffic of 5 hits per second, and each request takes 1 second to process (waiting on the datastore, waiting on facebook, whatever). If you're using single-threaded python, you will need 5 instances to serve this load - each instance can do nothing else while it processes a single request. So, maybe the datastore is behaving well today and you ditched your Facebook integration so you can complete each request in 200ms. Now you only need one instance to serve those 5 hits per second. Now let's say you get slashdotted, and for a day you sustain 500 hits per second. You now need 100 instances. Maybe there's a datastore hiccup and your latency goes up... now you need 200, 300 instances. They consume very little CPU because they spend most of their time blocked waiting for I/O, but they sure do occupy a lot of RAM. An efficient multithreaded (or async) server should be able to handle this load with less than 10 instances, and I/O latency will have minimal impact. Additional concurrent requests consume more CPU but they don't consume more RAM. Nobody is complaining about $50/mo. They're complaining about the looming threat of $500 or $5000 per month for traffic levels that barely register on a less scalable architecture. The Google blog says that appengine served over 2,000 hits per second for the Royal Wedding - I'd like to know what the bill would look like before and after the pricing change. Jeff On Tue, May 24, 2011 at 1:46 AM, Drew Spencer slugmand...@gmail.com wrote: Hi coders, Could people please correct me as I am trying to understand all this, have read quite a few thread/pages but still a bit unsure what is going on exactly. This is what I get so far: Being charged for instances means we should probably use multi-threading in our apps to avoid significant cost increases, so google is encouraging us to write apps that make more efficient use of memory. Python developers are piddled off because they can't use multi-threading. Can anyone enlighten me as to when an application that doesn't use multi-threading would require a new instance - when more than 1 request is happening simultaneously? When one JVM can't handle more requests? I am totally confused. I still think GAE is well worth the money. People are complaining about $50/month but I want my app to be making way more than that and I think the tools and support they provide make it way worth it. I just want to make sure I take all these measures into account to make my app as efficient as possible. Drew -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
On Tuesday, May 24, 2011 11:21:00 AM UTC+2, Jeff Schnitzer wrote: The Google blog says that appengine served over 2,000 hits per second for the Royal Wedding - I'd like to know what the bill would look like before and after the pricing change. Indeed, that would be an interesting thing to know. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
Can't you just limit your maximum number of instances at any one time? In the case of the datastore hiccup surely google would make some sort of adjustment due to their own failures? I see you point and agree wholeheartedly Jeff, I guess I just trust Google to keep it reasonably competitive on price. Otherwise wouldn't we all just move to another service? Drew -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
On Sun, May 22, 2011 at 10:15 PM, Tom Gibara tomgib...@gmail.com wrote: Put it this way: A single multithreaded Java appserver instance should be able to happily consume every last CPU cycle on a frontend box - and that's just the free tier. That presumes that the JVM that sandboxes the app is given access to all the CPU cycles. Nothing precludes mapping all Java threads onto a single native thread, for example. I don't work for Google and I don't have any secret backroom knowledge of how appengine works beyond what is commonly available. The impression I get from paying attention is: * GAE runs on linux (a custom version, probably standardized throughout Google) * GAE runs on a linux JVM (probably unhacked, or very lightly hacked) * GAE runs on a version of Jetty (probably heavily hacked) I don't think appengine is so exotic that they've built their own JVM. Yes, they they hired Guido and probably have their own special version of Python, but the JVM has deeper hooks that were designed from the get-go for this kind of secure isolated application processing. If Google has JVM engineers of Guido's pedigree working on appengine (ie, not part of the Android/Dalvik team), they have been very secretive about it. My guess is that the appengine JVM is a standard Sun JVM. ...and at any rate, it doesn't change point I was making. Even if you assume GAE uses an on ancient JVM with green threads, that only ensures that a single free-tier instance can consume one core of a box. Still very expensive given that boxes are unlikely to have more than 8 cores (16 if you consider hyperthreading). Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Feelings about new pricing model
The new price model says $0.08/hour for every new instance. http://www.google.com/enterprise/appengine/appengine_pricing.html That sounds extremely expensive, or have I missed something? One GAE server no doubt runs many instances, or? 0.08 * 24 * 30 = $57.6 per month. Yikes. At the moment my apps have very low traffic, but already today 2 instances are often running. With increased traffic many instances may be running all the time resulting in huge monthly bills. On May 10, 11:18 pm, Marcel Overdijk marceloverd...@gmail.com wrote: Today Google announced the new pricing model to be effective later this year (http://googleappengine.blogspot.com/2011/05/year-ahead-for- google-app-engine.html). I always like the pay per usage model compared to the pay per instance model. Because of this change by Google, other platforms - like VMware's CloudFoundry - might be on the same pricing level and offer more advantage as they are more flexible in terms of frameworks supported. I'm wondering how other developers feel about this change in pricing model. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Feelings about new pricing model
And it is said that the new price model is more transparent. But CPU hours at least sounds more transparent. How many instances share the same CPU in a GAE server? 1, 2, 10 or 100? The new price model seems more opaque. For example, if 10 instances share the same CPU, then only (at best, not counting overhead) 1/10 of the CPU power will be available to each instance given they consume the same amount CPU time each, and yet all 10 instances will be billed the full price! What a rip off. Or probably I have missed something, but still, it's not clear. A better price model is needed imo. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
I think you're worried about the wrong thing here. Given the [probable] surplus of CPU in the cluster, it's unlikely that your app will be starved for CPU. And does your app's frontend really perform all that much computation? On the other hand, what happens when there is a blip in datastore/network/whatever latency? Assuming you're running at reasonably optimal concurrency, you're suddenly going to need many more instances. Your bill is going to depend heavily on factors entirely outside of your control. Before, the health of GAE was Google's problem. Now it's your problem. Jeff On Sun, May 22, 2011 at 6:53 AM, Anders blabl...@gmail.com wrote: And it is said that the new price model is more transparent. But CPU hours at least sounds more transparent. How many instances share the same CPU in a GAE server? 1, 2, 10 or 100? The new price model seems more opaque. For example, if 10 instances share the same CPU, then only (at best, not counting overhead) 1/10 of the CPU power will be available to each instance given they consume the same amount CPU time each, and yet all 10 instances will be billed the full price! What a rip off. Or probably I have missed something, but still, it's not clear. A better price model is needed imo. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
If the application is multithreaded then new instances would not be needed, but yes if it's a single thread application and new requests need to be served then I suppose new instances must be spawned if the latency becomes too large. But will that happen often in practice? -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
On Sun, May 22, 2011 at 11:48 AM, Jeff Schnitzer j...@infohazard.org wrote: optimal concurrency Thinking out loud here... this is an interesting phrase. Imagine for a second that GAE was built on Node.js or an equivalent fully-asynchronous server. In this environment, RAM is not the limiting factor, CPU is. Any single instance will scale up to almost any number of concurrent requests, limited only by maxing out a single CPU core. You only need another instance when you need another CPU core. This ignores the cost of RAM consumed by idle instances, but that is a sunk cost. Both old and new pricing strategies assume a single free instance to everyone no matter what. Yeah there is a cost for that but it's a cost that Google has chosen to accept, so it leaves the equation. Multithreaded Java servers may be somewhat less optimal than a purely async system WRT concurrency, but they should be good enough. My experience with JBoss clusters on modern linux is that unless you're doing long polling, you run out of CPU long before you run out of the ability to spawn new threads. So, if GAE had efficient levels of concurrency, the old pricing model (CPU time) would actually make a lot of sense - almost all apps would have a single instance until they're sucking down so much CPU time that they need another instance. RAM is not the scarcest resource - you'll run out of CPU cores long before you'll run out of additional 128M chunks of RAM. Of course, scheduling a highly concurrent instance is harder - a hot async instance will have a much larger impact than a hot single-threaded instance, and a hot multi-threaded instance will be significantly harder to manage than even a hot async instance. But this is why Google hires the smarties. It's the legacy single-threaded servers that makes CPU-time pricing unsustainable. These systems consume vastly more RAM than they should for equivalent amounts of traffic. They need to be priced much higher - but this price is likely going to be higher than any mass consumer application developer is willing to pay. Since-threaded blocking servers are just not cost-effective in 2010. They probably never were, but Google hid that from us. I wonder if this pricing model switch, which makes sense for the legacy single-threaded systems, is actually going to be a liability when everyone is converted over to multithreaded systems. At that point, CPU may be the bottleneck again. And the pricing model will need to change again. Put it this way: A single multithreaded Java appserver instance should be able to happily consume every last CPU cycle on a frontend box - and that's just the free tier. Or maybe Google doesn't believe they will ever be able to get close to optimal concurrency, even with multithreaded systems. That would surprise me. Maybe the answer is that there needs to be two pricing models, or some pricing scheme that discourages development of inefficient single-threaded blocking applications. Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
On Sun, May 22, 2011 at 3:04 PM, Jeff Schnitzer j...@infohazard.org wrote: Since-threaded blocking servers are just not cost-effective in 2010. That sentence should read Single-threaded blocking servers are just not cost-effective in 2011. Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
Re: [appengine-java] Re: Feelings about new pricing model
Put it this way: A single multithreaded Java appserver instance should be able to happily consume every last CPU cycle on a frontend box - and that's just the free tier. That presumes that the JVM that sandboxes the app is given access to all the CPU cycles. Nothing precludes mapping all Java threads onto a single native thread, for example. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Feelings about new pricing model
On 11 Mai, 05:07, Spines kwste...@gmail.com wrote: I'm quite unhappy about the new pricing. The pay per usage model was the main reason I chose GAE. That's it. I don't want to think about how many instances I might need. I like it the way it is. It's a big advantage that google appengine starts instances just when it needs to. I always tell people that this is the big reason for me taking appengine as platform. On Amazon I have to think about how many servers I need and do the communication between them. That's not necessary on appengine. I don't want to by instances, I just want CPU time! Thanks. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Feelings about new pricing model
Discussion and some responses from Google Product Management here: https://groups.google.com/d/topic/google-appengine/VCYbRH4WWBI/discussion -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
[appengine-java] Re: Feelings about new pricing model
I'm quite unhappy about the new pricing. The pay per usage model was the main reason I chose GAE. On the old model, I could handle a reasonable amount of traffic with just paying $9/month for getting 3 reserved instances. Letting my users get loading requests is bad since my loading requests take 10 seconds. Now it looks like I'll have to pay $45/month ($9/mo for premium + $36/mo for 1 reserved instance), and even paying that much, my users will experience more loading requests since there will only be 1 reserved instance instead of 3. On May 10, 2:25 pm, JT jem...@gmail.com wrote: Moving away, hosting ourselves on RISK based architecture like guruplug/dreamplug. Cost less than a dollar per server per month :) On May 10, 2011 5:18 PM, Marcel Overdijk marceloverd...@gmail.com wrote: Today Google announced the new pricing model to be effective later this year (http://googleappengine.blogspot.com/2011/05/year-ahead-for- google-app-engine.html). I always like the pay per usage model compared to the pay per instance model. Because of this change by Google, other platforms - like VMware's CloudFoundry - might be on the same pricing level and offer more advantage as they are more flexible in terms of frameworks supported. I'm wondering how other developers feel about this change in pricing model. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine for Java group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
