Как оптимизировать принятие POST запросов?

Question

[aopil]

Я отправляю 20 запросов к сайту-поставщику, указываю адрес на который он мне пришлет ответ (Call Back) и получается так, что он присылает мне все 20 в течении 2-3 секунд каждый запрос по отдельности. Соответственно получается он делает к моему сайту 20 POST запросов и мой сайт блокирует этот поток, тем самым некоторые ответы пропадают.

Вопрос, можно ли как-то оптимизировать и настроить получение post запросов в количестве 20-30 штук?)
p.s. Пообщался с поддержкой хостинга (Cloud хост) сказали мол если только на VPS перейдете (дорого получается в моем случае) и на VPS говорят можете больше чем 30 даже получать если хотите.
p.s. И даже если мой сайт принимает 5-7 запросов нормально, то при выполнении скрипта (получается, что скрипт запускается для каждого callBackа почти одновременно 7 скриптов и куча запросов к БД в 2-3 секунды этих) в результате при загрузке сайта я получаю Error 500. пока скрипт не выполнит свои действия.

Как с этим Call Back живут в итоге, ведь кто-то пользуется этим...

Comments

[Moses Fender]

складывать в файловый буфер, а потом неспеша разбирать.

[aopil]

Moses Fender, как я могу складывать в файл, если post запросы блокируются после 7-10 запросов и просто не доходят до меня?

[Максим Тимофеев]

а что мешает отправлять запросы с задержкой, по мере получения ответов? Делаем очередь, шлем 1, получаем ответ, шлем второй и т.д.

дорого получается в моем случае

vps-ки сейчас копейки стоят. Не понимаю о какой дороговизне речь.

[Moses Fender]

aopil, мне это не понятно. Почему блокируются?

[aopil]

Максим Тимофеев, 50$ в месяц копейки?

[aopil]

Moses Fender, потому что идет 20 запросов от одного ip в течении 2-3 секунд. хостинг блокирует все запросы из этого ip после 7-10 запросов

[sim3x]

aopil,

$5 https://www.digitalocean.com/pricing/
$2.5 https://www.vultr.com/pricing/

Можно найти еще дешевле
lowendstock.com
$3.5 в год

[aopil]

sim3x, $5 https://www.digitalocean.com/pricing/ - Это за Cloud 5$, а не VPS, или я не понимаю?)

[sim3x]

aopil,

Balanced virtual machines with a healthy amount of memory tuned to host and scale applications like blogs, web apps, testing and staging environments, in-memory caching, and databases.

[Максим Тимофеев]

aopil,

50$ в месяц копейки?

Ну во первых для работы - это копейки. А во вторых, есть варианты дешевле по 150р в месяц, например >>> Этим конкретно я пользуюсь, наверняка и еще дешевле есть.
У Вас шаред намного дешевле 150 рублей?

Answer 1

[Иван Шумов]

Перейдите уже на нормальный хостинг. VPS это норма

Comments

[aopil]

bluehost не нормальный?)

[Иван Шумов]

aopil, Любой шаред это дикость) А так вообще с этим конкретно не работал - у меня в основном AWS, DigitalOcean, OVH

[nrgian]

VPS - это сервер без нежной админовской поддержки.
Все нужно уметь самому.

[nrgian]

Иван Шумов,

Любой шаред это дикость)

Шаред это все тот же VPS с предустановленным стандартным набором ПО (каким это сложилось уже в индустрии).
И с администрированием этого стандартного набора.

[aopil]

Иван Шумов, DigitalOcean предлагает VPS? https://www.digitalocean.com/pricing/ от 5$?? Почему тогда мой основной 50$ берет?)

[Иван Шумов]

nrgian, на самом деле нет) это еще и лимиты ресурсов по тому как там гораздо больше соседствующих проектов и не такая хорошая изоляция

[Иван Шумов]

aopil, спросите что полегче. за 50$ я в амазоне шикарнейшую архитектуру разверну)

[Максим Тимофеев]

aopil,

Почему тогда мой основной 50$ берет?)

Это вопрос явно не по адресу. Спросите у своего провайдера.

[Everything_is_not_so_bad]

Иван Шумов, это лишь за проделанную работу ? А сколько в месяц стоить будет?

[Иван Шумов]

Роман Мирр, это в месяц за архитектуру) работа нынче так дешево не стоит)

[nrgian]

Иван Шумов,

на самом деле нет) это еще и лимиты ресурсов по тому как там гораздо больше соседствующих проектов и не такая хорошая изоляция

Просто не пользуйтесь школохостами - и все у вас будет хорошо.

Ну а если вам нужна изоляция - то есть VIP-shared - это та же VPS, но с предустановленным набором общепринятого в shared ПО и с администрированием его же.
https://ruweb.net/hosting/vip

Разница между нормальным shared и VPS - именно что в обслуживании хостером стандартного набора ПО.
И именно потому нормальный shared и дороже VPS.

Однако разница в цене радикально ниже, чем затраты на администрирование собственными силами.

[nrgian]

aopil,

DigitalOcean предлагает VPS? https://www.digitalocean.com/pricing/ от 5$?? Почему тогда мой основной 50$ берет?)

Скорее всего вы сравниваете несравнимые тарифы/разные услуги.
Разница в сравнимых, конечно, может быть и в раза.
Но не такая, не в 10.

[Иван Шумов]

nrgian, ну, про школохоcты вы правы, просто все организовывают это по-равному и в итоге оказывается что для работы шаредов используются не качественные устаревающие железки, порой с дисками под утилизацию .... в общем много нюансов.

Администрирование своими силами/настроенный сервер это tradeoff и надо всегда понимать что шаред это детские игры и вам почти всегда нужно больше. Даже в облаках все понимают что предустановленный сервер это просто способ заманить человека, но никто не отнимает возможности ручных настроек (как пример - AWS Lightsail и AWS Beanstalk)

[nrgian]

Иван Шумов,

шаред это детские игры и вам почти всегда нужно больше

У вас типичное заблуждение.

Как и обычно все топчат аргументацию за VPS такую:
1) гибко и
2) дешево.

1) Но это совсем другая услуга. Shared типовой это именно что типа LAMP (ну или nginx там вместо/вместе с Apache). Прочие shared - большая редкость, и есть сомнения с проработанности управляющего ПО для shared для стека отличного от LAMP (вариации с nginx, PostgreSQL допустимы).
Если вам нужно другое ПО, то действительно VPS имеет смысл глянуть. И PaaS.

Но сравнивать тут с shared - глупо. Ибо банально - другой стек.

2) Типичное заблуждение, что shared детский хостинг и потому должен стоить дешевле.
Shared же по факту сложнее с точки зрения услуг хостера, так как организацию поддержки этого ПО берет на себя хостер.
Чисто по себестоимости VPS и shared на сопоставимых аппаратных ресурсах - shared будет стоить дороже из-за дополнительной работы админов хостинга shared, которой работы нет на хостинге VPS.

Те, кто подвержены этому заблуждению - берут услуги shared дешевле услуг VPS и закономерно получают то, что получают. Потом выражают свое недовольство услугой shared как таковой.

Нормальная услуга shared дороже, а не дешевле VPS.

Тот shared, что дешевле - то да, не то железо, сверхуплотнение сайтов и пр., что снижает качество shared.

Answer 2

[Everything_is_not_so_bad]

Есть простое решение: использовать очереди сообщений. Это позволит откладывать обработку POST запросов и тогда ничем не будет блокироваться.
То есть это

получается, что скрипт запускается для каждого callBackа почти одновременно 7 скриптов и куча запросов к БД в 2-3 секунды этих

будет выполняться в фоне отдельным процессом.
И тогда никакие апгрейды не понадобятся совсем.

Comments

[aopil]

Можно подробнее про очередь сообщений?

[Everything_is_not_so_bad]

aopil, нужно читать статьи и дополнительные материалы для каждого языка они свои.
Очереди сообщений
Message queue < language >, message broker < language >
Обычно не нужны никакие облачные средства очередей сообщений, как могут подсказать многие, включая Ивана. Он заинтересован в продвижении свои услуг.

[Николай Конюхов]

aopil, думаю для вас это такой же недоступный плод, как и VPS

[Артур Мустафин]

можно сделать самому очередь сообщений, rabbitmqm, но для всего веселья все равно нужен VPS, как ни крути

[Everything_is_not_so_bad]

Артур Мустафин, а на общем хостинге нельзя иметь дополнительные процессы?

Answer 3

[Артур Мустафин]

В общем, подними столько бесптатных сервсисов, сколько сможешь, потом на одном из бесплтаных серверов реализуй неконфигурируемый балансировщик нагрузки на бесплатном VPS, пропиши туда +100500 серверов и вуаля.

Если вы в Python сайт написали, то asyncio поможет, и логика работы в БД переезжает задачи в chrontab. Как жто делается. Выполнять запросы в обработчике POST в контроллерах не надо (любой ЯП), регстрируете запрос, регистрируете данные, и досвидос. Прокладкой между рулем и сиденьем может служить dynamodb, благо он есть и в докере и на локалхосте, куда обращаться будут два сервиса - первый ваг веб сервис, второй - daemon для работы с базой данных, который при поступлении нового запроса, тупо фигачит в БД с таймаутами задержки 24 часа и лимитами на подключение в 2 Gb, вашему же вебсерверу остается только функция посыльного, прямая ассциация с ресепшн отеля, получили конвертик, положили в ячейку комнаты, запрос пришел от владельца ячейки, содержимое ячейки отдали, если есть если нет, не отдали, все просто.
Если вы в ASP.NET, то то же самое, принимаете запрос, говорите, спасибо, вот возьми с полки пирожок, отправляете уникальный ID запроса, и с богом, а задачу по выгрузке всего барахла опять же в EF Core, и в crontab

Answer 4

[Александр]

Во-первых, можете настроить многопоточность. Это есть на практически всех back языках (хоть иногда и на костылях). Во-вторых, можете попросить их слать callback с таймаутом. Если у вашего хостинга стоит ограничение на количество принимаемых запросов, это никак не оптимизировать. Так же, можно отправлять в одном post несколько или распределить нагрузку на несколько серверов.

Comments

[aopil]

Это все здорово и красиво! но вы думаете проект, который работает успешно и я хочу заказывать их услуги будет колупаться и настраивать их систему под меня?)

[Johny Smith]

aopil,

я хочу заказывать их услуги будет колупаться и настраивать их систему под меня?)

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

[Johny Smith]

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

[Александр]

aopil, а почему бы не попробовать?

Answer 5

[Евгений Педя]

Не понятно как проверялось не прохождение запросов. Изучался лог сервера?
Если хостер не адекватный и дропает запросы через проксирование, то лучше его сменить.
Если речь о приёме вебхуков по POST ничего не возвращающих кроме статуса 200, то лучше принятые данные сохранить и передать id или имя файла скрипту запускающемуся в фоне.
Если речь об запросах к REST API на PHP, то узкое место при множественных одновременных запросах от одного клиента это сессии в PHP. Сессии при REST API как правило не нужны, а потому максимально быстро переключаем их в режим только чтения.