That is indeed an interesting suggestion, but I suspect it might be unworkable at that granularity. If you have an idle instance occupying 20 MB of a 128 MB instance class, GAE can't make use of the remaining 108 MB without restrictions. If your instance suddenly needs more than 20 MB to process an incoming request then it could not have it available (without paging) because some other process would be using it.
Perhaps a clever combination of scheduling and non-guaranteed QoS instances would allow such finer granularity. A statistical analysis could allow various apps with intermittent usage spikes to be combined on the same servers / instance class partitions, in such a way that you would known with a given probability that no trashing (massive paging) would occur. Different probabilistic QoS / performance classes could be worked out. BTW, some QoS questions: 1) regarding backend classes: I suspect the B8 4.8 GHz is a 2.4 + 2.4 GHz dual core. Is it so? shouldn't that be advertised? It's not the same for some apps. 2) What exactly is, anyway, the provided QoS of the various instances? A B1 with 600 Mz is surely a server being partitioned in various class configurations. But Linux is not a real-time OS, so the other processes probably can have a significant worst-case impact on your apps' performance. What that impact can be should probably be better disclosed. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
