On Sun, May 22, 2011 at 10:15 PM, Tom Gibara <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
