I am implementing a REST API which requires throttling. I know that, ideally, you would place this logic in nginx. However, I have some unique constraints.
Namely, I have one class of users who should NOT be rate limited. It would not be useful to implement a rate limit on a per IP basis (the nginx way).
Users of the API are differentiated on a APIKey basis. Using a caching system, I could count requests per APIKEY and handle rate limiting accordingly. That involves more setup and is not as scalable, I would imagine.
Any suggestions?
You could setup multiple virtual hosts that are individually throttled at different limits. You could do your count and then redirect selected users to these virtual hosts to be throttled.
Related
I'm reading about different strategies for load balancers and one of them is hashing by the source IP (or the session ID). As far as I understand the idea behind that is to connect every user with a specific server, which can allow storing data about a particular user on the matching server. The examples I found are game servers (in case of disconnection user will be connected to the same server) and e-commerce websites (to store items in the cart for not logged-in users).
However, this strategy looks off to me from the availability perspective. What happens if some nodes failover? Will all users from the matching IP addresses won't be able to use the service then?
If not - how the fallback is implemented (maybe you can reference a nice article)?
If yes - in what use cases it is justified to use such a strategy? At the first glance, it doesn't seem to me that using it for game servers and e-commerce is a good idea
I would like to know Here servers automatically reject IPs associated to Tor servers?
Because, I've tried many times to do a request with API (which never answered).
When checking the HERE FAQs it does not say anything about blocking certain IPs, f. ex. from Tor, but it does tell you a bit about limits there adhere to, such as 250,000 Transactions per month.
That's probably a good starting point to check for limits of the HERE API.
I am trying to query public utility data from an API (oasis.caiso.com) with a threaded script in R. Apparently this API will refuse requests from certain IP addresses if too many are made. Therefor I need to run many different API requests in parallel across different IP addresses, and am wondering if a machine with many different CPUs on google cloud platform will allow this?
I was looking at the n1-highcpu-96 option from this page: https://cloud.google.com/compute/docs/machine-types
If this is a poor solution can anyone suggest another distributed computing solution that can scale to allow dozens or even hundreds of API queries simultaneously from different IPs?
If I needed multiple IP to perform "light" API calls I would not scale vertically (with a machine having 96 core). I would create an instance group with 50 or 100 or n Debian micro or small preentible instances with the size depending on the kind of computation you need to perform.
You can set up a startup script loaded in the metadata or in a custom image that connects to the API server do what it has to do and save the result on a bucket and if the instance get a "API refuse" I would simply kill the instance automatically having the instances group creating a new one for me with possibly a new IP.
This I think is a possible easy solution to achieve what you want, but I guess there are multiple solutions.
I am not sure what you are trying to achieve and I think you need to check first that it is legal and if the owner of the API agree.
I know this is a difficult question but here it is, in context:
Our company has a request to build a WordPress website for a certain client. The caveat is that, on one day per year, for a period of about 20 minutes, 5,000 - 10,000 people will attempt to access the home page of this website. Their purpose: Only to acquire an outbound link to another site.
My concern is, no matter what kind of hosting we provide, the server may reject the connections after a certain number of connections are reached.
Any ideas on this?
This does not depend on WordPress. WordPress is basically software to render webpages: it helps you to quickly modify the content content of a page. Other software like for instance Apache accepts connections and redirects the calls to for instance WordPress.
Apache can be configured to accept more connections. I think the default is about 200. If that's bad really depends. If the purpose is only to give another URL, you can say that connections will be terminated fast. So that's not really an issue. If on the other hand you want to generate an entire page using PHP and MySQL it can take some time before a client is satisfied. In that case 200 connections are perhaps not sufficient.
As B-Lat points out. You can use cloud computing platforms like Google App Engine or Microsoft Azure that provide a lot of server power. But only bill their clients on the consumption on these resources. In other words you can accept thousands of connections at once. But you don't need to pay for the other days when clients visit your website less often.
I want to be able to pull how many followers Twitter accounts have in rails. However, I want to do this for many accounts each day 10,000 +. I am only allowed around 150 requests per ip address.
I am a newb to rails, but I have heard of solutions like ip masking, bouncing, and proxy servers to get around this problem.
I have also heard that heroku ip's change all the time for your app, so this may not be a problem.
My main question is...can anyone explain what strategy is possible to make more calls to an api with rate limiting with a rails app on heroku?
Trying to circumvent the restrictions of the API is a very bad idea. You can require users to authorize with Twitter in order to get certain requests to count against their individual API limits instead of yours.
Also, not all calls are rate limited. Some have individual limits, others are limited as part of a group. Look into more creative ways to use the API in ways that reduce the number of requests you need to make.