On Mon, Nov 14, 2011 at 4:27 AM, Volker Thiel <v.th...@kosatec.de> wrote:
> > If you're churning through your datastore ops because you have 100 > > indexes, you would have churned through your CPU quota before. The > > problem is you're trying to update too many indexes. The only > > solution is "don't". > > Not true. I had an application that I optimized in CPU usage and it > was well below the limits every day. I only had two entities with a > few indexes each (three and four respectively). The latter is updated > frequently (several times a day). I (currently) have about 4000 > entities which required approximately 20 write operations on each > update. This was no problem under the old billing model! > I threw out some of the indexes but on the cost of usability. Now I'm > down to 8 write ops for a new entity and 6 for an update. I got those > figures from the dev environment, but what I'd really like to see is > read and write ops in the production logs, since the new billing isn't > focused around CPU cycles anymore. My two cents. > I don't mean to argue that the price hasn't gone up... just that it bills more or less the same way as before (which hid datastore ops in "api_cpu_ms"). They just tripled (or more) the price for these ops. Sounds like your app is in the margin of what was cheap before and expensive now. Read and write ops in the production logs would be rad. Is there an issue I can star? Jeff -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
