Hacker News new | ask | show | jobs
by dantkz 5685 days ago
In the comments he says that the restrictions were not THE problem, THE problem was the instability. List of restrictions is kind of reminder of what he had to cope with, and wasted money on, until it turned out that GAE doesn't work properly.
1 comments
nl 5685 days ago
In my experience "instability" with GAE means you are pushing it beyond where it wants to go. If you a have code that just completes within the timeout, then guess what? When the system is under load it isn't going to complete.

You can use all kinds of techniques to protect your application from things like variable datastore performance. For example, nowdays I usually use a pattern where user-facing servlets only ever read from the datastore - all updates go via a taskqueue, which means that even if the datastore is in maintenance mode the updates will eventually be applied.

GAE isn't for everyone, but the first step to getting the most out of it is accepting it isn't anything like a typical frontend plus database architecture.

link
mmastrac 5685 days ago
Late September was bad for the datastore. We were seeing latency on simple queries vary from 50ms up to 5s. These were simple properly-value queries as well. This was fixed in early October I think, and a recent bit of maintenance brought latencies down even further. The datastore is now extremely fast and rarely errors out.

We (http://gri.pe) are still happy on AppEngine, even though September was rough.

link
grandalf 5685 days ago
Very true. The datastore unreliability was a real nightmare. I was getting periods of 60 seconds where it was unusable...

But it does appear to be fixed now.

link
nischalshetty 5685 days ago
The Datastore problems have indeed been fixed and things have been smooth since the fix.
link
fauigerzigerk 5685 days ago
" If you a have code that just completes within the timeout, then guess what? When the system is under load it isn't going to complete."

Unless the platform scales as it should, which is the whole point of accepting all the limitations. If there are tight and hard limits on request timeout, then there must be equally stringent guarantees provided by the underlying platform. "We're working on it" is just not enough under these conditions.

link