Будь ласка, виберіть
  • Проєкти 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к запитів на хвилину потрібно використовувати асинхронні потоки та оптимізацію з'єднань, щоб не витрачати ресурси на встановлення нових сесій. Яким чином ви плануєте обробляти відповіді від сервера при такій інтенсивності, чи потрібно їх десь зберігати або аналізувати в режимі реального часу?