Разработка сервера на php и системных скриптов

[WST]

Никак не могу понять, а в чём смысл? Можно с тем же успехом и алиас добавить и, если уж так хочется краткости, то вообще не указывать IP и порт.

[lnroma]

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

[riot26]

Статья явно не уровня хабра. Зачем права 777? Почему не следуете хоть каким-то правилам табуляции (не говорю уже об общепринятым PSR)?

[lnroma]

777 как бы машина локальная и смысла придумывать права нет.
вообще то табуляцию не использую по psr, а используют 4 пробела.

[riot26]

if(isset($argv[1])) {
     $host = $argv[1];
   } else {
     help();
   }
   
   if(isset($argv[2])) {
     $port = $argv[2];
   } else {
     help();
   }

Для одинаковых блоков разная разметка. Да и дублирование — не есть хорошо.

[grossws]

Зачем права 777?

Наверное, чтоб потом макиному хацкеру было удобнее; желательно такое ещё из под рута запускать, чтоб не нужно было потом LPE exploit искать.

[mpakep]

Многие не знают саму возможность такого использования php. Хорошо, что сама тема не часто но освещается. Сам какое то время назад пробовал избавится от апача но столкнулся с задержкой в работе скриптов. Надеюсь тема будет дорабатываться и скоро появится возможность использовать встроенного сервера не только для разработки. Мой интерес тут в минимальном количестве ПО которое используется. По той же причине в последних версиях перехожу на sqlite. Чем меньше всяких «серверов» и «служб» тем более надежна система. Спасибо за статью.

[Delphinum]

Чем меньше всяких «серверов» и «служб» тем более надежна система

А я думал, что чем меньше «серверов» и «служб», тем жирнее и сложнее становится оставшаяся система, их заменяющая, что делает ее менее надежной, не?

[mpakep]

Эта фукнция уже встроена в php даже если вы ее не просили ставть. Часть системы от которой не отказаться. А апач вы ставите дополнительно. От части функционала пхп к сожалению или к счастью не получится отказаться а от апача легко. В данном случае это не замена а использование уже встроенного функционала а не стороннего требующего установки дополнительных пакетов. Поэтому для меня использование встроенных функций огромный плюсь как и отказ от еще одной сторонней системы фукнкции которой удалось заменить встроенными.

[Delphinum]

Часть системы от которой не отказаться

Значит интерпретатор стал сложнее, начал заниматься тем, что к его целям не относится, следовательно стал хуже.

не замена а использование уже встроенного функционала

Нет, использованием уже встроенного функционала это было бы, если бы PHP был веб-сервером, но PHP это интерпретатор, которым пытаются заменить веб-сервер (к слову, я знаю зачем это делается).

[mpakep]

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

[Delphinum]

Если они его туда встроили значит были на то веские основания

И эти веские основания — поднятие тестового окружения без заморочек — ничего более (к счастью).

[mpakep]

Отлично. А там где тестовый запускается быстро и без заморочек почему бы его не использовать под боевой. (Уже вижу как на меня накидывается все сообщество). Но не забывайте любая технология развивается. Когда запуск тестового сервера действительно будет проходить без заморочек идея почему мы боевой все еще запускаем с заморочками возникнет сам собой.

[Delphinum]

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

Потому что окружения везде разные. На одной машине веб-сервер нужно настроить так, на другой иначе, где-то нужна обертка в виде какого нить nginx, где-то можно обойтись одним apache (или одним nginx), следовательно нужно либо учитывать все возможные окружения внутри PHP и автоматически определять их (что невозможно), либо повторять apache и nginx (что нецелесообразно).

почему мы боевой все еще запускаем с заморочками

Открою вам секрет — боевой тоже можно запускать без заморочек.

[mpakep]

Если бы запускали без заморочек небыло бы необходимости создавать подобную возможность в пхп. Чувствуете противоречие? Сейчас вопрос скорее личных предпочтений. Свои предпочтения я уже озвучит. Всегда считал что включение сторонних продуктов исключительным случаем и при любой возможности избавлялся от всего стороннего. Поэтому и встроеная функция мне лично видится более привлекательной. У вас может быть другое мнение. Время покажет. Если есть возможность обойтись без какой либо библиотеки или кода это надо стараться делать. В данном случае такая возможность появляется. Не прямо сейчас а в перспективе.

[Delphinum]

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

Так для теста прод. веб-сервер никто не запускает (хотя нет, знаю несколько людей, которые запускают), для теста есть дев. веб-сервер. У меня это давным давно настроенный апач, который я от проекта к проекту никак не конфигурирую, и не нужно никакого доп. процесса запускать типа: php -S ip:port -t public/index.php

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

Так веб-сервер в PHP это стороннее )

[mpakep]

Так веб-сервер в PHP это стороннее )

apach или нгинкс мне дает возможность как то заменить php? или вы предлагаете один сторонний интерпритатор заменить на другой? php дает возможность не использовать apach а apach не дает возможность обойтись без php слова ничем не подкрепленные. Чтобы создать действительно зеркальную ситуацию пусть нгинкс создась встроенный интерпритатор и мы уже будем говорить про php как сторонней библиотеке в нгинксе. Пока таких попыток не делалаось насколько я знаю. Хотя, возможно тоже было бы интересно.

[Delphinum]

А что для вас значит слово «стороннее»?

[mpakep]

Если мы на столь простых терминах расходимся, о чем мы вообще разговариваем.

Вы до сих пор не понимаете смысл этого термина?

[Delphinum]

Не понимаю, просветите.

[mpakep]

Считаю что разговор можно закончить. Гугл вам в помощь. Я не учитель. Самостоятельно пожалуйста.

[Delphinum]

Ну как хотите ) И вам всего хорошего.

[YemSalat]

apach или нгинкс мне дает возможность как то заменить php?

а то… Можно заменить на любой другой язык.

php дает возможность не использовать apach а apach не дает возможность обойтись без php..

вместо того что бы забивать все гвозди молотком, на котором написано «ПХП» — оглядитесь вокруг, и придет понимание почему apache и nginx — это серверы, а php — нет

Чтобы создать действительно зеркальную ситуацию пусть нгинкс создась встроенный интерпритатор и мы уже будем говорить про php как сторонней библиотеке в нгинксе. Пока таких попыток не делалаось насколько я знаю. Хотя, возможно тоже было бы интересно.

Не знаете предмета разговора, в nginx'e есть nginScript (сравнительно новая «фишка»), плюс поддержка раcширений на куче разных языков, которая была давно.

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

[YemSalat]

Давайте все-таки придерживаться контекста. Мы говорим о ПХП.

Если бы запускали без заморочек небыло бы необходимости создавать подобную возможность в пхп.

Если бы речь была про другой язык / платформу — я бы с вами наверное согласился, но мы говорим о ПХП…
У него фактически официальная позиция — все тащить в «стандартную библиотеку»

Например, можно установить соединение с мускулом без заморочек…
Или подключить библиотеку для работы с изображениями без заморочек…
И т.д.

Но в ПХП все эти вещи «вшиты» в сам язык.

[trilodi]

А как же быть с распараллеливанием процессов? Я считаю что каждый должен заниматься своим делом, апач обработкой запросов, php интерпритацией скриптов,mysql и etc базами, а сувать все в одну коробку это как минимум не целесообразно. Говорю это как владелец высоконагруженного бек сервиса. Даже представить страшно как распаралеливать если все в одной коробке. Каждому свое! Что касается быстрых запусков, то не вижу проблем поставить апач параллельно, и тестить, это делается за пару минут, да какой там, за минуту без каких либо настроек (если конечно нет ничего грандиозного, а если и есть что то такое, то и на php сервере вы провозитесь на много дольше, так как нет достаточно документации и комюнити как у апача)

[Fedot]

Разработчики php не ставят задачу написать вот сервер не для разработки. Уже есть nginx и новый никому не нужен.

[mpakep]

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

[lnroma]

Это просто встроенный сервер как в ROR и python, для боя его неследует использовать так как он сделан исключительно для разработки, а это значит что ни кто не уделял должного времени: кэшированию, многопоточности, и т.д. и т.п. это лишь сервер для разработки… И навряд ли это как то измениться, но поживём увидем…

[trilodi]

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

[lnroma]

Хорошо продуманная и разработанная система не должна зависить от окружения(сервера в частности), если приложение выполняется на разных серверах по разному это как минимум не хорошое приложение. Роутинг лучше делать на стороне php что бы не было +100500 реврайтов в htaccess и location в nginx. Нагрузочное тестирование проводится на препродакшен серверах(полной копии боевого окружения).

[symbix]

Нет никакого смысла заботиться о совместимости с теми средами, которые никогда не будут использованы в продакшене (если это не коробочный продукт типа cms-ок).

Например, я на 146% уверен, что никогда не буду пользоваться Windows-серверами, и полагаюсь на юникс-специфику.
Или, скажем, я на те же 146% уверен, что никакие глупости типа mbstring_overload не будут включены в конфигурации php.

[trilodi]

Вы видимо не совсем понимаете о чем говорите. Как бы вы хорошо не проверили продакшн версию, как бы не провели нагрузочное тестирование, конечный результат всегда может быть неожиданным, и вы всегда будете зависеть от окружения (железо, сервер и тд). Коробочные приложения конечно будут почти всегда исполняться на разных серверах одинаково, в отличии от разработок под ключ, под которые подгоняется железо, сервер и инфраструктура в целом. Я уже промолчу про дальнейшее масштабирование как системы, так и ее компонентов, с разными целями. Ну и про асинхронность в таком сервере забудьте. У меня нет желания на 15 лет возвращаться

[Fedot]

Дело не в успешности, и не в том что кто-то придёт на рынок вторым.
Просто это объективно не нужные трудозатраты. Веб сервер это значительно больше чем то что есть сейчас в PHP. Это множество модулей, которые уже реализованы, и на реализацию которых потрачено множество человеко лет. Нет смысла писать это заново.

> Разработчики php не ставят задачу написать вот сервер не для разработки
Эта фраза о том что сами разработчики PHP не ставят себе задачу написать высокопроизводительный встроенный вебсервер. Так что в ближайшие 5 лет ждать координальных изменений не стоит.

[trilodi]

Внуки оценят! Касательно прийти вторым, вы не забывайте что в те годы технологии асталависты или интернет эксплорера были убоги и не состоятельными, и практически стояли на месте без какого либо активного развития, фаер фокс подтормаживал, хром взял своей скоростью работы, гугл поиск взял в свое время ресурсами и развитием молниеносным, победил тот кто активно развивался и развивал стандарты. Сегодня nginx и apache активно развиваются, и добиться их уровня или переплюнуть будет ой как не просто. Вообще не вижу смысла для развития данного направления. Почему бы тогда не взять и не переписать гугл? — по вашей логике, почему бы и нет, можно, но сколько времени, ресурсов уйдет на это, и не факт что выстрелит!

[Aibolit]

Асталависта, бейби. Была АльтаВиста.

[LeonidZ]

Мы очень счастливы, что вы узнали о существовании опции -S у php. Она нужна исключительно для тестирования без поднятия окружения, генерирует особые заголовки (например, PATH_INFO, который REQUEST_URI в классическом понимании), работает очень особым образом. В общем, для реального сервера не годится совершенно.

[dmx102]

Интересно, на сколько будут ощутимы утечки памяти, если использовать такой подход? В случае использования CGI или FastCGI на каждый запрос создается отдельный процесс или пул процессов, при завершении скрипта который тут же уничтожается и память высвобождается. По этому можно пренебречь качеством самого кода.
Или он на каждый запрос форкает себя?

[Delphinum]

Или он на каждый запрос форкает себя?

Нет конечно.

на сколько будут ощутимы утечки памяти

Про утечки не знаю, но от открытых файловых дескрипторов система вскоре загнется (если где либо используется что то типа file_get/put_contents).

[zoonim116]

Warning
This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network

Это первый абзац с сайта php.net, по поводу их встроенного php сервера, я думаю разработчикам виднее. И все-таки стоит прислушиваться к ним.

[symbix]

Этот сервер годится только для мелкой разработки для небольших проектов — он в состоянии обработать только один запрос одновременно.

Вот, смотрите:

$ cat index.php
<?php
sleep(1);
echo 'Hello World';

$ php -S localhost:8888 index.php

$ ab -c 10 -n 10 http://localhost:8888/
[...]
Concurrency Level: 10
Time taken for tests: 10.015 seconds
Complete requests: 10
Failed requests: 0
Total transferred: 1360 bytes
HTML transferred: 110 bytes
Requests per second: 1.00 [#/sec] (mean)
Time per request: 10015.454 [ms] (mean)
Time per request: 1001.545 [ms] (mean, across all concurrent requests)
Transfer rate: 0.13 [Kbytes/sec] received

[lnroma]

Каковы критерии крупного проекта?

[trilodi]

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

[symbix]

Тут проект должен быть настолько мал и неважен, чтобы вообще не заботиться о его производительности.

[lnroma]

Этот сервер для разработки, зачем ему производительность?

[trilodi]

А как вы собираетесь тестировать асинхронность? Скорость вызовов методов? Вы вообще не понимаете о чем пишете. Глючит метод, ну и ладно, возможно на продакшн сервере будет работать нормально потому что тестовый сервер тормозит. — БРЕД

[lnroma]

Обычно цикл разработки это dev(локальный сервер) -> тестовый -> препродакшен -> продакшен. Бред это то что вы сразу с dev на prod льёте.

[symbix]

Никто не льет.

Если на локальном сервере страница, которая в нормальной среде открывается 0.1 секунду, на локалке открывается 10 секунд — это очень фиговая среда разработки.
Можно совсем довести до абсурда и после каждого изменения кода заливать на стейджи. Зачем тогда локальный сервер-то вообще? :)

[trilodi]

Я пропустил эти этапы. Так как обычно нормально сделанный продукт прогназируемо отрабатывает на всех этих этапах. С данной же техникой строить какие то прогнозы? — да вы шутник. Хорошо что посмотрели википедию о этапах публикации разработки, дальше почитайте внимательно, и поймете что не правы в своих суждениях. Делать что то в одной среде, потом переделывать на других этапах только потому что оно перестало работать, таким макаром все сроки прогорят, еще и в долгу останетесь. Опять таки повторюсь, это что то из разряда назад в прошлое, такая поточность лет 15 назад использовалась, благо сегодня и железо и софт позволяют работать в многопоточном режиме. Мучать себя в однопоточном режиме?-да помилуйте

[symbix]

Если проект мал и неважен — особо незачем. Я как раз об этом.

Речь, разумеется, не об абсолютной производительности, а об относительной. Вот добавили аяксиков, стало тормозить — это потому что дев-сервер однопоточный или потому что код такой? Установить nginx и fpm — как-то побыстрее будет, чем тратить время на эту ерунду.