Fine I'm tired of people who want to optimize the scheduler for low traffic users, so I fixed it. (And made it better for High Volume users with Mixed task latencies)
The CDN in a box platform is now available as a Java or a Python frontend, and has support for managing backend instances. The Front end spins up in 750ms on python and 1.8s on Java, and will track the request queue which it passes to backend instances which it creates based on load and job type. Each endpoint has an expected time to completion, and can be prioritized to maximize the performance of your Queue by putting small latency request ahead of high latency requests. I don't want to support you if you aren't serious about needing this, so the pricing is $3500 set up and $500 a month, and you must be in the Google Premiere support tier. You also get the caching, HTML fixing, HTML Speed Optimizations that are built in to our premier CDN product. Lastly because you can do Queue reordering/prioritization and backend spin-up and sizing by task we expect that you can save about 30% on your operational costs, while improving your average QoS. These savings from our ability to reorder tasks right up until they have started to run, so in testing we have fewer idle CPU cycles. And because we have more ability to route tasks to servers handling similar tasks we get more efficient in instance memory usage. Downsides. You lose some elasticity. We are an intermediary, and if you get a spike of 100k users we have to spin up front end proxies and then spin up backends so if you need 10 new frontends and 50 new backends you will have to wait for a little of both to get everything in to the queue, and in testing we have seen that can be problematic, but we can't really tell how much more so than the existing schedule which suffers from lots of cold startups in this scenario. Also because of the increased efficiencies that come from this architecture you may be able to handle more requests with fewer resources so elasticity may not be as needed. I strongly suggest using the Python version of this app, because the speed is the best in most cases, and since your app can run whatever you like there is little downside to this approach. The Java version of this app has less over all overhead and uses fewer frontend hours, and maybe more performant for users averaging less than 1000 requests per minute. -- 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.
