51–60 of 63 posts
I'm starting to notice that App Engine's memcache is incredibly slow. If serving up a page requires one memcache hit (for, say, caching entire response objects), it works well. If it starts to require, say, a dozen, the response time slows to ~700ms at best, and ~4s at worst.
On the other hand, GAE looks like a great fit for a static site built with Jekyll, like a personal blog. In fact I'm planning to migrate my site over today. Almost any personal site will be free to host. Even though I would only be paying a few dollars with S3, I see no reason not to give app engine a shot. One thing I worry about is the reported downtime. I'm not sure whether or not that will affect a static site.
Django might not be the best tool for GAE.
My experience agrees with this. It should be noted that this is largely due to cold start time.
I'm starting to notice that App Engine's memcache is incredibly slow. If serving up a page requires one memcache hit (for, say, caching entire response objects), it works well. If it starts to require, say, a dozen, the response time slows to ~700ms at best, and ~4s at worst.
Oh wow, that's surprising and somewhat disconcerting. Do you have any sort of reference? If true, it's very serious.
Earlier quoted context omitted.
1) Yep. My company moved to an HRD instance this week and our CS reps and customers have both noticed a significant difference in stability. That doesn't imply that it's perfect but to say that Google is ignoring the issue is completely false.
How bad was the cost differential?
Earlier quoted context omitted.
Oh wow, that's surprising and somewhat disconcerting. Do you have any sort of reference? If true, it's very serious.
I have no exact data at the moment. I looked through my application's logs and compared the response times in situations when the front page loads from a full-page cache entry and when it has to build the page from multiple pieces of memcached data. If I find time, I'll write a small benchmark application which tests memcache performance. Empirically however, App Engine's "memcache" is pretty slow.
Earlier quoted context omitted.
Can you illuminate that a little? Among the competitors, GAE appears to be among the lowest cost platforms. I'm sure there's certain types of applications that can cause it to become expensive, but I'm not sure I can predict well enough what those are.
Like the application being built by the author of the post. Query eats up CPU time etc.
At a high load (50+ requests/sec), we saw database timeouts tens of times per minute, and often more (every request in a 10-60 sec period would fail).
That's not a terribly high load by any modern standard, you can easily service that on one or two fairly commodity machines these days.
Assuming the point of GAE is scalability, this issue didn't make any sense to me. One would assume that Google would simply load balance requests out to replicated instances of your app and that those apps would in turn access Google's vaunted super scalable data services. Thousands of requests a second shouldn't even phase it.
I've noticed that response times can be highly variable, but so far (we're pre-launch) I haven't noticed anything just simply not getting returned or the kinds of slowness he's describing. Without more detail, something else must be going on here.
Earlier quoted context omitted.
I am building everything on AppEngine atm. Initially it was just to prototype but I am thinking of launching a preview release of one app live Can you talk about how big some of the larger customer apps are and how much traffic/uers they serve? It would be easier for ppl in a position like mine to make decisions about AppEngine if there were big examples/case studies to point to in the same way Amazon, Heroku, Racksp…
I can't give any current numbers, but last year we did a blog post about Gigya who had an app that peaked at 1600QPS: http://googleappengine.blogspot.com/2010/02/scalability-mean...
I don't quite understand with some of the commenters: why do you guys talk about caching immediately as if your app needs to scale from the ground? Isn't the point of GAE is that it scales (as long as you don't do stupid queries)? If we have to put everything in memcached, what's the point of using GAE? I also don't quite understand the push of using memcached for almost everything (especially for young startups). Ho…
Your site will scale well - as in it will give exactly the same performance for the millionth user as for the first user. That doesn't mean you will have a fast site, though. On GAE the datastore is pretty slow (it's a lot better now, but it used to be terrible), so a common pattern it to use a read-though cache to improve performance. I wrote a thing that touched on this a couple of months back: http://nicklothian.c…
I heard stories where some people that use Spring MVC would have their request fails because the call stack is too deep.
Earlier quoted context omitted.
Your site will scale well - as in it will give exactly the same performance for the millionth user as for the first user. That doesn't mean you will have a fast site, though. On GAE the datastore is pretty slow (it's a lot better now, but it used to be terrible), so a common pattern it to use a read-though cache to improve performance. I wrote a thing that touched on this a couple of months back: http://nicklothian.c…
I saw your blog. One question for you if you're using GAE/J: how heavy it is the GAE/J warm-up compare to GAE/Python? I heard stories where some people that use Spring MVC would have their request fails because the call stack is too deep.
The worst offender is the data access libraries. JPA is bad, JDP slightly better, but something like Objectify works really well.
Typically, Spring isn't the problem (I guess it could be if it is doing a lot of classpath scanning stuff or something though)