Scratch one cause off of the list. I found out that the client would always send each request without credentials, the server would kick back a 401 and then the client would resubmit with credentials every time! It was nuts, two requests for each useful request :( Since doing that the app has been performing much better.
On Fri, Mar 12, 2010 at 11:55 PM, Tim Hoffman <[email protected]> wrote: > Hi > > Have you checked that startup times on a lightly used system are not > inflating your response times ? > > T > > On Mar 13, 3:05 pm, Patrick Twohig <[email protected]> wrote: > > Hi, > > > > I asked once before, but I'm getting some painfully slow requests in my > > app. Even on queries that I am certain only fetch a few entities, (5-10 > max > > under absolutely worst case circumstances). I also take advantage of > memory > > caching wherever possible, and I have confirmed (via logging) that I'm > > pulling from the cache. Some requests are taking upwards of 2-3 seconds. > > And given that my app right now is mostly a web service and not running > in a > > browser, there's quite a few things that are perplexing me. SO I have a > few > > questions: > > > > - I'm running JAX-RS (Jersey), a little Groovy, low level API (no JDO > or > > JPA), and Guice (yep, I'm a Google fanboy). I have identified where > Groovy > > is being slow, and came up with a workaround for that, so I'm not too > > concerned. > > - What's a reasonable number of entities I should fetch from the > > datastore per request? I currently fetch at least one per request to > > validate a user's login credentials, so no matter what I'm fetching at > least > > one per request. Adding up the numbers in my head, I don't think that > > - Even with aggressive caching, (all of my data objects get put in > > memcache), it still behaves rather slowly? What is the penalty > speed-wise > > for using a transaction? I can't use caching with a transaction > obviously > > because I can't be guaranteed any consistency of data. If I start a > > transaction and and commit it or roll it back and perform no > operations in > > it, what is the penalty? I'm certain this happens in my app, albeit > very > > infrequently. > > - What's up with queries? They just tend to be really really slow. > > - I know loading requests are a problem, but I'm not hitting many of > > those according to the logs, so I can rule those out as being a > contributing > > factor (unless there's something I don't know). I also don't use > JSPs, most > > of it is static. > > - How much of a performance difference does a bulk fetch/put cost > versus > > a bunch of individual ones? I haven't seen much of a difference, but > maybe > > I'm doing it wrong. > > - There are zero use cases in my application where more than two users > > write to the same entity group, except for a counter for which I use > > sharding offloaded to the task queue. Is there a penalty for many > users > > reading from a single entity group at the same time? > > > > Thanks, > > > > -- > > Patrick H. Twohig. > > > > Namazu Studios > > P.O. Box 34161 > > San Diego, CA 92163-4161 > > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > > -- Patrick H. Twohig. Namazu Studios P.O. Box 34161 San Diego, CA 92163-4161 -- 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.
