Does Log.sendLogAsync() API have limitations in the number of requests or any other limitation of usage? I know that it works only for Pro accounts.
I've noticed that when it's invoked dozens of times by one of my apps in a short time, it stops working.
Yes. There's a 100 messages per day limit on sending logs to avoid potential spam flooding.
Related
Our application processes emails for clients. One client very often became "suspended". In GSuite Admin console he saw that he have hit "Requests limit". At the same time as gmail web interface is suspended, gmail mobile is working. Our application also do not see any interruption. We do not see nor '429 Too Many Requests "Too many concurrent requests for user"' nor '429 Too Many Requests "User-rate limit exceeded"' nor any other kind of errors.
Therefore, the user became suspended from time to time due to "request limit", we do not see any rejected requests due to limits/quotas. We do not do concurrent requests per user. That is, different users are processed concurrently but processing for one user is sequential. But we also use batching, biggest batch size is 20.
On a page about "Request limits" I found only that "the number of server requests a G Suite account can make at one time is limited". What does "one time" mean? Does batching make the issue worse or it helps? Do other apis (ex. Calendar api) counted here? Is gmail mobile counted here? Is there any way to get support for such question?
Any help is aprecated.
PS. Most calls to Gmail are history.list, messages.get (with max batch size is 5), threads.get (max batch size is 20). Calls of messages.attachments.get (max batch size is 2) are not so often. history.list and messages.get are called as new messages arrived to user mailbox. Sometimes messages.get and threads.get bursts. But we have a code to prevent getting out of quotas. Attachments are processed by 2, one batch (of 2) in 5 seconds, but we are going to slow it down to 1 attachment per 5 secs. In my opinion, the rate is low (per one user). Also the app calls other apis - gdrive api, calendar api, old contacts api.
We see 429 code very very rare. But one our client suffers from suspensions 1-2 times a week. Sometimes a suspension lasts for about 1 hour, sometimes a suspension is a sequence of several short periods of time
I'm maintaining a blog app(blog.wokanxing.info, it's in Chinese) for myself which was built upon Google app engine. It's been like two or three years since first deployment and I've never met any quota issue because its simpicity and small visit count.
However since early last month, I noticed that from time to time the app reported 500 server error, and in admin panel it shows a mysterious fast consumption of free datatstore read operation quota. Within a single hour about 10% of free read quota (~5k ops) are consumed, but I'm counting only a dozen requests that involve datastore read ops, 30 tops, which means an average 150 to 200 read op per request, which sounds impossible to me.
I've not commited any change to my codebase for months, and I'm not seeing any change in datastore or quote policy either. Despite that, it also confuses me how such consumption can be made. I use memcache a lot, which leaves first page the biggest player, which fetch the first threads using Post.all.order('-date').fetch(10, offset). Other request merely fetch a single model using Post.get_by_key_name and iterates post.comment_set.
Sorry for my poor English, but can anyone give me some clues? Thanks.
From Admin console check your log.
Do not check for errors only, rather check all types of messages inside the log.
Look for the requests made by robots/web crawlers. In most cases, you can detect such "users" by words "robot" or "bot" (well, if they are honest...).
The first thing you can do is to edit your "robot" file. For more detail read How to identify web-crawler? . Also, GAE has help for use of "robot" file.
If that fails, try to detect IP address used by bot/bots. Using GAE Admin console put such addresses in blacklist and check your quota consumption again.
I developed an application for client that uses Play framework 1.x and runs on GAE. The app works great, but sometimes is crazy slow. It takes around 30 seconds to load simple page but sometimes it runs faster - no code change whatsoever.
Are there any way to identify why it's running slow? I tried to contact support but I couldnt find any telephone number or email. Also there is no response on official google group.
How would you approach this problem? Currently my customer is very angry because of slow loading time, but switching to other provider is last option at the moment.
Use GAE Appstats to profile your remote procedure calls. All of the RPCs are slow (Google Cloud Storage, Google Cloud SQL, ...), so if you can reduce the amount of RPCs or can use some caching datastructures, use them -> your application will be much faster. But you can see with appstats which parts are slow and if they need attention :) .
For example, I've created a Google Cloud Storage cache for my application and decreased execution time from 2 minutes to under 30 seconds. The RPCs are a bottleneck in the GAE.
Google does not usually provide a contact support for a lot of services. The issue described about google app engine slowness is probably caused by a cold start. Google app engine front-end instances sleep after about 15 minutes. You could write a cron job to ping instances every 14 minutes to keep the nodes up.
Combining some answers and adding a few things to check:
Debug using app stats. Look for "staircase" situations and RPC calls. Maybe something in your app is triggering RPC calls at certain points that don't happen in your logic all the time.
Tweak your instance settings. Add some permanent/resident instances and see if that makes a difference. If you are spinning up new instances, things will be slow, for probably around the time frame (30 seconds or more) you describe. It will seem random. It's not just how many instances, but what combinations of the sliders you are using (you can actually hurt yourself with too little/many).
Look at your app itself. Are you doing lots of memory allocations in the JVM? Allocating/freeing memory is inherently a slow operation and can cause freezes. Are you sure your freezing is not a JVM issue? Try replicating the problem locally and tweak the JVM xmx and xms settings and see if you find similar behavior. Also profile your application locally for memory/performance issues. You can cut down on allocations using pooling, DI containers, etc.
Are you running any sort of cron jobs/processing on your front-end servers? Try to move as much as you can to background tasks such as sending emails. The intervals may seem random, but it can be a result of things happening depending on your job settings. 9 am every day may not mean what you think depending on the cron/task options. A corollary - move things to back-end servers and pull queues.
It's tough to give you a good answer without more information. The best someone here can do is give you a starting point, which pretty much every answer here already has.
By making at least one instance permanent, you get a great improvement in the first use. It takes about 15 sec. to load the application in the instance, which is why you experience long request times, when nobody has been using the application for a while
We know from the documentation there is a theoretical limit of 1 message per user per second, but we aren't coming anywhere close to that while running email migrations on a high-end server. What should we do? Should we increase the amount of threads per user to more than one (even though the documentation suggests only 1 thread per user)? I've used their GAMME tool and it blows the email migration api away in terms of speed, even on lower end servers.
Does anyone have any suggestions? It's not super-slow, but it's slow enough to be a pain.
The GAMME tool itself utilizes the Email Migration API, it's not doing anything special so there are likely other factors slowing your migration. Are you actually hitting the migration API from AppEngine? If so, you should be able to utilize appstats to profile your application and see if there are other bottlenecks. Where are you pulling messages from?
Do not attempt to use more than 1 thread per user migration, it won't work and you'll get performance issues. DO make sure that you are properly implementing exponential backoff. If your app doesn't acknowledge 503 error codes by backing off exponential (1 second the first time, then 2 seconds, 4, 8, etc) then Google will respond by further throttling your API calls.
Is anyone else having this problem? Sometime last night after app engine's server maintenance, i have only successfully been able to geocode a few addresses -- most responses are 620 errors. ive been running the same app with no problems for 3 months, so i think i think its a problem on google's end. one other person on the google groups discussion was able to confirm, but i want to be sure because im very skeptical given that more people arent complaining.
here's the explaination of the 620 status code.
"The given key has gone over the requests limit in the 24 hour period or has submitted too many requests in too short a period of time. If you're sending multiple requests in parallel or in a tight loop, use a timer or pause in your code to make sure you don't send the requests too quickly."
And a post on the subject.
Hope it help!