200 1625ms 98kb Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1092.0 Safari/536.6 70.162.197.131 - - [22/Jul/2012:01:38:53 -0700] "GET /www.xyhd.tv HTTP/1.1" 200 98752 - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.6 (KHTML, like Gecko) Chrome/20.0.1092.0 Safari/536.6" "second.cdninabox-java.appspot.com" ms=1626 cpu_ms=844 api_cpu_ms=0 cpm_usd=0.042899 loading_request=1 instance=00c61b117c382cd6d2d719025a767570ad95c0 I 2012-07-22 01:38:53.885 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application.
I read that as 1.626 MS. What I did in that time on an F1. Initialized the App from nothing. Read the configuration out of Datastore (not even from Memcache) Did a URL Fetch to read the contents of XYHD.tv (like you doing your read from file) Regexed it to change all the paths from relative to absolute. Deferred a write to the datastore so I wouldn't have to do that for the next request that comes along in the next 30 seconds. Output the data. I still have 370 Ms to do something else. And that is on an F1. I think that counts as Hello world. > -----Original Message----- > From: google-appengine@googlegroups.com [mailto:google- > appeng...@googlegroups.com] On Behalf Of Jeff Schnitzer > Sent: Sunday, July 22, 2012 1:18 AM > To: google-appengine@googlegroups.com > Subject: Re: [google-appengine] Re: Startup time exceeded...on F4?! > > On Sat, Jul 21, 2012 at 11:32 PM, Drake <drak...@digerat.com> 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 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.
