On Sat, Jul 21, 2012 at 11:32 PM, Drake <[email protected]> wrote: >> * How do you persist data? (low-level, jdo, objectify, etc) > Actually I use a multi-approach based on the work being done. Python has > NDB, CachePy, and a number of things that Java seems to missing good analogs > for, but using the lowlevel API gets things up and running and does the > majority of the heavy lifting. When we don't want to have to manage a bunch > of code to handle stuff that is more complex or do things that are less time > sensitive like deep queries for single users, we use JPA. (I think JDO is > mostly dead.)
This thread is about Java instance startup time. Enough about Python already. It's irrelevant. You've completely - and lamely - dodged ALL of my questions. You insinuate that you have sophisticated Java applications that start up quickly. I'm calling bullshit. Give me ACTUAL numbers for one ACTUAL Java application. >> * How many entity kinds/classes do you have? > A shit ton. For the analytics app we built we found out that you are limited > to 65535 and that Dynamic is not as dynamic as you might think. Generated kinds or classes don't count. I mean this literally, how many user-defined entity types does your Java app load? You're going to tell me you have Java apps that load 64k JPA classes? Not a chance. See, this is getting to the ACTUAL problem with the Java environment - classloading is slow. Entity classes must be loaded and introspected before datastore operations can start. Near as I can tell, the only way around this particular problem is to stay with the low-level api - which, like assembly programming, severely limits how sophisticated an application you can reasonably build. >> * How do you manage URL routing? (ie, jsp files? web.xml? JAX-RS) > How quaint. Did you miss that I said one type of task per app/backent? I will be generous and assume for the moment that this makes sense for your particular application. At best you are arguing that you have a wacky application. You won't find too many people building business apps that way, especially when you have elaborate transactional logic. There are sometimes good reasons to compose an app out of more fundamental services, but this should be driven by application design - not a dumb limitation of how many classes you can pack into a JAR before instance startup times get out of control. > Web.XML at the individual app, but path routing is handled by the If I went the web.xml route, it would map 326 servlets. Not really fun. There's a reason people started inventing "web frameworks" in the late 90s... because that kind of programming sucks when your app is even mildly complicated. >> * How many URL endpoints do you have? > Per app? Or In total? In many cases we have endpoints per domain in > multi-tenant apps, and we are running 10k plus domains. I was really asking about your "unicorn" java app that loads in 2 seconds. But I think you misunderstand what an 'endpoint' is. It's a particular code path; for example, http://example.com/thing/123, http://example.com/thing/456, and http://other.com/thing/789 are all the same endpoint because they all execute the same code. It's relevant because it is related to how many classes get loaded at startup, which has a strong effect on the startup latency. >> * How many total java classes in your application? What is total size? >> * How many jars in your WEB-INF/lib? What is total size? > Per app? Maybe 20. In an application deployment couple thousand. Last time > I looked our code base was nearly 800 megs, with 80% of apps at less than 10 > megs I want those numbers for your "unicorn" sophisticated Java app that you claim starts in 2s. > Jeff, my "toys" are bigger than your "projects". My unique indexed pages > in Google is over 1 Billion. I likely spend more in Datastore file costs > than you spend hosting your entire client base. Yawn. The Royal Wedding site served more traffic and probably cost more than either of us will make in revenue all year, but it's 99.9% static content. Your application is highly atypical of business applications, and yet you myopically believe that we should all build our apps out of zillions tiny components that use the low-level persistence API and communicate through urlfetches and task queues. That's retarded, and when you eventually discover the "transaction" feature of the datastore you will understand why. Jeff P.S. One consequence of my particular career history is that I'm not impressed by people trying to prove their dick is bigger. -- 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.
