Пожалуйста выберите
  • Проекты 5
  • Оценка 4.9
  • Рейтинг 756

Бюджет: 700 UAH Срок: 7 дней

Здравствуйте, я недавно делал похожий высоконагруженный отправитель запросов: пул соединений, асинхронные работники, батчинг и контроль rate limit под 100-200к запросов в минуту. Ретраи с бэкофом и очередь на неудачные запросы были частью того же решения.

Если запросы идут на внешний API с лимитами, стоит сразу заложить очередь и адаптивный throttle, это спасает от банов и потери данных под пиковым нагрузкой.

Куда именно шлет запросы - на свой сервер или внешний API, и есть ли у него лимит на количество в минуту? И где это должно крутиться - разовый запуск или постоянный сервис?

Предлагаю связаться, сейчас же накидаю схему решения с очередью и работниками под ваши 200к в минуту.

  • Проекты 11
  • Оценка 5.0
  • Рейтинг 914

Бюджет: 2500 UAH Срок: 2 дня

Здравствуйте! Могу сделать срочно

Уточните, пожалуйста, на какой URL нужно отправлять GET-запросы, нужны ли уникальные параметры или просто одинаковые запросы, с какого сервера будет запуск и требуется ли 100–200 тыс запросов в минуту с одного сервера или допускается распределённая отправка

  • Проекты 6
  • Оценка 3.9
  • Рейтинг 776

Бюджет: 700 UAH Срок: 2 дня

Антон, задача заключается в обеспечении высокой пропускной способности для GET-запросов, где главной проблемой становится не сам код запроса, а эффективная работа с сетевым стеком и избегание блокировок на стороне сервера при такой нагрузке. Для стабильной работы 200к запросов в минуту нужно использовать асинхронные потоки и оптимизацию соединений, чтобы не тратить ресурсы на установление новых сессий. Каким образом вы планируете обрабатывать ответы от сервера при такой интенсивности, нужно ли их где-то хранить или анализировать в реальном времени?