I didn't need task queues/defer because I was self managing queues and in fact do that more than using task Queue still because it lets me do more process shaping. So now short term tasks are defer, and long term tasks go in to a self managed bucket that fires based on current load as determined by the number of instances active.
> * 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.) > * 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. > * 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? Web.XML at the individual app, but path routing is handled by the caching/loadbalancing that is done using the python version of CDNInabox for most our apps, and Squid on another service for some of the other Apps. No "App" ever is exposed directly to a user request, they are all proxied. (ps this also allows us to do much of our own QoS manipulation because we can send a request that is taking too long to an F8 that has multiple apps installed on it and can be anything it needs at a moments notice. > * 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. > * 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 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. > -----Original Message----- > From: google-appengine@googlegroups.com [mailto:google- > appeng...@googlegroups.com] On Behalf Of Jeff Schnitzer > Sent: Saturday, July 21, 2012 9:27 PM > To: google-appengine@googlegroups.com > Subject: Re: [google-appengine] Re: Startup time exceeded...on F4?! > > Brandon, you talk a lot of shit for a guy who only discovered the task queue 6 > months ago. > > Everyone who thinks they have the secret to starting up a Java app in <5s, > answer these questions and prove that you're running more than a > toy: > > * How do you persist data? (low-level, jdo, objectify, etc) > * How many entity kinds/classes do you have? > * How do you manage URL routing? (ie, jsp files? web.xml? JAX-RS) > * How many URL endpoints do you have? > * How many total java classes in your application? What is total size? > * How many jars in your WEB-INF/lib? What is total size? > > Having done a fair bit of experimentation around this issue, I know that > you're talking out of your asses. Clever suggestions like "rewrite app in > Python" aren't nearly as clever as you think they are. > Suggestions that you can optimize startup time by some combination of > caching, task queues, or threading merely indicate total lack of understanding > of the problem in the first place. > > To the people paying attention to this thread who are actually trying to build > real world apps on Appengine: Brandon does not speak for the GAE team. > Neither do I, but I occasionally talk to people that do. I know that Google > really does want Java apps to run well on GAE. They know about this issue > and care about it - maybe even enough to do something about it. It *is* > constructive to "whine" politely about startup time because there are many > issues competing for the team's time, and our feedback helps them prioritize > their efforts. > > Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to google- > appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
