How should I go about controlling the rate of my Google Cloud Platform code calling
an third party API?
Specifically, I need to send out SMS text messages over many different phone numbers
via Twilio. And Twilio requires us to send a) no more than 3 messages/second per phone numbers, b) no more than 25 messages/second across all numbers.
I explored several approaches for my code, but they all come down to one point: how do I reliably control the number of parallel executions of those code on the platform.
Thanks!
Combining number of messages/second per phone and number of message/second globally is not possible.
Else, you can use Cloud Task. Queue all your messages on Cloud Task, and set a rate limit to call a Cloud Functions that call Twilio API. You can put that limit to 25 per second for the global value
For the error that you will get with the same phone number, you can configure retry policies.
Related
I, like everyone else I imagine, have a courtesy limit of 1000 Mirror API calls per day.
I see there's a batching facility that looks promising, but it appears to be able to batch only requests for a single credential. So even one customer, pushing to the API every 60 seconds will be 1440 requests/day. Ideally, 30 seconds is where I'd like to be. 2880 requests/day would be multiplied by the number of customers. It will get really big really fast.
I might be missing something, but I don't see a way around that.
If it were available I could glom all updates across all clients in the 30 second period into one giant message...
Is there a better design pattern to keep cards up-to-date with telemetry that's changing in real-time?
You can send requests to multiple users with a single batch request: instead of setting the Authorization header in the batch request, simply set the Authorization header in each sub-request.
Our Python and Java Quick Start projects have an example of using batch request to send an update to up to 10 users. This is also mentioned in the Building Glass Services with the Google Mirror API I/O session.
Otherwise, you can check the protocol documentation in our reference guide.
As Scarygami mentioned, each sub-request will consume quota so the only optimization is to save on bandwidth and HTTP requests, especially if using gzip encoding.
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.
Many banks, airlines, etc. offer the possibility to receive text message notifications by entering your mobile number. Some other sites have you enter your mobile number and wireless carrier and send messages to your free per-provider email-to-mobile number. But some people definitely do it without asking for the provider. How is this accomplished? Are there commercial services that provide this functionality?
(if this doesn't belong on SO, feel free to migrate to another SE site)
Edit: I'm primarily concerned with mobile numbers in the US, but interested in answers for other countries as well.
Yep, providers of this service are called SMS gateways, good ones should be able to set you up with an API for bi-directional use
There are a few different ways this can happen. If you have access to cellular hardware, like Multitech's MTC-H5 cellular modem or their rCell 100 cellular gateway, you're sending SMS just like a cell phone does, so this bypasses the need to know the carrier of the phone number. If the program you're using can't directly access the hardware, you could try to use a program like ours, PageGate, to receiving alerting notifications from that program to interface with the hardware to deliver the SMS.
There are also message aggregators, companies who provide a web API that allows you to send SMS. You submit the phone number with message to their API, they handle the delivery. Examples of these companies would be Infobip and Clickatell or if you're looking for something for medical markets, you could try TigerText, or for emergency management, you could try Active911 or I Am Responding.
I've got an application that sits behind a US based SMS Short Code. I can test my application from the point of ingress into our systems to the point of egress and am confident about the functionality within those boundaries.
What I want to be able to do is extend the test to include the SMS Aggregator that is handling our short code. I want a service provider that will allow me to send and SMS via an API to a short code. We're working with 2 different SMS aggregators (a Tier1 and a Tier3) and both api's only allow SMS messages to be sent to long codes (10 digit numbers). I've also tried Tiwlio's SMS API, but they also do not allow SMS messages to be sent to a short code.
Can anyone recommend a service, hardware device, or other solution that would allow us to message a short code so that we can automate testing and monitoring of our short code based applications?
Thanks,
Kyle
This is probably disallowed by the aggregators due to difficulty in determining what short codes incur premium charges for MT messages.
Given that you can send to a shortcode from any GSM modem/handset with a valid SIM, why not interface with one of those and use the AT command set to send your test messages?
Could somebody give a good explanation for newbie, what does following phrase means:
1) workload throttling within a single cluster and 2) workload
balance across multiple clusters.
This is from overview of advantages of one ETL-jobs tool, that helps perform ETL (Extract, Transform, Load) jobs on Redshift database.
Many web services allocate a maximum amount of "interaction" that you can have with a service. Once your exceed that amount, the service will shift in how it completes its interactions.
Amazon imposes limitations on how much compute power you can consume within your nodes. The phrase "workload throttling" means that if you exceed the limits detailed in Amazon's documentation Amazon Redshift Limts, your queries, jobs, tasks, or work items will be given lower priority or fail outright.
The idea is that Amazon doesn't want you to consume so much compute power that it prevents others from using the service and, honestly, they don't want you to consume more power than it costs them to provide.
Workload throttling isn't an idea exclusive to this Amazon service, or cloud services in general. The concept can be found in any system that needs to account for receiving more tasks than it can handle. Some systems deal with being overburdened differently.
For example, some systems will defer you to alternate services in the case of a load balancer. 3rd party data APIs will delegate you a maximum amount of data per hour/minute and then either delay the responses you get back, charge you more money, or stop responding altogether.
Another service that you can look at that deals with throttling is the Google Maps Geocoding service. If you look on their documentation, Google Maps Geocoding API Usage Limits, you will see that:
Users of the standard API:
2,500 free requests per day, calculated as the sum of client-side and server-side queries.
50 requests per second, calculated as the sum of client-side and server-side queries.
If you exceed this and have billing enabled, Google will shift to:
$0.50 USD / 1000 additional requests, up to 100,000 daily.
I can't remember what the response looks like after you hit that daily limit, but once you hit it, you basically don't get responses back until the day resets.