This morning I did some final testing and because app engine team
introduced 'quota details' page with some more explanation in
http://code.google.com/appengine/docs/quotas.html link now I am
thinking that I created a little bit more complicated code than I
needed. Just because they introduced suggestion warnings in admin
console log with yellow and red colors plus some warning sign from the
beginning.
I am using app engine last half year and I have read almost every
article, watched every interesting video and constantly read app
engine group discussions. In the last half year every now and then
they explained more and more about high cpu quota, difference between
api cpu and our code cpu usage and difference in its presentation over
the admin console.
My final test was simple:
class Test(webapp.RequestHandler):
def get(self):
for i in range(200):
t = Testna(podatak = str(i))
t.put()
self.response.out.write('radi')
Results were like some religious revelation for me:
http://picasaweb.google.com/matija.jerkovic/GoogleAppEngine?authkey=9MVoK12s0SA#5281097404943213970
http://picasaweb.google.com/matija.jerkovic/GoogleAppEngine?authkey=9MVoK12s0SA#5281097405750931410
Although they stated over and over (not at the beginning but lately)
these results, I needed proof. And now I have it.
I will not be punished (in quota sense) for more than one datastore
write operation. During my test I had no high cpu quota usage. There
was some warning but I think that they are there when we are near 8s
limit per request, and when we break this limit, but even then this
was not counted as high cpu quota.
I understand contention problem and even user experience with too slow
response, but I will not be punished, temporary baned or something
like that.
This is so important for me because I mostly need more write operation
only for administrative purpose. Not 200 writes but let's say 10 or
20. With bigtable system we are creating super redundant datastore,
but when I need to correct (for some reason) that data, now I know
that I don't have to do this in thousand 'one write' operation step,
than in a 50 (or less) '20 write' operation request. If I do this when
there is low usage (night for example) I could even bypass some
contention problem.
Second reason was lack of model count ability. So when I needed to use
additional counter model with shard principle for avoiding contention
problem. But I needed two write operation. In my fear of 'punishment'
i did this in two connected ajax requests. If first request (write
operation) succeeded I will send second request to increment count.
With this approach I was under 1000 mcycles cpu usage (with datastore
api), but this also introduced new problems. What if second request
has not succeeded. What now.
Now I have wrong count data. With this more complicated approach I had
problem and even I have thought that app engine could not be used for
serious purpose where this discrepancy in data is not an option. Last
five years I was lead developer for hospital information system so you
can understand my fear for error data. Counting comments on web page,
poll data or something like data can have 99% precision but something
else can't. Of course I am not developing now something serious like
hospital information system but it takes time to switch from 100%
desktop application data to 99% web application data.
And now I have found out that this was not necessary and that I can
have 100% data precision in connection with user perception of
succeeded or not succeeded operation. I can have two, four, six or
more write operation in one request only if I stay under 8(or 9?)
seconds time request limit because contention can impact only on
request time limit.
All these high cpu fuss (in connection with write operations, of
course) were just design warnings and not some forcing statement.
Or am I wrong again ?
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
