Paid API subscription, but Too many requests limitation?

[miherb]

Hi there,

I have considerable translation work to perform for my academic research project for the upcoming month and I was under the impression I could use the paid API provided by Libretranslate and UAV4GEO to get this done effectively. First, it was advertise it can process up to 80 requests per minute. In our tests, we did not get anywhere close to this. Second, there were no mention about a limit. When we were done testing and ready to move to production, we no longer were able to receive any 200 responses from the server (we are only getting 403 and 429 responses at this point). Even when I try to use the browser’s version, I get a “Too many request limits violations”.

Is this a temporary issue with the server or there were limitations paid users should be aware of before subscribing to your services?

Thank you

[pierotofy]

Hi @miherb !

Yes the requests limits with an API key are (should be?) 80 per minute.

I’ll run some tests to see if something is misconfigured on our part

[pierotofy]

One thing to keep in mind, is that you cannot initiate more than 20 concurrent connections to the server from the same IP. Can you provide more details about how you are making connections to the API? I’ve tried to run CURL several times within a minute and the limits seem to work OK (but here I’m using a single connection):

curl -d "q=test&api_key=xxxxx&source=en&target=es" -X POST https://libretranslate.com/translate
{"translatedText":"prueba"}

[miherb]

Thank you for your prompt reply! I understand now the 80 requests per minute is a constraint and not a performance target. Just a heads up, to improve your communication with future clients, I’ve read it as: “our servers can deliver up to 80 requests per minute” not as "you can process maximum 80 requests per minute. Anyway our number of requests per minutes even with parallelization set up on my machine, we were nowhere near the 80 requests maximum. We were around 30.

Keep me posted!

[pierotofy]

I will update the wording

[miherb]

All the requests are coming from my computer. I don’t use any proxies, and I have 7 parallel process. I do use a VPN and I might have changed my address IP while querying the server. Might that be the issue?

[pierotofy]

I also realize that perhaps 20 is too conservative for a number of parallel connections; we’ve set that limit recently because a few users were making thousands of parallel connections. I’d be happy to increment that if it helps get your application working.

Edit: I just bumped it to 80. Let me know if it works better now?

Using VPN should not affect the request limits.

[miherb]

It seems to work now! Thanks! I did not change anything on my side. Did you do something to green flag my API key?

[pierotofy]

I’ve bumped the number of allowed parallel connections to our webserver from 20 to 80 (for all users). That was probably the issue. Sorry for the trouble this might have caused and thanks for reporting it!

[miherb]

Ok so we have done further tests with translation of titles and it was very quick. We did pass the threshold of 80. The server starts to return 429 responses. I wanted to test further to get closer the 80 requests limit, but now I receive only 403 responses. What is the penality every time we don’t respect the threshold?

[pierotofy]

Continuously hitting the request limits will get the API key temporarily banned for a period of time (30 minutes). I recommend putting a sleep if you get a 429 to make sure this doesn’t happen.

[dingedi]

I had this problem because in the event of a parallel request, if a request fails with a 429 the others have already left and therefore have the IP banned.
It may be necessary to review this system, it is interesting for libretranslate.com but may not be for paid API keys, or increase it for paid API keys. i think

[miherb]

Makes sense. Thanks @pierotofy

[miherb]

Hi @pierotofy, is it possible we get 520 responses after a timeout of roughly 50sec on the server?

Also, was there any maintenance yesterday? There was a solid 3 hours we only got 520. We got also a considerable amount of 502.

Are these server responses random or is there anything we can do on our side to optimize for 200 responses?

[pierotofy]

We did 1-2 restarts to update the software, but shouldn’t have lasted 3 hours. Mm

Unless there was a network issue at the VM level.

So long as you don’t flood the server with requests and exceed the key limits I think you should be fine.

Perhaps if you can provide more details about how you are querying the API I can offer additional possible insights?

[miherb]

Hi @pierotofy,

Do you have an issue with the service today? Today we have 502 responses after roughly 30 sec (while we had 520 after roughly 50 sec yesterday). This means the server doesn’t have time to perform the queries on our longest content to translate, which doesn’t contain more than 3000 characters before the encoding made by httr::build_url() in R. We did 3000 characters chunks as a way to get close the 5000 limitation, while minimizing the chance of busting it.

In the screen shot below, you can see the timestamp of the log, what is important to notice is the status code and the Time elapsed.

Another issue here, we have a 502 with a content of 570 char to translate.
[ 2022-07-21 11:36:15 ] : Result request row name 391 with nchar = 570 is : Status_code: 502 Time elepased : 30.4199368953705

This is very concerning as I expect to use this service that I have paid for much more than I currently have in the next weeks.

Thanks for addressing this.

[miherb]

@pierotofy This is how we built our server request with R and the package httr.

Here is an example of request that we send to your server with POST method:

https://libretranslate.com/translate?q= %20Auf%20Karten%20basierte%20Befragungen%20veranschaulichen%20die%20Ansichten%20von%20%20Bürgern%20und%20Fachleuten.%20Das%20vereinfachte%20Einblenden%20von%20Analysen%20verschiedener%20Ansichten%20und%20Erwartungen%20an%20räumliche%20Gestaltungen%20unterstützt%20den%20Entscheidungsfindungsprozess. %20Jetzt%20als%20Testnutzer%20gratis%20registrieren%20und%20eine%20Befragung%20von%20bis%20zu%2040%20Personen%20durchführen! %20Für%20die%20uneingeschränkte%20Nutzung%20von%20Mapita%2C%20inklusive%20unserem%20kundenorientierten%20Service%2C%20kontaktieren%20Sie%20bitte%3A%20sales%40mapita.fi&source=de&target=en&api_key=API_NUMBER

Let me know if there is something that should be done differently to optimize our 200 responses.

Thanks.

[pierotofy]

You should try to pass the api_key, q, source and target parameters in the POST request body, not in the URL. URLs typically have a maximum length of 2048. I’m guessing that’s the key issue here.

[miherb]

Ok we’ll try it. But we dont seem to have this issue before and we just tried a URL with 2500, and it was successful.

[miherb]

Hi @pierotofy, even with the POST request body method you suggested, we still receive 502 responses systematically when we hit the 30 second mark. It’s like there is some form of a timeout on the server side. Can you verify please? Thanks.