The post has been translated automatically. Original language: Russian
The request frequency limit usually appears in a hurry, after the first time when one customer posted the service. They take a round threshold, apply it to everyone, and after a week they deal with the complaints of those who are not to blame for anything.
Where they make mistakes when setting up
- The threshold is selected without data. No one has looked at the actual distribution of requests, so the limit either fails or cuts off normal work.
- The restriction applies to the address, not the client. One corporate client behind a shared address blocks the rest of the employees.
- One limit for all methods. Cheap reading and a heavy report cost differently, but they have the same quota.
- There is no useful information in the response. The client gets rejected and does not know how long to wait, so repeats immediately.
- Internal calls fall under the same limit. Own services are falling off, not external clients.
What to do
- Count the threshold from the actual load. Take a high percentile of regular traffic and leave a margin.
- Limit by client ID or access key. The address is the last option when there is nothing else.
- Divide the limits by the cost of operations. Heavy requests have a separate and smaller quota.
- In the rejection response, specify the time until the next attempt. This reduces the number of pointless repetitions more than any persuasion.
- First, turn on the monitoring mode. Count the exceedances without blocking and see who would have gone under the knife.
- Allow short bursts. A minute limit with a one-second burst tolerance cuts off the attack, but does not interfere with normal operation.
Result
Limiting the frequency of requests protects not only the service, but also the clients from each other. It works when the threshold is justified by the data, linked to the client and explains to him what to do next. Otherwise, it's just a way to turn an overload into a flood of support calls.
Do you roll out new limits in the monitoring mode or turn on the lock immediately?
Почти в каждой команде есть работа, которую делают руками каждую неделю. Собрать выгрузку, свести две таблицы, разослать отчёт, перенести данные из одного файла в другой. Каждый раз это занимает немного времени, поэтому кажется, что автоматизировать не стоит.
Посчитать выгоду проще, чем кажется. Возьмите задачу и умножьте время на количество повторений за год. Сорок минут раз в неделю это больше тридцати часов за год. Такую задачу уже имеет смысл описать и передать программе.
Начинать лучше не с самой сложной задачи, а с самой частой. Частая задача хорошо изучена, шаги в ней понятны, и результат легко сравнить с прежним. Сложная задача обычно требует решений, о которых команда ещё не договорилась, и работа останавливается на обсуждении.
Первый шаг простой: запишите задачу словами. Откуда берутся данные, что с ними происходит, куда уходит результат, кто им пользуется. Часто на этом этапе становится видно, что половина шагов существует по привычке, и задача сокращается сама.
Второй шаг тоже без кода. Уберите лишние шаги и приведите вход к одному виду. Если сегодня файл приходит в трёх разных форматах, никакая программа не сделает этот процесс спокойным. Сначала договорённость о формате, потом автоматизация.
Дальше делайте самое маленькое решение, которое работает. Один скрипт, который выполняет один шаг и сохраняет результат. Его можно проверить за день и сразу увидеть пользу. Большое решение проверить сложнее, и оно чаще остаётся незаконченным.
Полезно с самого начала оставлять след. Пусть программа записывает, когда она запускалась и что получилось. Тогда через месяц любой человек в команде сможет посмотреть результат и не спрашивать автора.
И последнее. Автоматизация имеет смысл только для того процесса, который останется таким же и через полгода. Если правила меняются каждую неделю, сначала стоит договориться о правилах, а уже потом писать программу.
А в вашей команде есть задача, которую делают руками каждую неделю?
Share
