cURL постійне з'єднання Новий
Всіх вітаю!
Сумніваюся, що питання ставиться безпосередньо до modx, однак буде корисно порадитися із знаючими.
2. В процесі, зіткнувся з повільним виконанням запиту: до 5-10 секунд. Тому набрів на статтю: Http запити - ми все це робимо неправильно Суть в тому, що не обов'язково створювати з'єднання на кожен запит, це сильно гальмує його виконання.
5. Через велику часу виконання, постає питання. Припустимо, 100 користувачів одночасно запустять даний сниппет. Думаю або повіситься сервер, не даючи виконувати основні функції сайту, або будуть проблеми з форумом. Чи потрібно організовувати чергу виконання даних запитів?
Але тому що я в цьому цілковитий 0, хотілося б порадитися, перш ніж городити велосипеди з милиць.
Спершу потрібно почитати про phpDaemon. потім про сокети. а потім довго думати.
Особисто я, для вирішення подібних завдань на хостингу, не став зв'язуватися з PHP і освоїв Python.
Спасибі за пораду!
А я б узяв ноду (nodejs). Але з нею з наскоку не впоратися - надто вже багато нюансів для непідготовленої людини)
Нода це звичайно добре, ось тільки мій VPS не впорається. Є задумки щодо пожвавлення сайту, і позбавлення від милиць, при переході на інший сервер, з обростання функціоналу, однак, занадто рано.
ось тільки мій VPS не впорається Чёйта? У мене на локальній машині, на винде, нодовскій процес, який нічого не робить, займає 6,5 мегабайт пам'яті. Усе. Для вашого завдання (приймати і надсилати запити) - не сильно більше. Будь-яка vps'ка подужає.
Взагалі, для вашого завдання всі ці танці з keep-alive'ом для curl'а з php не мають абсолютно ніякого сенсу, якщо для одного клієнта вам не потрібно робити більше одного запиту до стороннього сайту.
У вас же як - користувач відкриває вашу сторінку (або відправляє post-запит, неважливо), сниппет через curl робить один запит до стороннього сайту, отримує і віддає дані клієнта і все - php-процес вмирає. Як то кажуть - «php живе, щоб померти». Для іншого користувача створите свій окремий php-процес, який нічого про попередній curl-запит попереднього клієнта знати не знає і знати не повинен. Відповідно, танці з keep-alive'ом безглузді.
Так ось. Щоб скористатися 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'а - це большооой питання.
У цьому є сенс тільки при наявності великої кількості одночасних з'єднань. У вашому випадку - кількості користувачів, які будуть одночасно надсилати запити через ваш сервіс.
А по факту - якщо на вашому сервісі користувачі роблять запити рідше, ніж раз в 30 секунд, то все це шаманство не має сенсу взагалі. Чому? Спробуйте здогадатися самі :-)
А оскільки ви впевнені в немічності вашого vps, значить (скоріше за все) немає у вас на сайті такої кількості одночасних користувачів і останній варіант - найвірогідніший :) Вибачте, переплутав з Shared. У мене чомусь асоціація V - virtual - і значить слабкий.
Саме з шаред переходив на ВПС, з ростом аудиторії.
Поточний проект лежить на шаред, на етапі розробки набагато вигідніше тримати саме шаред (на своєму компі не тримаю з деяких причин). І присутній мандраж, що на етапі розкрутки, почнуться гальма на шаред.
Втім, залишив все як є, судячи з усього не так сильно і вантажить, як не дивно йде близько 3 секунд на запит, що практично не помітно, дивлячись на ajaxloader.
Планую переходити на більш потужне залізо, однак, в той же час не хочу поспішати.
Просто не маю поняття яке залізо потрібно під певні цілі.
Залив трафіку, сидить до 50 осіб одночасно. І думається мені, вони надто часто «довбають» чужий форум. Яким чином можливо поставити таймер? або як назвати.
І думається мені Знову ж - треба чітко розуміти, а не додумувати) Ведіть який-небудь лог, щоб розуміти - як часто робляться запити. Хоч тупо в файл записуйте - не важливо.
По суті так і є, я логін по 1 посиланням, Парс сторінку по 2, і відправляю повідомлення по 3 Тоді робіть як описано в тій статті з Хабра - відкриваєте curl_init. робите запити до форуму скільки потрібно, і тільки після всіх запитів закриваєте з'єднання curl_close (не забувши включити verbose -Опції в curl).
Знову ж потрібно якось фіксувати - а чекають взагалі ваші клієнти відповіді від сторонненого форуму. Тобто ваш-то сервер одночасно 50 чоловік витримує (а чи витримує? може в момент пікового навантаження і ваш сервер не справляється?), але витримує таке навантаження сторонній форум?
Тут здогадки, як ви розумієте, не доречні - все потрібно відстежувати, щоб робити якісь висновки.