3 ms·
If RAM is the one GAE charging for, then they are massively overcharging the apps. Spawning a new process off a parent process takes very little memory. Most
by ww520 15y ago
If RAM is the one GAE charging for, then they are massively overcharging the apps. Spawning a new process off a parent process takes very little memory. Most of the memory of the child processes are shared with the parent process. That's how Python/Ruby/Perl/whatnot web apps work. They spawn a new process to handle each request because it's really cheap on CPU and RAM to do so.
The first GAE instance process on a server would take up fair amount of RAM. The next one takes very little. Yet Google charges for the second one fully.
- Scaevolus 15y agoEach instance on GAE runs on a different physical server.
- ww520 15y agoYou have source for that? Otherwise those must be really pony physical servers cause people are getting Out-Of-Memory error at around 100 megs.
- stickfigure 15y agoI suspect what he meant is that when GAE spins up a new instance of your app, it will try to locate it on a different server. This is a natural way to prevent hot instances from overwhelming a single box in the cluster.
- stickfigure 15y agoThis hasn't been true for a very long time. Back in the olde days of C programs with large code/data segments and tiny heaps it would be true. But things have changed: * In modern interpreted/JITed languages, the "code" is actually data that gets malloced. These segments are not shared. * Modern interpreted/JITed applications eat VAST quantities of heap. They constantly produce garbage, most of which (hopefully) gets culled by the garbage collector. On GAE, even small Python instances typically grow to 30-40MB. Java instances typically hover around 90MB. The actual per-instance reservation must be significantly larger because boxes can never be allowed to go into swap. Figure that Google allocates ~128MB for every single active instance of every single application. It's a lot.