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]> > . > 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.
