It's sad how we find ourselves thinking about not implementing stuff,
because of the pricing...
The new pricing Model had to be implemented, we can all agree on
that... but the pricing itself is too high!
Does Google servers cost that much more than Amazon's? I'm sure that's
not the case.
On Nov
Maybe Google Cloud SQL will better suit your dataset.
--
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/-/cc22RSpIbToJ.
To post to this group, send ema
I hear what you're saying, but at that rate I'm pretty much rewriting my
application plus cost isn't even known. And I like the datastore.
The problem as always is how the app was written. Users can update one
field at a time on a data grid and save it back via ajax, so that's
seriously not e
link does not work
--
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/-/JHLT-C_FgEwJ.
To post to this group, send email to google-appengine@googlegroups
> 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
After managing my instances, I had a similar sticker shock with data store
usage. However, the app stats utility, even though its really built around
the old pricing model, was invaluable in telling me what my heavy hitters
were in terms of data store ops. I implemented caching for my most
import
FWIW, your app would have been a problem under the old pricing model
as well. The only difference WRT the datastore is that instead of
being charged "datastore operations" you were charged a magic number
of "api_cpu_ms" per operation. The pricing model is pretty much the
same, it's just more expe
Here is an article that can help you reduce the # of composite indexes you
use in some cases:
http://code.google.com/appengine/articles/indexselection.html
On Tue, Nov 8, 2011 at 4:16 PM, Jeff Schnitzer wrote:
> FWIW, your app would have been a problem under the old pricing model
> as well. The
On Mon, Nov 14, 2011 at 4:27 AM, Volker Thiel 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 t