Как стать автором
Обновить

Комментарии 106

В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS. А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты. Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник, чтобы его можно было распространять как есть, без необходимости ставить рантайм.

У каждого языка своя направленность, а когда пытаются засунуть один язык везде… Вот это удручает, что приложения пишутся вот так
Удручает больше тот факт, что программирование в сущности это про работу с текстовыми данные (подразумеюваются не только исходники), но единого инструмента для этого как не было, так и не предвидится.
Но исходники это в первую очередь не текст, а программа на каком-то языке, текстовое представление AST, которое удобнее обрабатывать специализированным инструментом, нежели обычным текстовым редактором. А поскольку языки все разные, то единый инструмент вряд ли возможен, и даже плагины для всех языков в одной IDE будут иметь достаточно большие отличия в поведении.
По факту любой автомат этот текст.
Текст это чудо которое сотворили люди, а не природа, но проблема в том что люди не могут думать иначе чем текст

Диаграммами могут некоторые...

Ну можно сделать велосипед с архивом, куда придётся ложить ещё и интепритатор. Компиляция в бинарь была бы мега пушка, можно было бы хотя бы простые консольные штуки пилить, с ui сложнее

Да всё это было. Просто с ростом культуры кода забылось.
Могу поделиться упакованными екзешниками php 4.4 под винду, которые весят от 635кб до 1434кб (в зависимости от комплектации). При запуске выполняют рядом лежащий index.php (зловонный Index.php с демонстрацией окошек прилагаю)
https://yadi.sk/d/oZmQ9bQGgXawjQ
Естественно, можно было бы весь код упаковать в 1 файл, но тут весь смысл в переносе компилятора на любую машину с возможностью в блокноте написать нужный код. В армии это особенно принесло пользу — надо было написать скрипт по умному переименованию сотен-тысяч mp3-файлов (убрать префиксы и прочий мусор из названий). Накидал код в блокноте и готово.
php5 упаковывать уже накладно (выходит более 5мб), поэтому лучше dll класть в папочку и таскать с собой. Решения есть и под php7. Странно, что под php8 пока всё выглядит немного уныло даже с ffi уже в комплекте. Но это вопрос времени, как мне кажется.

Это как я понял просто скомпиленый php.exe с нужными расширениями, я подобный компилил для андройда, во времена когда не было всяких ksweb

Может, в настоящее время вместо велосипеда с архивом решением имеет право стать Docker-контейнер?

Так в ноде насколько я знаю тоже нет варианта упаковать все в один бинарь.

Есть — https://www.npmjs.com/package/pkg
Правда под виндой у меня бинарник выходил больше 40мб точно

Это разве не упаковка ноды вместе с исходниками? Если да то не вижу причин почему на пхп так нельзя сделать

и не нужно писать всё всё на одном языке.
выучить библиотеку для написания чего-то нового по времени и трудозатратам ничем не меньше, чем выучить новый подходящий для этого язык.
Не совсем.
Стоит учитывать, что библиотеки основные фишки языка сохраняют, а вот языки, особенно не мейнстримные, могут весьма значительно различаться
да, не трудозатратно. Но языки же живые, большинство из них не enterprise и не заботятся об обратной совместимости, и их синтаксис меняются по желанию левой пятки мейнтейнеров, из-за чего постоянно есть какой то deprecated и прочие несовместимости, как в том же python 2 и 3.
Есть DevelNext, этакий гибрид из Java-runtime и php. Интересная вещь, жаль, что не очень широкие возможности. Писал на нём маленькое приложение
Но, к сожалению, я не нашел популярного способа хотя бы упаковать PHP код в бинарник

Было что-то лет пятнадцать назад, но особо не взлетело.

В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.

Можете. На чистом PHP без каких-либо дополнительных экстеншенов, которые идут через pecl. У меня пока не возникало такой задачи, где бы на пыхе это нельзя было реализовать.


Разве что сталкивался с проблемами uint64_t, в OpenGL, но оно обходилось явным выделением памяти под этот тип, а оверфлоу будет только при касте к пыховскому инту (который не unsigned).


А так, я бы с удовольствием пилил на нем и мобильные приложения, и десктоп, и cli утилиты.

И кто мешает? С мобилой сложнее, нужно через terminus запускать, а не паковать в apk. Но в теории можно придумать и нормальный запуск. Не копал в этом направлении от слова "вообще", но раз на сишке можно писать под мобилу, значит и на пыхе можно, просто чуть иначе перепаковать бинарь.


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

Тут или шашечки, или ехать. Java, JS или любой другой платформонезависимый код поставляется с рантаймом. Никто не мешает поставлять в своей сборке и бинарь рантайма, как это делается, например, в случае с IDEA. С точки зрения реюзабельности — это самый профитный вариант.




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

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

Про джаву не совсем правда-она вполне успешно компилируется в бинарь

Признаться, подобных подходов вообще ни разу не встречал. Ну или не обращал внимания просто… Буду знать, спасибо.

Без обид, но те, кто пишет на js все-все-все (особенно мобилки и десктоп), будут гореть в аду. Производительность этого всего-всего-всего никакая-никакая-никакая. Только php в этом формате нам и не хватает для полного счастья. Консольные утилиты — ок, в этой области претензий нет.
Наоборот, тенденция в мире такая, что все хотят один язык для всего. Поэтому Go, JS, C#, Kotlin, etc — все хотят пролезть во всё.
НЛО прилетело и опубликовало эту надпись здесь
Если все что я прочитал про PHP 8 я понимаю верно, то у разработчиков такая же хотелка, поэтому они добавили JIT, это первый шаг. Вангую что скоро будет добавлено и упрощение сборки в бинарник.

После доклада Дмитрия Стогова о JIT на PHPFest 2020 был вопрос:


Планируется ли версия PHP, которая будет компилировать код в бинарник (по аналогии с C или Go)

Дмитрий ответил:


Нет, не планируется, хотя в принципе я не вижу ничего сложного — для этого всё уже есть… Если вы хотите распространять close source проекты и зарабатывать деньги, тогда пожалуйста, сами делайте
НЛО прилетело и опубликовало эту надпись здесь

Мотивация создания бинарников не понята, наверное. А потому ответ может быть не на ТОТ вопрос.

В такой постановке вполне не тот вопрос — нет. Единственную необходимость в исполнимых, какую он наиболее предполагает — закрытые исходники, про что он дополнил. А на основе этих ответов можно предложить, почему вам нужна компиляция и что это даст сообществу.

Лично мне она нужна для удобства инхаус разработки и эксплуатации )Это если говорить именно об исполнимом бинаринике/ Ещё хотелось бы аналог .pyc файлов в python

phar не подходит?

Неа. Он содержит только php код. Если бы ещё, например, расширения вкладывались то частично бы подошёл

Я знаю, что только код. Можно же скомпилить себе пых с нужными расширениями и будет всего пара файлов. При желании, упаковать их в архив с самозапуском из памяти. Наверняка подобные решения есть. Конечно, это не так просто, если бы всё было заготовлено. Но решаемо.

Мне это нужно, чтобы упростить ежедневную работу, а не усложнить ) Коробочным решением с удовольствием бы пользовался — в гоу понравилось когда его немного пробовал, а что-то костылять плохо стандартизированное… Лучше уж докер-контейнерами доставлять — стандарт де-факто уже можно сказать. Если админы-девопсы есть, то им даже специфика ПХП особо не нужна

НЛО прилетело и опубликовало эту надпись здесь

Я ж так и написал. Более того, вот вчера сделал пайплайн:
На билд-сервере:


  • чекаут репы
  • сборка образа
  • пуш образа
    Идём на прод:
  • пулл образа
  • создаем контейнер
  • копируем из него файлы на хост )
  • удаляем контейнер, так и не запустив

Просто аналог зип-архива, например

НЛО прилетело и опубликовало эту надпись здесь

На удивление в CI/CD это оказалось проще, чем поднимать контейнер с кастомным PHP, монтировать исходники, билдить в нём, создавать артефакт архив, потом его загружать, расжимать и рсинкать на таргет. И для кэширования по composer.* ничего специально делать не пришлось )

В PHP меня расстраивает только один факт: я не могу писать на нем все-все-все, как на NodeJS.
Вы и на ноде не можете. Просто php-разработчики обычно не испытывают иллюзий по поводу границ применимости своего языка.

Здесь должна быть шутка про «Один пацан писал все на JavaScript...»

Есть babel-preset-php, который синтаксис PHP7, кроме деструкторов, ссылок, die(), суперглобальных массивов с данными запроса и еще некоторых моментов транспилирует в JS, который можно обернуть в Cordova/PhoneGap и получить десктопное или мобильное приложение.
Реальных проектов не видел.

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

тут надо разделять просто упаковку в бинарник как замену php program.phar или php -S и всякие извращения с GUI типа завернутого хромиума

Для php8 будет доступна jit-компиляция и разработчики обещают, что скоро возможность создания приложений появится. Мол, язык уже давно вырос, окреп, и в своей серверной нише ему тесновато.

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

Ээээ… Эти утверждения вы придумали только что? Дима тыщу раз повторял, что этого ничего не будет. А, мол, если надо — пилите сами, благо не сложно (с) почти цитата


Ну т.е. откуда эта информация?

Информация из доклада Стогова.

Важно разделять понятия «построение нативных приложений» и «компиляция в закрытый бинарник». Это не совсем одно и то же. Особенно когда речь идет о JIt-компиляции.

Стогов против второго, но ничего не имеет против первого.
Стогов против второго, но ничего не имеет против первого.

А с чего ему иметь? Я кажется тоже самое написал: "Хотите делать — делайте".


И попросил пруфов на тему того, цитата: "разработчики обещают, что скоро возможность создания приложений появится". Но при этом никто никогда не обещал, что "вы сможете билдить полноценные и самодостаточные бинари".


Или вы имели ввиду возможность создания их в целом своими силами? Если в целом, то она ещё в PHP 4 была (или когда там появился embedded sapi?). Тот же мёртвый нынче Devel Studio работал так, брал и подрубался к API PHP через Delphi, а потом это всё в бинарь один собиралось. Делайте, никто не запрещает.

Это, конечно, все хорошо но мне что-то подсказывает, что написание своего статического анализатора и ORM потому, что «других нормальных нету» — это не совсем то, что ожидают от полноценной экосистемы абстрактного языка в вакууме

это не совсем то, что ожидают от полноценной экосистемы абстрактного языка в вакууме

Я правильно понимаю, что обычно, у более других языков, "полноценная экосистема" возникает сама собой, ее никто не пишет?

НЛО прилетело и опубликовало эту надпись здесь
Жду момента когда на пхп из коробки можно будет легко и просто написать самостоятельный микросервис, как на ноде например. Без установки отельного веб сервера, без swoole и roadrunner, без танцев с pthreads. Это будет новый виток эволюции.
Скорее всего к этому таки придут, но еще надо подождать пару лет.

А кто мешает? Я писал такое ещё на PHP3. Открываем сокет слушаем обрабтывае. Да, синхронно, да однопоточно, да память текла во всю тогда… Сейчас со многим лучше. Генераторы вон можно прикрутить

Какой смысл с однопоточного сервера? Мы же о серьезных вещах говорим.

А ничего, что в ноду многопоточность только недавно завезли (и то не факт, что прикрутили к эвентлупу, тут надо жсников спрашивать), а раньше как бы никого это и не волновало особо? В чём отличия-то?

в ноду многопоточность только недавно завезли

А об этом все забывают, один случайный sleep в 15м году убивал весь сервер :)

Автомасштабирование в кубере или ещ' где настраиваем — полушутка

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ничего не имею против отдельного веб сервера, просто не всегда подходит что скрипт живет только один запрос. Бывает нужно сделать демон со своим состоянием, например для лучшей производительности или из-за особенностей бизнес-логики.
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Хотелось бы все-таки, чтобы -S годился для прода просто как запускальщик index.php условного для микросервисов

НЛО прилетело и опубликовало эту надпись здесь

За второй не скажу, но с первым в докерах или типа того постоянно нюансы: их в один контейнер помещать с супервизор или системд или в разные. Чистую статику из пхп-фрейма как веб-серверу давать. Пользовательскую.


Да и вообще, два компонента обычно сложнее в разработке, разворачивание поддержке чем один.

НЛО прилетело и опубликовало эту надпись здесь

Я знаю эту философию, поэтому и вопрос вечно этот возникает, каждый раз когда в контейнер пытаешься пхп-фпм положить — в расшаривание файлов между контейнерами много нюансов.


P.S. Облачные сервисы не рассматриваем по ряду причин, кроме как базу для подъёма виртуалок и сетей между ними. И то, обычные хостеры предпочтительней, особенно если АПИ дают по цене обычного ВДС хостинга. А так на текущем проекте обычные дедики

Да нет никаких нюансов, нужно просто разбираться в правах, пользователях и докере.
Так про всё можно сказать, что «есть много нюансов» :)

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

НЛО прилетело и опубликовало эту надпись здесь

Ту, что решается по ссылке на 5-м шаге с помощью --volumes-from, который если не deprecated ещё в самом docker, то точно к лучшим практикам не относится.


Задача в целом такая: папка в одном контейнере должна быть примонтирована в другой. На практике: есть контейнер с приложением в /app/public/ которого лежат какие-то статические файлы, нужно это папку примонтировать в /var/www/html контейнера с nginx или apache. Усложнённый вариант: первый образ не просто содержит в папке файлы из билд-тайма, но и активно создаёт их сам в рантайме.

Это у вас какие-то жуткие артефакты непонятно чего. Либо докер пятилетней давности, либо какой-то суперспецифичный кейс. Через биндинг папки хоста ни разу на куче проектов проблем не было, в т.ч. даже на маке.

Обычный кейс: контейнер с пхп /app/public которого нужно смотнтировать в /var/www/html контейнера с nginx. Докер 20.10.


Если что я не про глюки или ещё что, а про документированное поведение, но его нужно знать наизусть, чтобы не принимать документированное поведение последней стабильной версии за "артефакты или докер пятилетней давности"

Ээээ, и в чем проблема?

php:
...
volumes:
- /var/www/public:/app/public

nginx:
...
volumes:
- /var/www/public:/var/www/html

Там же пусто будет! Или вы при каждом деплое на проде будете из CD делать что-то вроде:


docker build -t app:$tag .
docker create -name app-$tag app:$tag
docker cp app-$tag:/app/public /tmp/app-$tag-public
rsync /tmp/app-$tag-public/ production:/var/www/public/

?

Подождите, давайте по очереди :)
Есть две практики:
— докер содержит вселенную, код монтируется отдельно. Это характерно для дев- и стейдж-сред, и мой вариант отлично подойдет — мы подмонтируем папку с кодом, код управляется отдельно через CI/CD, ansible и т.д.
— докер-образ уже содержит код. Это фиксированная среда, допустим для прода. Тогда я не понимаю, зачем нам монтировать вольюм, когда мы можем положить код в каждый образ через мультистейдж-сборку. Рантаймы же, если они нужны — снова-таки через общий хостовый вольюм, если они по архитектуре лежат внутри папок с кодом — окей, унесем симлинками.

Речь в целом не про код, а про данные, но ладно. А вы только подтверждаете мои слова про "есть нюансы":


  • код/данные откуда-то должны взяться — деплой через git pull?
  • CI/CD ансибль нужны
  • дублирование данных по контейнерам (а их там сотни мегабайт может быть легко), усложнение и увелечине времени сборки (а мог бы быть базовый nginx прямо с хаба, ладно докерфайл с одним копированием конфига)

Я ещё вариантов решения могу набросать:


  • волюм полноценный, ентрипоинт копирует в него из контейнера при старте перед запуском основного процесса
  • вообще на сервере эти даные не храним — хоть с3, хоть гитхаб пэйджес

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


И это всё нюансы простой задачи расшарить папку между контейнерами. Часто проще плюнуть на идеологию докера и запихать два процесса в контейнер плюс супервизор

Окей, я согласен, что конкретно задача шаринга в вашей постановке не решается элегантно в одну команду :)
Со своей стороны хочу добавить — что это вообще не мешает жить :)

С одной стороны, да, не особо мешает: выбрал какой-то способ (для меня по дефолту — мультистейджинг, как требующий вовлечения минимума лишних сущностей), настроил раз, пускай и кучу времени потратив, и забыл.


С другой, рано или поздно вылезают какие-то траблы и понимаешь, что надо всё переделывать

Знаете, тут хочется процитировать афоризм, приписываемый Черчиллю: «Демократия — наихудшая форма правления, если не считать всех остальных» :)

Как-то так, да.

Философия докера: один контейнер — один процесс.

Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах. Является ли это достоинством?

посмотрите на nginx unit

Выглядит очень интересно. А то уже думал может апачем пхп запускать для одного процессаю Спасибо за наводку. В проде пробовали?

Ну вот и получается что микросервис на php невозможно задеплоить менее чем в двух контейнерах.

Простите, а этот тезис с потолка взят? Или для вас нормально в прод (раз уж про деплой заговорили) выкатывать сервисы без супервизора, балансеров, взрослых серверов и прочего "баловства"?

Нормально один nginx на N php-fpm пулов или даже процессов (разные версии пхп например) на одном сервере под управлением системного systemd. С докером же это не очень нормально получается — выходит 1+N процессов nginx чтоб более-менее удобно деплоить отдельные приложения/сервисы

Для начала стоит определиться с тем, что используется:
1) nginx — это внешний сервер.
2) fpm — это супервизор для php с fcgi гейтом.
3) systemd — это ещё один супервизор (и крон в т.ч.) под всё остальное.


Два из этих сервиса (fpm + systemd) — это супервизоры, а значит должны быть непосредственно прибиты к контейнеру, в котором они там что-то менеджерят. Ну или делать это снаружи (например systemd может мониторить докер контейнер), так?


Получается, что у нас только один контейнер с fpm, который открывает наружу порт к которому nginx уже коннектится через fcgi.


А если подобная ситуация не нравится по какой-либо причине, то они выкидываются, а nginx разворачивается как реверс прокси и/или балансер напрямую на пыховский сервер (благо их туча: amp, react, swoole, PEAR, etc).


Ну или я что-то не понимаю… По два-три раза прочитал комментарий что этот, что ранее аналогичный, но так до конца и не уверен, что понял проблему полностью.


P.S. А ещё вместо fpm можно взять roadrunner, он выполняет примерно ту же роль процесс менеджера, что и сабж. И вместо контейнера с fpm надо будет стартовать уже rr. Остальные телодвижения примерно те же самые.

Типичный (для меня и вообще на просторах мануалов и туториалов) сетап сервера для нескольких пхп приложений (на примере убунту по памяти)


  • nginx c конфигами для статики и fastcgi_pass в /etc/nginx/sites-enabled/* для каждого приложения
  • php-fpm c конфигами в /etc/php/7.4/fpm/pool.d/* для каждого приложения со своим портом/файл-сокетом
  • всё это systemd держит

На докере обычно получается, что приложение — это два контейнера в связке с конфигами для выделенного nginx и php-fpm. Или запихнуты в один плюс, обычно, supervisor. Плюс общесистемный nginx или haproxy (trаefik вроде тоже) как http reverse proxy в качестве чисто http роутера/"ингресса"


Хотелось бы чтобы php приложение было в одном процессе, слушало http, эффективно раздавало статику из публичного каталога приложени, ну и обслуживало динамику. И всё это гибко, очень гибко, настраиваемо на уровне билда или старта контейнера/ Как рабочий функционирующий пример: apache2+libphp или вон в комментах узнал про nGinx Unit.


Так понятнее? )

Блин, это мне целую простыню текста придётся писать, что б пояснить своё мнение развёрнуто. Но постараюсь...


В общем, есть БД для небольших приложений под небольшую загрузку, которые не требуют оркестарции — sqlite. Это вполне себе production-ready решение, но для определённого круга задач. Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?


С серверами всё точно так же. Если не нужно ничего особо крутого, то в node достаточно использовать express, в ruby webrick, а в php перечисленные мною выше в заминусованном комментарии. Они вполне эффективно (и местами эффективнее, нежели nginx), отдают и статику, и гибкие, и настраиваются в билде и вообще всё, что вы перечислили, просто потому что написаны на том же PHP. И не надо ничего ставить кроме самого PHP. Но при масштабировании требуется уже больше возможностей, поэтому ставят специально заточенное под это дело внешнее ПО.


В вашем случае — вы изначально воспользовались крутыми сторонними решениями, предназначенными для масштабирования, высокой нагрузки и поддержки всего, что есть в вебе. Но что мешало, если не нужно такого — не стрелять из пушки по воробьям, а воспользоваться более простыми аналогами, написанными на том же PHP?


Ну как-то так…

Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?

В мире PHP обычно всё же по умолчанию mysql, за сотни собеседований от трейни до лида второй команды только пару человек вообще пробовали с ним работать.


Так и с остальным, наверное. Раньше apache+modphp стандартом де-факто для самого простого хелловорда были, потом nginx+php-fpm, сейчас — они же в докере (с кмпозом в качестве оркестратор), хорошо если не кубер поднимают для бложика на вордпресе. При этом вопрос масштабирования/отказоустойчивости если и поднимается при выборе этой части инфраструктуры, то только горизонтального и бэкапов. В крайнем случае в уме держат реплику мускула для отчётов и тех же бэкапов.


Думаю, популярность этого связана с простой, если не самих средств, то их разворачивания и минимального конфигурирования путем копипасты нескольких готовых конфигов. Да даже ещё раньше, со времён массовой популярности апачи виртхостингов, где вообще свой софт установить или свой cli php процесс запустить нельзя было. Это всё досатточно простое чтобы стать, скорее всего, самым массовым способом создать работающее веб-приложение. При этом с большим запасом "прочности" когда задачи становятся сложнее. Тепрь туда добавился докер и идёт кубер. И, не дай бог, сделают лямбды на авс нативные )


Swoole (на С написан скорее всего) и ко для тех, кто вырос на LAMP и продолжателях, сложнее по факту. Скорее рассматривается как "вот понадобится масштабироваться, работать асинхронно и т. п. — у нас есть такие варианты в запасе чтоб не переписывать всю кодовую базу на Go/Kotlin"


P.S. плюсиков добавил — интересный диалог

Не, ну понятное дело что cgi удобнее демона по части забивания болтов на утечки памяти, отсюда и любовь к "классическим связкам". Но с другой стороны тут претензии были выше от mayorovp к тому, что PHP не умеет вообще никак иначе.


Ну и, думаю, довольно странно при таком количестве технологий закрывать на это глаза и рефлексом ставить "sudo apt install php-fpm". Для какого-нибудь хоумпейджа никто не запрещает поэкспериментировать с другими технологиями, которые могут вполне оказаться и удобнее в оркестарии и стабильнее.


P.S. Для бложиков я уже поднимал sqlite и могу сказать, что разницы с mysql вообще не заметно (при такой-то нагрузке, которой особо и нет). А это значит, что на VPS можно вполне минуснуть пол гига оперативы и кусок места на харде, просто избавившись от mysql в пользу локальной sqlite.


Тоже касается и React + Swoole (другое не проверял). Полёт вполне себе нормальный. Так что уже начинаю воспринимать не как "модную шняжку", а как вполне себе рабочее решение, которое можно и на чуть более серьёзных проектах использовать.

Бывает же. Первый раз вчера за 8 месяцев работы прилетела задачка оценить разработку почти стороннего для основной системы демо-сайт, даже без технической интеграции любой, чисто брендовость общая. Прочитал ваш комент в 2 часа ночи и до 7 утра экспериментировал со  Swoole.  Поднял в докере http/ws сервер. чатик в памяти — вроде работает. Впечатление двойственное: давно такое низкоуровневое и, я бы сказал, процедурное чуть ли не PHP3, и без поддержки в IDE нормальной не писал (ide-helper помогает, но не сильно — они сами признают, что он минимальный, но развивать нет ресурсов особо). И документация какая-то специфичная для таких проектов.


А с другой стороны работает, правда нагрузки не делал пока. В любом случае спасибо, что так вовремя "заставили" попробовать.

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


Так что лично я бы выбрал лучше React (если о качестве исходников говорить) или Amp (если об удобстве использования).

А Workerman не вариант?
в node достаточно использовать express, в ruby webrick, а в php перечисленные мною выше в заминусованном комментарии

Я бы не надеялся на качественную и эффективную обработку https и раздачу статики в стандартных языковых библиотеках. Точнее, она наверняка сильно уступает таковой в nginx и его конкурентах.

Ключевое слово:


Если не нужно ничего особо крутого

В некоторых случаях подобные решения даже не про все HTTP методы знают и на какой-нибудь HEAD могут ответить "ой".

НЛО прилетело и опубликовало эту надпись здесь
php-cli через supervisord? :)
И забудете о всех межпроцессорных штуках
Нужно пообщаться между скриптами — memcached, реббит, редис
а почему забыть? IPC вроде есть под PHP

По памяти он именно "вроде", просто биндинги

Чем вас не устраивает, например, Workerman, который в некоторых тестах давит даже Go и Rust?
Отвратительный перевод. Если вы постите перевод статьи из гуглтранслейта — это плохо. Хотя бы вычитывайте после автоперевода статью.
да нормальный перевод
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.