Status Update
Comments
ko...@googlemail.com <ko...@googlemail.com> #2
ma...@google.com <ma...@google.com>
Jo...@hotmail.com <Jo...@hotmail.com> #3
processing of a request, so I can stop processing and return a page informing the
user that the server is busy with a link to a URL that will pick the processing and
finish it off.
Jo...@hotmail.com <Jo...@hotmail.com> #4
As there is a soft cap of 1000 on the mcycles an app consumes processing a
request, its necessary to be able to determine how many mcycles indidvidual
subtasks and API calls are taking to determine why the processing of a
particular request is going over the magic 1000 mcycle number.
Currently doing this requires pulling chunks of the request processing out
and into two nearly identical requests and then running through each one.
The different between the two nearly identical requests is the chunk of
code you are trying to determine the mcycle consumption of. The one
without is the baseline and the other yields the number to subtract the
baseline from to get the actual mcycle consumption of the chunk of code of
interest.
This is a very inefficient way to get this data.
t....@gmail.com <t....@gmail.com> #5
ol...@googlemail.com <ol...@googlemail.com> #6
error messages before the quota is exceeded 100%.
rr...@gmail.com <rr...@gmail.com> #7
iz...@gmail.com <iz...@gmail.com> #8
ad...@gtempaccount.com <ad...@gtempaccount.com> #9
st...@gmail.com <st...@gmail.com> #10
real-time would be a given.
ki...@gmail.com <ki...@gmail.com> #11
je...@gmail.com <je...@gmail.com> #12
[Deleted User] <[Deleted User]> #13
cr...@gmail.com <cr...@gmail.com> #14
wi...@gmail.com <wi...@gmail.com> #15
ja...@gmail.com <ja...@gmail.com> #16
ja...@gmail.com <ja...@gmail.com> #17
fr...@qmining.com <fr...@qmining.com> #18
How can we create viable applications on appengine if we can't automate a pricing layer on top of google appengine usage statistics?
If I want to deploy appengine SaaS for my customers, how can I automate my billing without this critical feature? Please give us an alternative (screen scraping
My understanding is that google want to make sure we don't build revenue based solution on appengine platform.
Before choosing appengine I could have never thought the usage API could be hidden.
Changing pricing model + hidden statistics will kill this great dev plateform.
Francis
ce...@gmail.com <ce...@gmail.com> #19
I think that new pricing definitively blocks development application with "pay per request/usage" policy - I can not offer something which is not predictable.
You not report i/o, latency, execution times in dashboard per request type - it kind pig in poke currently.
Only logs shows some information but it no complete and it partially obsolete i.e. cpm_usd which has different value from time to time for the same request.
"GET /order-in-restaurant?hash=3777e6080ef6c4383d3316eafb45536294187f220efeabe80d45d42e73cb4ddc HTTP/1.1" 500 0 "
er...@gmail.com <er...@gmail.com> #20
bt...@brandonthomson.com <bt...@brandonthomson.com> #22
it sucks compared to getting an email, but I guess it's better than nothing. Maybe try that if you have the same need.
ce...@gmail.com <ce...@gmail.com> #23
We strongly need quota API allowing getting statistics at least the best will be to get some notification when quota is high or hook such events but it is harder to define such api. Please provide at least quota statistics to read.
ga...@gmail.com <ga...@gmail.com> #24
dr...@digifit.com <dr...@digifit.com> #25
ma...@gmail.com <ma...@gmail.com> #26
gi...@gmail.com <gi...@gmail.com> #27
But seeing it is open since 2008 is kind of disappointing.
ra...@flarb.com <ra...@flarb.com> #28
[Deleted User] <[Deleted User]> #29
I could make it available via github if there's enough interest.
do...@gmail.com <do...@gmail.com> #30
thanks
re...@renanmobile.com <re...@renanmobile.com> #31
va...@gmail.com <va...@gmail.com> #32
GAE team, please provide an api to read statistics per quota.
thanks.
er...@gmail.com <er...@gmail.com> #33
[Deleted User] <[Deleted User]> #34
Feedback welcome. May need some minor tweaking depending on your environment.
sa...@gmail.com <sa...@gmail.com> #35
It's not as powerful as the web based dashboard but you can check on e.g. costs and quota details. Even has app widget to track quota stats.
re...@gmail.com <re...@gmail.com> #36
gu...@gmail.com <gu...@gmail.com> #37
[Deleted User] <[Deleted User]> #38
jo...@gmail.com <jo...@gmail.com> #39
ja...@gmail.com <ja...@gmail.com> #40
js...@google.com <js...@google.com> #41
It's likely that the 300+ people following this thread had some applications in mind which aren't enabled by the Admin API. If so, feel free to open new feature requests. As much as possible, please keep each feature request limited to a single business case or workflow; this will help us out as we triage and work on future features.
js...@google.com <js...@google.com> #42
kl...@google.com <kl...@google.com> #43
ph...@gmail.com <ph...@gmail.com> #44
vi...@gmail.com <vi...@gmail.com> #45
Unfortunately these endpoint don't enable Cross Origin requests. Would it be possible maybe to enable it?
[Deleted User] <[Deleted User]> #46
just out of curiosity i checked the quotas and found that it used 32, is that correct for one voice request?.
va...@google.com <va...@google.com>
ku...@google.com <ku...@google.com> #47
Hello,
I hope that our product engineering team has resolved the reported issue. It looks like the request has been fulfilled as documented in
As per our understanding, the above links have fulfilled the original requirement as stated in
Thank you!
ku...@google.com <ku...@google.com> #48
Hello,
Thank you for your engagement regarding this issue. We haven’t heard back from you regarding this issue in a while. As noted in the above comment, we believe the requirement for the reported issue has been fulfilled.
Therefore, we’ll go ahead and close this issue now, which will no longer be monitored. If you have any further questions or encounter any new issues, please don't hesitate to create a new issue on the
Thank you for your trust and continued support to improve Google Cloud Platform products.
Description
applications to dynamically disable resource heavy features when the site
is under high load. Secondly if load became too high the application could
completely shut down itself down serving a static page that fit with the
applications styling and layout.