PHP.SU

Программирование на PHP, MySQL и другие веб-технологии
PHP.SU Портал     На главную страницу форума Главная     Помощь Помощь     Поиск Поиск     Поиск Яндекс Поиск Яндекс     Вакансии  Пользователи Пользователи


 Страниц (1): [1]   

> Описание: Версия с обеих сторон.
EuGen Администратор
Отправлено: 15 Мая, 2013 - 14:18:37
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




Приветствую.

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

Отчасти, я согласен с автором, поскольку язык действительно имеет корни вовсе не в программировании серверных процессов. Однако же мне интересно как выразить собственное мнение, поделившись им с посетителями, так и обсудить правильность утверждения в заголовке в целом. В самом деле - автор статьи опирается на то, что в PHP очень плохо устроена работа с памятью из-за её хеш-устройства, вследствие чего отслеживать зависимые ссылки очень трудно (да и возможно ли на 100%?). И это правда. PHP действительно имеет проблему утечки.

Но верно ли то, что PHP не в состоянии средствами самого себя позаботиться о своих же процессах? Я считаю, нет. Первое, на что бы я хотел обратить внимание - это сборщик мусора, он появился достаточно давно, с PHP 5.3. Однако же, можно возразить, что 100% очистки он не даст, да и иногда бывает, что память нужна сразу же, после unset, например. Второе, что бы я отнёс к средствам саморегуляции - это register_shutdown_function. Напомню, она выполнится всегда при аварийном завершении скрипта - будь то необработанное исключение, либо же более глобальная проблема наподобие нехватки памяти (но не будет вызвана при получении системного прерывания, разумеется, что позволит прервать исполнение такого демона путём, например, команды kill). И этим-то и можно воспользоваться как раз для создания "чего-то" надёжного, что может следить за другими процессами PHP. Иными словами, PHP будет следить за PHP. Просто добавим это:
PHP:
скопировать код в буфер обмена
  1. {
  2.     $sProcess   = '/usr/bin/php '.join(' ', $_SERVER['argv']).' > /dev/null &';
  3.     //...
  4.     //some preparations?
  5.     system($sProcess);
  6. });

- и, очевидно, процесс-контролёр будет сам себя перезапускать при завершении работы. Разумеется, '/usr/bin/php' нужно вынести в константу, к примеру, но здесь суть в самом способе. Это - одна из возможностей заставить PHP саморегулироваться. Если же процесс не создаёт сущностей, которым нужно непрерывно "жить", то конструкцию выше можно добавлять и непосредственно в такой скрипт (например, сама конструкция взята из демона-рассыльщика SMS-сообщений, которому, очевидно, не критично прерывание, поскольку неотправленные сообщения не получают статуса отправки и после перезапуска старт начинается с начала очереди).
Автор статьи указывает на использование, например, crond для аналогичного способа контроля, но это, во-первых, не решает проблему с вопросом немедленного реагирования (минута - минимальная величина дискретизации запуска в crond - может быть слишком критична), а во-вторых, всё же показывает именно то, что PHP сам по себе не может быть надёжным.

Интересно было бы узнать, какие способы вы используете, если требуется решать серверные задачи посредством PHP-процессов (а, может, не решаете вовсе с помощью PHP, используя другие языки, например, Python?) и обсудить их с другими заинтересовавшимися участниками.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
Zuldek
Отправлено: 15 Мая, 2013 - 15:30:32
Post Id


Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июнь 2010  


Помог: 50 раз(а)




Необходимое для задач PHP в контексте управления памятью в нем есть и тс указал (ничем иным я и не пользовался). Этого более чем достаточно для решения задач предназначенных для языка.
Автор статьи все прямо и умело разъясняет - почти ни с чем не поспоришь. Но постоянно хотелось, пока читал, спросить его - "И что?"
Создавалось ощущение, что автор всю статью доказывал, что лопатой асфальтовое покрытие вскрывать дело не благодатное и для этого нужен отбойный молоток.
Однако, если есть отбойный молоток, это не значит что нужно только им и пользоваться, и копать яму гораздо удобнее и быстрее лопатой.
Для многих сложных задач в контексте разработки интернет-приложений, связанных с необходимостью разработки программ, предусматривающих "постоянно живущие" процессы, есть специально для этого предназначенные демоны на сях, которые прекрасно справляются со своими задачами и нет необходимости решать их на php (а часто и на других языках, если мы говорим о web-разработке).
Никто не запрещает делать на php серверы рассылок, обработку графики и проч. При этом понятно, что для программирования роботов для хирургических операций, создания сервера потокового видеовещания и проч. PHP не то средство (хоть и все это вполне можно сделать и на этом языке).
Выражение автора:
Цитата:
"Для нового проекта я использую Python, virtualenv, Flask, Supervisor и Gunicorn. Я поражен, как хорошо всё это работает, насколько продуман каждый из компонентов"

есть субъектив его мышления. Когда автор откроет для себя, к примеру С, то, после PHP, очевидно, он тоже будет бесконечно счастлив тому, что теперь наконец-то все понятно "полный контроль над памятью, типами данных, сознанием и кармой" и "продуманностью компонентов", которые просто упрощены в интерпретаторе.
Цитата:
поэтому использование второго языка вместо того, который подвёл вас, может оказаться нетривиальной задачей

Радость . Вот это как раз к тому, что технологию нужно выбирать сообразно задачам. И подводит не она программиста, а его незнание этой технологии.
А тяга все реализовывать на одной технологии всем понятна. Другое дело нужно знать (опять же, все упирается в глубину знания) где это позволительно и решение будет работать, а где уже нет.

(Отредактировано автором: 15 Мая, 2013 - 15:51:25)

 
 Top
DlTA
Отправлено: 15 Мая, 2013 - 15:56:14
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2914
Дата рег-ции: Окт. 2010  


Помог: 53 раз(а)




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

хотя имхо что пыха что потомки С идут к чему то единому, только с разных сторон.
 
 Top
EuGen Администратор
Отправлено: 15 Мая, 2013 - 16:08:34
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




По поводу недостатков PHP есть известная статья о "фрактале" - и со многим там я согласен. Однако стек используемых технологий, варьируемый в соответствии с задачей - действительно один из ключей к успеху. При этом собственно использование тех или иных инструментов остаётся на совести разработчика, вот только в PHP их настолько много и настолько велика свобода (мнимая, как оказывается, разумеется), что соблазн сделать "неправильно" очень велик. Сюда же - низкий порог вхождения, когда встречаются случаи с параметрами "изучение второй день", "написание социальной сети", например.
Цитата:
@fopen('http://example.com/not-existing-file', 'r');
Что он будет делать?

* Если PHP скомпилирован с --disable-url-fopen-wrapper, он не будет работать. (Документация не говорит, что означает «не будет работать»; вернёт null, бросит исключение?) Заметьте, что этот флаг убрали в PHP 5.2.5.
* Если allow_url_fopen выключен в php.ini, он тоже не будет работать. (Как не будет? Нет идей.)
* Из-за @, предупреждение о несуществующем файле не будет выведено.
* Но будет выведено, если scream.enabled установлен в php.ini.
* Или если scream.enabled вручную установлен через ini_set.
* Но не в том случае, если не установлен корректный error_reporting.
* Если оно будет выведено, куда оно будет выведено зависит от display_errors, снова в php.ini. Или ini_set.

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


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
DeepVarvar Супермодератор
Отправлено: 15 Мая, 2013 - 17:31:42
Post Id



Активный участник


Покинул форум
Сообщений всего: 10378
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




Если вопрос касаем конкретно php, то я просто напишу как я,получая новые знания, шел к тому, к чему пришел:

Где-то у меня валяется достаточно сложный многозадачный демон на основе pcntl_fork() слушающий сокет на входе. Можно сказать целое приложение. Суть что он делает - не важно. Можете сравнить это с браузеркой гдедемоны написаны на php.

Затем оный был переделан и распилен на отдельные компоненты-процессы while(true){}; общающиеся между собой с помощью shared memory. Так улучшилась синхронизация за счет встроенной блокировки семафоров в памяти. Каждый компонент проверял своих собратьев, на их наличие по PID'у находящемуся в pid-файлах, ну и если кто-то из компонентов упал, его "поднимал" обнаруживший это собрат. Так возросла надежность. А еще возросла и "велосипедность". Но зато какая )))

Затем я отказался от сокетов на входе, и перешел полностью на передачу входных данных через shared memory. В CGI/FastCGI/CLI это возможно, и данные можно передавать даже напрямую с сайта, естественно при ситуации, когда демоны и сайт физически работают на одной машине. Исходя из задач - именно это мне было и нужно.

В настоящий момент я прекрасно осознаю насколько кривой велосипед я запилил.
Однако это работало и не было утечек памяти. Максимальное время без останова - пол года.
Да и дальше бы работало, остановил по причине ненадобности..
Как говорят - "Нет ничего постояннее временного" (ну или как-то так).

Да - на php писать большие реалтайм вещи сложно,
но можно, если очень хочется )))

Ну и на закуску один из старых велосипедов: тыц.
 
 Top
EuGen Администратор
Отправлено: 15 Мая, 2013 - 17:36:10
Post Id


Профессионал


Покинул форум
Сообщений всего: 9097
Дата рег-ции: Июнь 2007  
Откуда: Berlin


Помог: 707 раз(а)




.. а при желании тогда можно и memcached на PHP вспомнить. Но здесь, наверное, уместнее сказать, что это - вопреки, а не "благодаря". Это - не тот спектр задач, которые стоит решать на PHP.


-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.
 
 Top
esterio
Отправлено: 15 Мая, 2013 - 18:28:16
Post Id



Активный участник


Покинул форум
Сообщений всего: 5027
Дата рег-ции: Нояб. 2012  
Откуда: Украина, Львов


Помог: 127 раз(а)




Нужно было ускорить парсинг страниц(не спашивайте что именно). Нужно было обрабативать в паралельных потокак, так как страниц около 20-25 за одно исполнение скрипта и обичном режиме cURL обрабативал 10-15 сек. Подходила мисль написать демона на сях, но тут пришло прозрние в виде мультызапросов в cURL. В итоге на обработку ишло 5-6 сек. и нкаких Си не потребовалось, так cURL сам на Си и там уже оргаанизированая паралельная обработка.
С другой стороны унав о PHP Devel Studio решил взглянуть что ето за такой монстр. В итоге полное разочарование. Имхо полный изврат.
Итог: для каждой задачи свои инструменты. Тот же археолог не будет копать лопатой иначе может испортит експонат, а постой рабочий не будет рить траншею кисточкой(если успеет за год справиться с задачей честь ему и похвала) Радость Радость Радость
 
 Top
caballero
Отправлено: 15 Мая, 2013 - 18:32:51
Post Id


Активный участник


Покинул форум
Сообщений всего: 6001
Дата рег-ции: Сент. 2011  
Откуда: Харьков


Помог: 126 раз(а)




думаю проблемма не заставить PHP быть демоном - это решаемо.

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

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

иначе смысла никакого.

но для этого PHP должен работать как java сервлеты. А это уже совсем другая архитектура


-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore
 
 Top
OrmaJever
Отправлено: 15 Мая, 2013 - 18:47:44
Post Id



Активный участник


Покинул форум
Сообщений всего: 7540
Дата рег-ции: Янв. 2010  
Откуда: Чернигов


Помог: 299 раз(а)




EuGen пишет:
Однако же мне интересно как выразить собственное мнение, поделившись им с посетителями, так и обсудить правильность утверждения в заголовке в целом.

Если говорить за название темы "php создан что бы умиреть" то по-моему автор тут прав. На php нельзя писать демоны, или пускать его в бесконечные циклы типо для работы сокетами. Для этого есть прекрасные компилируемые языки которые сделают это качественее и быстрее. А вот что касается памяти и её очистке то тут ничег осказать немогу т.к. я пишу всегда скрипты которые создны чтобы умирать и меня этот вопрос не очень заботит.


-----
Если вы хотя бы 3-4 раза не решите всё выкинуть и начать заново - вы явно что-то делаете не так.
 
 Top
Ch_chov
Отправлено: 15 Мая, 2013 - 19:35:50
Post Id



Постоянный участник


Покинул форум
Сообщений всего: 2122
Дата рег-ции: Июль 2008  
Откуда: из города


Помог: 90 раз(а)




esterio пишет:
но тут пришло прозрние в виде мультызапросов в cURL
А ещё можно попробовать stream_select
 
 Top
DeepVarvar Супермодератор
Отправлено: 15 Мая, 2013 - 20:28:46
Post Id



Активный участник


Покинул форум
Сообщений всего: 10378
Дата рег-ции: Дек. 2008  
Откуда: Альфа Центавра


Помог: 353 раз(а)




OrmaJever пишет:
На php нельзя писать демоны
Однако ж, пишут Закатив глазки
 
 Top
Страниц (1): [1]
Сейчас эту тему просматривают: 1 (гостей: 1, зарегистрированных: 0)
« Обсуждение статей »


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



Powered by PHP  Powered By MySQL  Powered by Nginx  Valid CSS  RSS

 
Powered by ExBB FM 1.0 RC1. InvisionExBB