frontend instance specs

[GR]

What are the memory and CPU specs of the frontend instances we are paying for?

[Gopal Patel]

dont know what we are using, but we are charged for 1.2Ghz intel single core. and 128MB Max before instance get killed.

On Sat, Sep 3, 2011 at 9:50 PM, GR <goo...@gmail.com> wrote:

What are the memory and CPU specs of the frontend instances we are paying for?

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

[Anders]

1.2 Ghz Intel single core? What about time sharing? I suspect Google squeezes in a lot of instances in each physical server, so that with time sharing of the CPU the instances in reality get a lot less than that when the load is high, and judging by how often instances are swapped in and out of servers, it means that there are way too few physical servers to handle the practical load.

Compare with a virtual memory. If there is too little physical memory, the page swapping algorithm, no matter how good it is, will have to do a LOT of swapping of memory pages. And what do we see the GAE instance scheduler do? A LOT of instance swapping.

Not only that, we as customers have to pay a large part of that page swapping, plus poor performance when the traffic to the application is low. AND, much if not most of the actual specs for the instances is kept hidden from us customers. So it's very hard to tell what we actually will be paying for, plus Google can change the specs at any time without adjusting the price model. It's opaque as hell.

[Anders]

Also, another indication that too many frontend instances are sharing the same physical server is that I have noticed that even with low traffic the scheduler usually starts many instances. What should easily be handled by one frontend instance is handled by a whole bunch of instances, and we as customers will have to pay for that! It's completely outrageous unless I have missed something.

[Ugorji Nwoke]

Hi, Can you point us to where you got this from or how you figured this out? I can see the 128MB (I used a sample app to figure out when App Engine starts throwing OutOfMemoryErrors), but where did you get the 1.2 GHz CPU from? Is there a document somewhere you can point to, or did you decipher it, and if so, how?

Thanks.

[Raymond C.]

As far as I can remember, I dont think we have seen the CPU spec neither.  1.2 GHz CPU is used for calculate the CPU time we consumed in the old pricing model.  Back in the day we dont (need to) care how fast the CPU runs. 

[Gopal Patel]

1.2Ghz is not our app runs on. That's reference point to calculate cpu charge. i.e. if a 3.6Ghz server take 300ms to response, it will be charged as 900ms. but thats history now, no more cpu. only instance time. 

On Sun, Sep 4, 2011 at 8:20 AM, Raymond C. <wind...@gmail.com> wrote:

As far as I can remember, I dont think we have seen the CPU spec neither.  1.2 GHz CPU is used for calculate the CPU time we consumed in the old pricing model.  Back in the day we dont (need to) care how fast the CPU runs. 

--

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

[zdravko]

It matters even more now than before to make sure that one instance
can handle as much as it possibly can.

[GR]

Especially once python 2.7 support is finally here... CPU will matter more than latency at that point from what I understand.