Under new billing, how would a multiget/multiput be billed?

[Spines]

Doing a get of a 100 entities at once would be one API call right? So
it would cost the same as doing a get of 1 entity?

[Spines]

Similarly, with the new pricing, gets and puts will now cost the same?
I liked the old model that encouraged efficiency.

[nickmilon]

+ 1
Old model was much more on the green side.
Now we have to optimise for the new model.

[Ikai Lan]

Heh, Jeff Schnitzer asked about this during Greg's IO session : "What count as a DB operation?" TBD for the moment.

> --
> 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-a...@googlegroups.com.
> To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
>

[Max Ross (Google)]

We're still sorting out the details, but we will most likely be charging for entity reads, entity writes, and index writes.  This is actually pretty similar to what we do today, but we think the units are easier to understand than cpu.

Under this proposed model, multiget/multiput are a single api call but the cost will be determined by the number of entities you are fetching or the number of entities and indexes you are writing with that single api call.

Question for Spines:

Why do you feel that charging the same amount for reads and writes discourages efficiency?  I think the correct incentives are in place under the proposed model: For writes, if you have fewer indices on your entity your writes are cheaper.  For reads, the cost is directly tied to how much data you pull back.

Hope this helps,

Max

[Kenneth]

Today I've got 557,464 Data Store API Calls so far.  Under the new pricing model that is going to cost me 50 cents assuming they're all single reads or writes, which they're not. If I assume that the average is 10 entities, which is certainly low, I'm actually looking at $5, or $50 if the average is 100.  I'm currently paying 30 cent for cpu in total today.  Once again we're back to an order of magnitude of difference just on the datastore calls, maybe even two orders.

Google, what are you thinking.

[Brandon Wirtz]

Instance = more parity with the way other services bill.

 

CPU = More Parity with how Enterprise Sys Admins think. (and programmers).

 

I really like the price per cycle model.  Knowing that 2+2 takes 4 cycles and that as my provider gets faster it will still take 4 cycles but those cycles will take less time is reassuring because I know my pricing is fixed, and platform independent.

 

I also like know that some of my operations can be split up in to “Make left leg” , “Make head”, “make right arm” and so I can either use 1 instance for 9 months, or 9 instances for 1 month and either way have function “make baby” work.

--

[Gregory D'alesandre]

Hi Kenneth, check out Max's response from earlier, we are not charging for all the summarized by the Data Store API Calls that are currently listed in the dashboard but rather we will most likely be charging for entity reads, entity writes, and index writes.  This is similar to what we are charging today but we are just charging the operation rather than CPU hours.  Your cost for datastore operations should not go up by an order of magnitude.  We are working on getting comparative bills out so that you can see what it will actually cost.

Hope that helps!

Greg D'Alesandre

Senior Product Manager, Google App Engine

On Wed, May 11, 2011 at 9:48 AM, Kenneth <kenn...@aladdinschools.com> wrote:

Today I've got 557,464 Data Store API Calls so far.  Under the new pricing model that is going to cost me 50 cents assuming they're all single reads or writes, which they're not. If I assume that the average is 10 entities, which is certainly low, I'm actually looking at $5, or $50 if the average is 100.  I'm currently paying 30 cent for cpu in total today.  Once again we're back to an order of magnitude of difference just on the datastore calls, maybe even two orders.

Google, what are you thinking.

[Spines]

@Max Ross

I suppose if you split it up that way where writes would actually cost
more since it would count index writes too, then that would still
encourage efficiency. I've spent effort reducing the number of
indexes on my entities, and didn't want that effort to be wasted.

[Max Ross (Google)]

Right right, we don't want that effort to be wasted either.

[Sasha]

Glad to get more information on the new billing in this thread - the
new billing doc leaves many important questions unanswered. I am still
foggy on what will happen with these new billing units and whether App
Engine will still be affordable for startups and small projects (i.e.
without guaranteed paying audiences or "Enterprise" funding).

As a little feedback I don't at all think this is easier to understand
than CPU, which we've been able to measure in various ways for a
while.

How does the difference between a GqlQuery vs. a get_by_key_name
factor in to the new billing? Both are entity fetches in some sense,
but surely running the query doesn't take the same amount of time as
using the key name?

On the issue of reads and writes being billed the same: take your
typical fetch of an entity by key name, and compare it to your typical
put of an entity with a change to an indexed property. Is the
difference in CPU time between the fetch and the put entirely
accounted for by index writes? Because the concern here is whether the
new billing will maintain the ratio between the costs of reads and
writes in line with actual resource use.

[Kenneth]

Hi Greg,

Thanks for the answer.  I'm just having trouble seeing what API calls are not get and puts, are deletes not covered?

Anyhow, I'm looking forward to seeing my comparative bill.  :-)

Thanks again,

Kenneth

[JH]

Hopefully somebody from Google can confirm this info soon?

I have not participated in much of the "new price bashing" since the
initial shock of
day 1. However, to me this seems like one of the most restrictive
pricing changes of all.
If you count datastore operations by # of entities returned, these
numbers seem *EXTREMELY*
high to me.

First of all, this will put the smallest of apps beyond the free app
quota.

Secondly, this could really add up for the paid apps. I don't want to
see GAE priced out
of popularity. I think it's very important to recognize part of GAE's
appeal to this point
has been it's afford-ability. I don't want Google to loose money on
the product, but I really
hope the lack of a response is due to Google changing their mind. If
datastore operations equaled maybe
1 api call for reads, no matter how many entities returned, 50k free
+ .01 per 10k sounds affordable.
The per entity pricing will add up fast. Don't tell me it's similar
to what you do now. Maybe in theory it
is but it is so drastically different from today's quotas I believe
you are being very disingenuous
to tell people this change is not that different.

[Robert Kluin]

Hey Jamie,
In Greg's FAQ post he explained what constituted a datastore
operations. Each entity and corresponding index written is an
operation, every entity read is an operation, query results read, and
indexes scans (though scans will apparently not be billed). I agree
that this could add up fast, particularly on writes -- time to make
sure all properties you don't query on are not indexed. We've yet to
hear if keys_only queries will be billed differently, though they are
faster and hence will be cheaper since you'll use less instance time
waiting.

https://groups.google.com/d/topic/google-appengine/ob-kMuDAAqc/discussion

I know you didn't want to hear this, but it really isn't that much
different than 'API CPU time'. You can do some tests to demonstrate
this, setup a simple handler to write an entity then add an index,
write, repeat a few times and check the API CPU used. I've not done
the math to verify, but I think you are right about this amounting to
a large quota reduction.

Robert