Владимир Грабко: Вы себе льстите:) У вас не самый ужасный из возможных кодов:) Сколько лет вы программируете на постоянной основе? Если меньше пяти то удивляться нечему. Если вам кажется что мой код хороший или иногда даже идеальный то я вижу что это только начало на пути к действительно красивому, поддерживаемому и надёжному коду. С каждым годом вижу как меняется собственное представление о том как это делать.
safenoob: может им и не нужно?:) Естественный отбор:) Что бы сделать из этого полноценный ответ надо привести примеры, нужно так же указать модель взаимодействия клиента и сервера, например:
1. клиенты разные, подключаются, получают ответ, уходят, если заходят снова то работает кеш коннектов или keep-alive что по сути тоже самое, для https кеш хендшейков или вроде того (недавно попадалась статья на эту тему с Golang Meetup что был недавно в Москве в офисе Badoo)
2. клиенты известны, постоянные соединения, можно пулять 1 байт в одну сторону и 1 байт в другую... в самом лучшем случае, в худшем, делать echo где ответ будет содержать контрольный бит или сумму от запроса. Но так или иначе - это улучшит пропускную способность, весь вопрос в уровне надёжности и моделе использования.
При этом рассматривать что клиент или сервер будет на PHP - бессмысленно, разве что клиент на PHP, а сервер на чём-то другом более подходящем, хотя даже в этом случае есть куча других мест где в PHP можно тюнить.
1. на php что бы слушать сокет нужно создать сервер, а это тонна накладных расходов, задача отслеживать падения, отслеживать ресурсы и так далее - по этому я сразу сказал что это не простая задача и весь эффект может невилироваться.
2. с другой стороны если решить вопрос надёжности - появляется так же и постоянная память и сохранение контекста и прочие возможности запущенного приложения по сравнению с постоянно запускаемым и умираемым скриптом - но это уже очень сложная задача в рамках PHP, многие, кстати, её решают в той или иной степени в продакшине
3. http это тоже сетевой протокол
4. подсчёт символов даст вам ответ - есть ли польза от того что бы исключить тело ответа и ограничиться заголовками - вот тут вам уже точно нужно читать спецификацию протокола http и понять что разницы между заголовками и телом ответа нет никакого, и там и там текст, только заголовки в начале, а тело ответа в конце и между ними два перевода корретки и в общем-то вот и вся разница
5. curl - это библиотека которая работает с сокетом... убирая curl вы убираете прослойку, но все важные для бизнеса вещи (авторедирект, восстановления соединения, докачка и так далее) вам придётся дописать самому в зависимости от задачи.
Резюмируем:
- если задача сделать самый быстрый запрос и самый быстрый ответ
- если важно что бы передавалось минимум байтов через сеть
- если важно что бы не было лишних обменов пакетами
То:
- нужно смотреть на IP или TCP/IP (вам ведь UDP не нужен в данном случае)
- нужно понимать что PHP сам по себе медленный и скрипты при каждом запросе умирают
- нужно понимать что вам потребуется реально работающий сервер, а не скрипты
- нужно понимать что возможно вам больше подойдёт модуль к nginx который дёргает скрипты
- много всего ещё... хайлоад штука сложная. И почти никогда вам не смогу ничего подсказать другие - потому что точно таким же не занимаются.
Посчитайте количество символов. С отправкой тела ответа символов может быть столько же или даже меньше. Сравните листинги в чистом (текстовом) виде зайдя по telnet и сделав запрос вручную.
Владимир Грабко: напиши свой:) Уверен оно будет таким же страшным как библиотека для связи серверов что у тебя написана, но хоть будет о чём подисскутировать:)
Владимир Грабко: тоже интересно что вас там так задело?:) Я вот хотел к вашему комментарию (golang.org/x/net/html) написать что там адский ад, хотя и вполне корректный:)
Если не ставить датчики температуры то теплоноситель будет показывать "погоду". Температура в городе сильно отличается от того в каком здании, из каких материалов, с какой стороны (солнечной или противоположной) и так далее и так далее...
Добавь в код тесты... То что одинаковое во всех программах и микросервисах вполне нормально вынести в отдельные пакеты и линковать их везде где нужно. Просто такой пакет должен быть с тестами и желательно учитывающими все сценарии всех микросервисов. А иначе нельзя быть уверенным что ваш код функционирует.
Переименовать запущенный файл получается?:) Если да:
- переименовать в bin/program_v123456
- загрузить новую версию в /bin/program
- проверить запускается ли, если всё ок то отлично, если нет - откаваем программу обратно...