August 25th I have an app launch. It is no small thing. My CDN is a Toy in the view you have of it. But the internal version is designed to make all the other stuff work. It is a load balanacing url handling, code modularizing tool. But you keep slamming my CDN because you like those other "CDN guys" but it is just an enabling technology for everything else I do.
Because of that tool I can do www.myappp.com/user/12354 as an app in python, and www.myapp.com/products/12345?view=json in Java, and www.myapp.com/search/frogs as Go. And if I really want, /checkout/ can go to PHP on Dreamhost. That gives me infinite more control. It also lets me share databases because java.myapp.appspot.com can share data with python.myapp.appspot.com . So that comment that you can't convert your code to Python... You don't have to convert all of it, or all of it all at once. Maybe my bias is that because without such tech you have to do web.xml stuff or that it is hard to modularize your app that I'm so jaded by it's awesomeness that I can't see past, but... Typically when a company asks me to refactor code the first thing I do, is break their code in to groups that share classes/imports/frameworks and create 3-4 apps from those, and then use a "load balancer" or a "front end proxy" or a "Templated API wrapper" to make that app faster and more scalable. Step two is convert as much as possible to lowlevel api. Step 3 is to strip everything out of every framework that they aren't using. Step 4 is to create flatter versions of their data to make queries simpler, faster, and more friendly to the lowlevel API Step 5 is to prioritize writes and reads so that things can be delayed if they aren't for realtime data Step 6 is to optimize start ups using serialization of configuration strings, and other data. Pushing any file streams to Memcache Step 7 is to create a task database to create precaclulated versions of common requests, and to handle cron and steady state tasks. Step 8 is to make determinations about lazy loading. (I try hard to not lazy load because it makes your app harder to profile, because if you lazy load a large frame work you may over run the soft memory limit. If you do everything up front then you know what your steady state memory usage is) Step 9 is to self manage parts of the memory. Rather than relying on garbage collection start throwing away memory that you aren't using. Step 10 is to profile decision trees, to optimize order of operations. Step 11 is to manage threading (this is often late in life because it makes debugging hard, and the gains are often not amazing in apps with lots of simultaneous users) Step 12 is to strip all the debugging, logging and non-esential stuff from the code. Rinse and repeat. -- 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.
