On Wednesday, 7 September 2011 15:11:58 UTC+1, Mike Wesner wrote:
>
> Please stop telling people to use these settings.  Nobody will use the 
> damn service if they have to wait for seconds for a request to load. 
> Please either setup an app to run well and pay for it or use something 
> else. 
>
> I am a bit surprised that 15s is even an option for min-pending 
> latency... that is just crazy. 
>
>
I partially agree with you but there are some valid cases where latency of 
10 or 15 seconds isn't an issue: for example, most of the "expense" for my 
app is the single-page-webapp front-end doing lazy writebacks of updates by 
AJAX calls (it buffers updates in the client code until there's a sizable 
chunk of updates or a period where the user doesn't make any updates, like 
the auto-save of drafts in gmail). 

So a few seconds of pending latency is not an issue. I already have to cope 
with the fact the user may apply more changes to the data while the 
writeback is in flight, or the writeback fails and has to be retried, so 
upping the latency isn't too much of an issue. Of course, the same latency 
when READING the data in the first place (the app is served mostly from 
static files, but the javascript then loads the user data via AJAX calls as 
the page renders) is less than ideal, so I agree with you in the general 
case.

That's why if the scheduler works more like it now sounds (see my comments 
on another thread about what the "15 minute" minimum count actually means), 
then I'm happy to experiment with my latency (of course, it would be even 
nicer to be able to specify the latency per handler in the app.yaml or 
prioritise handlers or similar), and then it comes down to whether I can get 
the number of datastore write operations down to a reasonable number (which 
might involve changing the way I model the data so every chunk of updates 
can be written by a single write call and then making the read operation 
more complex as it has to effectively unpack a collection of deltas, each of 
which can be modifications to a number of logical records, and apply them to 
form a consolidated set of data records).

--
T

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/S6h7T85-k4QJ.
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.

Reply via email to