cURL постоянное соединение

вот только мой VPS не справится

Чёйта? У меня на локальной машине, на винде, нодовский процесс, который ничего не делает, занимает 6,5 мегабайт памяти. Всё. Для вашей задачи (принимать и слать запросы) — не сильно больше. Любая 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, значит (скорей всего) нет у вас на сайте такого количества одновременных пользователей и последний вариант — самый вероятный :)

Такие вот дела.