That's great. Thanks for doing that! On Thu, Aug 19, 2010 at 5:59 AM, Ingo Jaeckel <[email protected]>wrote:
> hello everyone, > > finally it turned out to be very easy to profile my gwt application > honeycrm using the amazing jprofiler. i created a 3 minute screencast > showing how it works http://www.youtube.com/watch?v=zUJUSxXOOa4 > > sorry for the delay when my app runs locally being profiled :) i hope > this screencast helps everyone who wants to increase his apps > performance. > > kind regards, > ingo > > 2010/8/17 ingo <[email protected]>: > > Hi Don, > > > > thank you so much for the input. It helped me alot to understand what > > appstats is for. > > > > Can anyone tell me how to setup DevAppServer for profiling with an > > external profiling tool? Normally i just run it from eclipse. > > > > I forgot to mention that my server code heavily relies on reflection > > i.e. on every CRUD operation data is copied from a generic dto class > > into the domain class object (or the other way around). I want to find > > out how much load is generated where by all this reflection to > > optimize my apps performance (e.g. DtoCopyMachine code see > > > http://code.google.com/p/honeycrm/source/browse/branches/honeycrm_r134_gwt2.1m2/src/honeycrm/server/transfer/DtoCopyMachine.java > ). > > > > Kind Regards, > > Ingo > > > > On 16 Aug., 17:28, Don Schwarz <[email protected]> wrote: > >> Hi Ingo, > >> > >> If you're making any API calls at all, there's a good chance that the > >> performance of your application depends significantly on the performance > of > >> those API calls. The goal of Appstats is to give you transparency into > how > >> many API calls you are making, and how much time you are spending in > those > >> API calls. While you cannot necessarily optimize the API calls > themselves, > >> there are important things that you can change in your application code > >> which will influence the number and speed of API calls: > >> - use bulk versions of API calls (e.g. datastore.get() to retrieve > multiple > >> entities in a single call) > >> - store commonly-accessed datastore entities in memcache > >> - use keys-only datastore queries when relevant > >> > >> If you are using JDO/JPA to access the datastore then some of this is > >> obscured from you, but it is still a good idea to know what API calls > are > >> being made under the covers. This may influence how you construct your > data > >> model. > >> > >> Now it's very possible that you aren't making any API calls at all, or > that > >> most of your time is consumed by expensive CPU-bound construction or > >> calculations within your application code. In this case Appstats will > not > >> be very helpful to you. In this case I would suggest hooking up a > >> traditional Java profiler to the DevAppServer. The performance of > CPU-bound > >> code on our servers should not be drastically different than under the > >> DevAppServer. > >> > >> On Mon, Aug 16, 2010 at 9:54 AM, Ingo Jaeckel > >> <[email protected]>wrote: > >> > >> > hello everyone, > >> > >> > okay if nobody knows an answer to this question i would like to know > >> > what appstats is all about if you can only measure (?) the time for a > >> > complete RPC request. since i as a developer cannot influence the > >> > speed of API methods (e.g. CRUD operations in the bigtable datastore) > >> > i am more interested in the performance of my own code. what is the > >> > use of appstats if i cannot measure my apps performance (see previous > >> > postings)? > >> > >> > kind regards, > >> > ingo > >> > >> > 2010/8/13 Ingo Jaeckel <[email protected]>: > >> > > hello everyone, > >> > >> > > i would like to make sure that i am reading the appstats output the > >> > > right way. is it correct to read each trace from button to top? if > >> > > that is true it seems like appstats only tells you > >> > >> > > 1. the entry point of the trace e.g. > >> > > com.google.apphosting.runtime.JavaRuntime$RpcRunnable:418 run() at > the > >> > > bottom of the page/trace > >> > > 2. the exit point of the trace e.g. > >> > > com.google.apphosting.api.ApiProxy:98 makeSyncCall() at the top of > >> > > the page/trace > >> > > 3. the time spend from entering and leaving the trace i.e. the time > >> > > between com.google.apphosting.runtime.JavaRuntime$RpcRunnable:418 > >> > > run() and com.google.apphosting.api.ApiProxy:98 makeSyncCall() > >> > >> > > if this is still correct my question remains: is it also possible to > >> > > measure the time of a fraction of the trace? thanks everyone in > >> > > advance! > >> > >> > > kind regards, > >> > > ingo > >> > >> > > 2010/8/12 Ingo Jaeckel <[email protected]>: > >> > >> hello everyone, > >> > >> > >> i enabled appstats for my java application honeycrm. now i want to > >> > >> know which parts of app take up most cpu time. at the moment i do > not > >> > >> care about the time spent in other packages. i would like to > measure > >> > >> the execution time of the methods in the package of my application: > >> > >> honeycrm.server.* > >> > >> > >> when i open the appstats ui i see a lot of huge stacktraces. > usually i > >> > >> find my sourcecode executed somewhere in the middle of the trace > (see > >> > >> attached screenshot). but as i said i would like to know the time > >> > >> spend in my methods. e.g. how much time of the selected 50ms slot > has > >> > >> been spend in > >> > honeycrm.server.CommonServiceReader.resolveRelatedEntities()? > >> > >> basically i want to identify the hotspots in my application that > >> > >> require performance tuning. but with the appstats ui i do not know > how > >> > >> to get the necessary information for that. > >> > >> > >> can anyone tell me how to identify hotspots in my code using > appstats? > >> > >> > >> i tried appwrench as well but could not get it going (eclipse > helios, > >> > >> gwt 2.1m2 on macosx snow leopard). did anyone has success with > that? > >> > >> > >> kind regards, > >> > >> ingo > >> > >> > -- > >> > You received this message because you are subscribed to the Google > Groups > >> > "Google App Engine for Java" group. > >> > To post to this group, send email to > >> > [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<google-appengine-java%[email protected]> > <google-appengine-java%[email protected]<google-appengine-java%[email protected]> > > > >> > . > >> > For more options, visit this group at > >> >http://groups.google.com/group/google-appengine-java?hl=en. > >> > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > > To post to this group, send email to > [email protected]. > > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
