Appstats and Billing

72 views
Skip to first unread message

Vijayakumar Subburaj

unread,
Sep 2, 2011, 2:06:41 AM9/2/11
to google-a...@googlegroups.com
It would be really great if appstats could include billing details. This way a developer 
would know exact billing amount, in development server environment.

Gregory D'alesandre

unread,
Sep 6, 2011, 11:59:22 PM9/6/11
to google-a...@googlegroups.com
Its a good idea, we'll see what we might be able to do about it.

Thanks,

Greg

On Thu, Sep 1, 2011 at 11:06 PM, _vjy <vijayakuma...@gmail.com> wrote:
It would be really great if appstats could include billing details. This way a developer 
would know exact billing amount, in development server environment.

--
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/-/xhGfnvdnPpgJ.
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.

Chris

unread,
Sep 27, 2011, 11:33:41 PM9/27/11
to Google App Engine
I have been using Appstats to optimize my applications as needed. It
is great for finding the chain of gets and zero in on problems. The
current version helps me to zero in on urls that use a lot of RPC's.
This is not as interesting with the new pricing scheme where I am
starting to spend more time thinking about reducing latency (to reduce
frontend instance hours) and datastore reads.

It would be a lot more helpful if Path Stats was sortable by "real"
time rather than #RPCs. It looks like you already have all of this
data, someone just needs to add the column in the GUI besides the
#RPCs column and let me click to sort by "real". Then I can more
efficiently prioritize url optimization by latency.

Chris

On Sep 7, 11:59 am, "Gregory D'alesandre" <gr...@google.com> wrote:
> Its a good idea, we'll see what we might be able to do about it.
>
> Thanks,
>
> Greg
>
Reply all
Reply to author
Forward
0 new messages