cURL постоянное соединение
Всех приветствую!
Сомневаюсь, что вопрос относится непосредственно к modx, однако будет полезно посоветоваться со знающими.
1. Дан сниппет, который по запросу пользователя отправляет ему личное сообщение на чужой форум от меня. В запросе указываются мои данные для авторизации на форуме. Прописывается 'keep-alive'.
2. В процессе, столкнулся с медленным выполнением запроса: до 5-10 секунд. Поэтому набрел на статью: Http запросы — мы все это делаем неправильно Суть в том, что не обязательно создавать соединение на каждый запрос, это сильно тормозит его выполнение.
Вопросы:
4. Первое что пришло на ум — убрать curl_close и сделать curl_init($ch) с данными авторизации глобально, чтобы единожды открылось соединение, и поддерживалось по мере разрывов. В какую сторону гуглить «как это сделать в modx», и стоит ли? $modx — ведь глобальна.
5. Из-за большого времени выполнения, встает вопрос. Допустим, 100 пользователей одновременно запустят данный сниппет. Думаю либо повесится сервер, не давая выполнять основные функции сайта, либо будут проблемы с форумом. Нужно ли организовывать очередь выполнения данных запросов?
Но т.к. я в этом полнейший 0, хотелось бы посоветоваться, прежде чем городить велосипеды из костылей.
Сомневаюсь, что вопрос относится непосредственно к modx, однако будет полезно посоветоваться со знающими.
1. Дан сниппет, который по запросу пользователя отправляет ему личное сообщение на чужой форум от меня. В запросе указываются мои данные для авторизации на форуме. Прописывается 'keep-alive'.
2. В процессе, столкнулся с медленным выполнением запроса: до 5-10 секунд. Поэтому набрел на статью: Http запросы — мы все это делаем неправильно Суть в том, что не обязательно создавать соединение на каждый запрос, это сильно тормозит его выполнение.
Вопросы:
4. Первое что пришло на ум — убрать curl_close и сделать curl_init($ch) с данными авторизации глобально, чтобы единожды открылось соединение, и поддерживалось по мере разрывов. В какую сторону гуглить «как это сделать в modx», и стоит ли? $modx — ведь глобальна.
5. Из-за большого времени выполнения, встает вопрос. Допустим, 100 пользователей одновременно запустят данный сниппет. Думаю либо повесится сервер, не давая выполнять основные функции сайта, либо будут проблемы с форумом. Нужно ли организовывать очередь выполнения данных запросов?
Но т.к. я в этом полнейший 0, хотелось бы посоветоваться, прежде чем городить велосипеды из костылей.
12 июня 2015, 15:15
Комментарии: 11
Конечно, искаропки.
Вообще, для вашей задачи все эти танцы с keep-alive'ом для curl'а из php не имеют абсолютно никакого смысла, если для одного клиента вам не нужно делать больше одного запроса к стороннему сайту.
У вас же как — пользователь открывает вашу страницу (или отправляет post-запрос, неважно), сниппет через curl делает один запрос к стороннему сайту, получает и отдаёт данные клиенту и всё — php-процесс умирает. Как говорится — «php живёт, чтобы умереть». Для другого пользователя создатся свой отдельный php-процесс, который ничего про предыдущий curl-запрос предыдущего клиента знать не знает и знать не должен. Соответственно, пляски с keep-alive'ом бессмысленны.
Но вот если бы вам для одного пользователя нужно было бы слать несколько запросов на один и тот же домен (скажем, сперва авторизовать, потом отправить какие-то данные, потом получить данные с какой-то другой страницы от имени этого авторизованного юзера) и всё это в рамках одного php-процесса и подряд — то да, в keep-alive был бы смысл. Ибо на все эти три запроса не было бы повторных соединений, потому что curl держал бы лишь одно.
Нода работает по другому. Я сейчас не буду рассказывать про event-loop'ы, process.nextTick'и, таймеры и как оно вообще работает. Но общий смысл такой.
Когда поднимается веб-сервер на ноде, то создаётся один процесс, который висит, не умирает и ждёт запросов. Этот процесс и обрабатывает все запросы от всех клиентов, и вся работа происходит асинхронно. Именно этот нюанс не понимают php-разработчики при переходе на ноду и работают с ней не правильно (так, по-крайней мере, говорят. У меня проблем не возникло. Но коллбеки в коллбеках до сих пор вгоняют меня в уныние, да).
Вот здесь Илья Кантор (создатель javascript.ru) отлично раскрывает тему. Вообще, советую посмотреть весь скринкаст, если интересна нода, ибо он раскрывает многие (но не все) нюансы.
Так вот. Чтобы воспользоваться keep-alive'ом, я вижу только один вариант.
Поднимается веб-сервер на ноде, который слушает localhost на, к примеру, 3000м порту.
Этот веб-сервер на каждый запрос принимает ваши данные, которые нужно отослать на сторонний сайт, делает этот самый запрос на сторонний сайт и отдаёт ответ. А ваш сниппет, через curl, шлёт запросы на этот самый localhost:3000, который примет нода, и от неё же получает ответ.
Т.е. в вашем примере цепочка такая:
1. клиент шлёт данные;
2. сниппет их получает;
3. сниппет что-то отправляет через curl на сторонний сайт;
4. curl получает ответ от стороннего сайта;
5. отдаёт данные клиенту;
6. php умирает.
В примере с нодой будет вот так:
1. клиент шлёт данные;
2. сниппет их получает;
3. шлёт что-то в ноду через curl на localhost:3000 (и здесь, напомню, нода не будет тратить время на запуск и инициализацию, ибо она уже запущена и проинициализированна. т.е. всё происходит максимально быстро);
4. нода принимает данные и отправляет их на сторонний сайт;
5. нода принимает данные от стороннего сайта и отдаёт их;
6. curl этот результат принимает;
7. отдаёт данные клиенту;
8. php умирает, а нода продолжает жить.
Так и вот, собссна, вопрос — а где же здесь выигрыш? И это самый правильный вопрос!
На чём теряем:
— на отправку запроса в ноду;
— на получение ответа из ноды;
— проверку из php — запущен ли процесс ноды и, если нет, то запустить (либо fallback на текущий вариант — прямого запроса на сторонний сайт через curl, чтобы не тратить времени на запуск ноды).
На чём выигрываем:
— нода будет использовать keep-alive при получении запросов от curl (об этом есть в видео выше);
— нода будет использовать keep-alive при запросах к стороннему сайту (и то не факт — надо исходники копать).
И вот будут ли затраты покрывать выигрыш от keep-alive'а — это большооой вопрос.
В этом есть смысл только при наличии большого количества одновременных соединений. В вашем случае — количества пользователей, которые будут одновременно слать запросы через ваш сервис.
А по факту — если на вашем сервисе пользователи делают запросы реже, чем раз в 30 секунд, то всё это шаманство не имеет смысла вообще. Почему? Попробуйте догадаться сами :-)
А если чаще, чем раз в 30 секунд, то нужно тестировать. А чтобы протестировать — нужно написать готовый код, чего, сами понимаете, делать сейчас особо не хочется)
И вот если/когда код напишется и будет протестирован, то вполне может оказаться, что на этот комментарий я потратил гораздо больше, чем сэкономится процессорного времени за всё время существования вашего сервиса :)
А поскольку вы уверены в немощности вашего vps, значит (скорей всего) нет у вас на сайте такого количества одновременных пользователей и последний вариант — самый вероятный :)
Такие вот дела.
Вообще, для вашей задачи все эти танцы с keep-alive'ом для curl'а из php не имеют абсолютно никакого смысла, если для одного клиента вам не нужно делать больше одного запроса к стороннему сайту.
У вас же как — пользователь открывает вашу страницу (или отправляет post-запрос, неважно), сниппет через curl делает один запрос к стороннему сайту, получает и отдаёт данные клиенту и всё — php-процесс умирает. Как говорится — «php живёт, чтобы умереть». Для другого пользователя создатся свой отдельный php-процесс, который ничего про предыдущий curl-запрос предыдущего клиента знать не знает и знать не должен. Соответственно, пляски с keep-alive'ом бессмысленны.
Но вот если бы вам для одного пользователя нужно было бы слать несколько запросов на один и тот же домен (скажем, сперва авторизовать, потом отправить какие-то данные, потом получить данные с какой-то другой страницы от имени этого авторизованного юзера) и всё это в рамках одного php-процесса и подряд — то да, в keep-alive был бы смысл. Ибо на все эти три запроса не было бы повторных соединений, потому что curl держал бы лишь одно.
Нода работает по другому. Я сейчас не буду рассказывать про event-loop'ы, process.nextTick'и, таймеры и как оно вообще работает. Но общий смысл такой.
Когда поднимается веб-сервер на ноде, то создаётся один процесс, который висит, не умирает и ждёт запросов. Этот процесс и обрабатывает все запросы от всех клиентов, и вся работа происходит асинхронно. Именно этот нюанс не понимают php-разработчики при переходе на ноду и работают с ней не правильно (так, по-крайней мере, говорят. У меня проблем не возникло. Но коллбеки в коллбеках до сих пор вгоняют меня в уныние, да).
Вот здесь Илья Кантор (создатель javascript.ru) отлично раскрывает тему. Вообще, советую посмотреть весь скринкаст, если интересна нода, ибо он раскрывает многие (но не все) нюансы.
Так вот. Чтобы воспользоваться keep-alive'ом, я вижу только один вариант.
Поднимается веб-сервер на ноде, который слушает localhost на, к примеру, 3000м порту.
Этот веб-сервер на каждый запрос принимает ваши данные, которые нужно отослать на сторонний сайт, делает этот самый запрос на сторонний сайт и отдаёт ответ. А ваш сниппет, через curl, шлёт запросы на этот самый localhost:3000, который примет нода, и от неё же получает ответ.
Т.е. в вашем примере цепочка такая:
1. клиент шлёт данные;
2. сниппет их получает;
3. сниппет что-то отправляет через curl на сторонний сайт;
4. curl получает ответ от стороннего сайта;
5. отдаёт данные клиенту;
6. php умирает.
В примере с нодой будет вот так:
1. клиент шлёт данные;
2. сниппет их получает;
3. шлёт что-то в ноду через curl на localhost:3000 (и здесь, напомню, нода не будет тратить время на запуск и инициализацию, ибо она уже запущена и проинициализированна. т.е. всё происходит максимально быстро);
4. нода принимает данные и отправляет их на сторонний сайт;
5. нода принимает данные от стороннего сайта и отдаёт их;
6. curl этот результат принимает;
7. отдаёт данные клиенту;
8. php умирает, а нода продолжает жить.
Так и вот, собссна, вопрос — а где же здесь выигрыш? И это самый правильный вопрос!
На чём теряем:
— на отправку запроса в ноду;
— на получение ответа из ноды;
— проверку из php — запущен ли процесс ноды и, если нет, то запустить (либо fallback на текущий вариант — прямого запроса на сторонний сайт через curl, чтобы не тратить времени на запуск ноды).
На чём выигрываем:
— нода будет использовать keep-alive при получении запросов от curl (об этом есть в видео выше);
— нода будет использовать keep-alive при запросах к стороннему сайту (и то не факт — надо исходники копать).
И вот будут ли затраты покрывать выигрыш от keep-alive'а — это большооой вопрос.
В этом есть смысл только при наличии большого количества одновременных соединений. В вашем случае — количества пользователей, которые будут одновременно слать запросы через ваш сервис.
А по факту — если на вашем сервисе пользователи делают запросы реже, чем раз в 30 секунд, то всё это шаманство не имеет смысла вообще. Почему? Попробуйте догадаться сами :-)
А если чаще, чем раз в 30 секунд, то нужно тестировать. А чтобы протестировать — нужно написать готовый код, чего, сами понимаете, делать сейчас особо не хочется)
И вот если/когда код напишется и будет протестирован, то вполне может оказаться, что на этот комментарий я потратил гораздо больше, чем сэкономится процессорного времени за всё время существования вашего сервиса :)
А поскольку вы уверены в немощности вашего vps, значит (скорей всего) нет у вас на сайте такого количества одновременных пользователей и последний вариант — самый вероятный :)
Такие вот дела.
Но вот если бы вам для одного пользователя нужно было бы слать несколько запросов на один и тот же домен (скажем, сперва авторизовать, потом отправить какие-то данные, потом получить данные с какой-то другой страницы от имени этого авторизованного юзера) и всё это в рамках одного php-процесса и подряд — то да, в keep-alive был бы смысл. Ибо на все эти три запроса не было бы повторных соединений, потому что curl держал бы лишь одно.По сути так и есть, я логинюсь по 1 ссылке, парсю страницу по 2, и отправляю сообщение по 3.
А поскольку вы уверены в немощности вашего vps, значит (скорей всего) нет у вас на сайте такого количества одновременных пользователей и последний вариант — самый вероятный :)Простите, перепутал с Shared. У меня почему-то ассоциация V — virtual — и значит слабый.
Именно с Шаред переходил на ВПС, с ростом аудитории.
Текущий проект лежит на шаред, на этапе разработки намного выгоднее держать именно Шаред (на своем компе не держу по некоторым причинам). И присутствует мандраж, что на этапе раскрутки, начнутся тормоза на Шареде.
Впрочем, оставил все как есть, судя по всему не так сильно и грузит, как ни странно уходит около 3 секунд на запрос, что практически не заметно, глядя на ajaxloader.
Планирую переходить на более мощное железо, однако, в то же время не хочу торопиться.
Просто не имею понятия какое железо нужно под определенные цели.
Таймер чего?
Опять же нужно как-то фиксировать — а дожидаются ли вообще ваши клиенты ответа от сторонненого форума. Т.е. ваш-то сервер одновременно 50 человек выдерживает (а выдерживает ли? может в момент пиковой нагрузки и ваш сервер не справляется?), но выдерживает ли такую нагрузку сторонний форум?
Здесь догадки, как вы понимаете, не уместны — всё нужно отслеживать, чтобы делать какие-то выводы.
И думается мнеОпять же — надо чётко понимать, а не додумывать) Ведите какой-нибудь лог, чтобы понимать — как часто делаются запросы. Хоть тупо в файл записывайте — не важно.
По сути так и есть, я логинюсь по 1 ссылке, парсю страницу по 2, и отправляю сообщение по 3Тогда делайте как описано в той статье с хабра — открываете curl_init, делаете запросы к форуму сколько нужно, и только после всех запросов закрываете соединение curl_close (не забыв включить verbose-опцию в curl).
Опять же нужно как-то фиксировать — а дожидаются ли вообще ваши клиенты ответа от сторонненого форума. Т.е. ваш-то сервер одновременно 50 человек выдерживает (а выдерживает ли? может в момент пиковой нагрузки и ваш сервер не справляется?), но выдерживает ли такую нагрузку сторонний форум?
Здесь догадки, как вы понимаете, не уместны — всё нужно отслеживать, чтобы делать какие-то выводы.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Вчера в 15:26
Очень рад, что тебе нравится!
05 мая 2024, 17:14
Сразу же вводит в заблуждение выбор курьером/в пункт как в форме минишопа, так и на карте параллельно.
так не юзерфрендли ни разу
05 мая 2024, 14:11
Установил, наконец-то)) Все работает спасибо.
05 мая 2024, 09:18
Примерно тоже самое, только при помощи mmxDatabase:
$id = $modx->getOption('id', $scriptProperties);
$category = $modx->getOption('category'...
05 мая 2024, 08:48
Собственно пока писал пост, пришла идея костыльного решения, отдельным выводом записать в плейсхолдер id отобранных товаров и их передать в фильтр и т...
