perl -pi -e 's|обновитьтся|обновиться|' $TEXT

сори за граматические ошибки.

А у меня складывается мнение, что php из легкого аккуратного
движка все больше становится тяжеловесным и полным багов.
Я делал замеры. Версия 4.3.0 обрабатывает одни и те же скрипты
в 1.5 раза медленнее, чем 4.0.6. Поэтому откатился назад.
Если так будет продолжаться, то проще перейти на старый добрый
perl. Лично мне php был интересен исключительно из-за более
высокой скорости.

эээ...... "Лично мне php был интересен исключительно из-за более высокой скорости"

более высокой чем у Perl ?????? Чаво курил то ?

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

Единственная альтернатива - криворукий перловый программист.

Еще один анонимус.

Именно криворукий.
ПХП быстрее только в качестве модуля веб сервера.
Да и "компилит" оно быстрее.
Но одна и та же задача(более хелло-ворлд) на перле будет исполнятся быстрее. Я имею ввиду чистое время работы программы.

> ПХП быстрее только в качестве модуля веб сервера.

Дык я именно про веб применение говорю. Я знаю, что вне веба
perl может быть быстрее.
Короче, на практике это выглядит как большее количество запросов в секунду, которое выдает php-скрипт по-сравнению с
аналогичным perl-скриптом. А в теории я могу объяснить это так:
Первая составляющая скорости php - нативная обработка GET/POST
вместо громоздского и тормозного CGI.pm. Второе - нативные
функции для работы с БД вместо тормозного DBI.pm.
По-моему все логично.

А кто тебя заставляет пользоваться CGI.pm, когда есть модуль Apache, который даст тебе производительность?

GET можно разобрать самому с помощью regexp'ов, а POST-запросов гораздо меньше, поэтому для них можно использовать и CGI.pm

А насчёт DBI -- смотри на Apache::DBI, который, по-сути, persistense database connection.

Кроме того mod_perl хранит кэш скомпилировной программы, и хранит данные в памяти. При правильном использовании это может ещё поднять производительность.

Я пользовался иногда PHP, до тех пор, пока не узнал о Text::Template, HTML::Template и Apache::DBI. После этого я о PHP забыл совсем.

2anonymous (*) (2003-02-19 23:07:35.017)

> есть модуль Apache, который даст тебе производительность

Объясняю. Апач не использую, т.к. это поделие не отвечает моим
потребностям и вообще не катит за вебсервер по моим понятиям ;)
У меня на сервере живут десятки платных виртуальных хостов с
большим трафиком. Все они хотят иметь возможность писать в свои
домашние каталоги из скриптов. Я пробовал suexec. Это полная
лажа. Тормозная и уродливая как смерть. Соответственно ни о
каком модуле при таком раскладе речи не идет, а все прелести
самого крутого вебсервера всех времен и народов растворяются
как дым. Зато вылезают все его кривости - огромный аппетит на
ресурсы при минимуме отдачи.

Соответственно, не проходит совет использовать Apache::DBI.

> Кроме того mod_perl хранит кэш скомпилировной программы,

Ага. И раздувает потребление памяти до совсем уж заоблачных
высот. Спасибо, не надо. Памяти всего гиг. Половина уходит
на другое прожорливое поделие - mysql ;( Я нехочу ставить
сервер на колени. Это уже пройденный этап.

> Я пользовался иногда PHP, до тех пор, пока не узнал о Text::Template, HTML::Template

Ну а это я не понимаю. Какая связь между шаблонами и
переходом с php на perl? Неужели не нашел ни одной библиотеки
шаблонов для php? Я по памяти могу назвать с десяток ;)
Причем гораздо более быстрых, чем тормозной HTML::Template.
В _разы_ более быстрых.

что мне подсказывает, что сейчас последнего анонимуса (не меня) опустят из-за апача по самое нихачу :).

Ты чего так говорить. Это же лор, тут только хай-энд хакеры :)

В апаче можно дать возможность писать пользователям в свои домашние каталоги через mod_userdir, или имелось ввиду чтото другое ?

А насчёт памяти, стоит посмотреть http://phpsysinfo.sourceforge.net/phpsysinfo/ (;

Но я не развожу флейм, и не даю повод для драки, я также согласен с тем что у апача и свои недостатки есть ;)

Апач -дерьмо!

Я смотрю, этот долбаный индеец всем нравится из-за того что кроме него никто ничего не знает, и знать не хочет. Скромный thttpd с пхп делает его в разы отъедая всего 3 мб и оставляя остальное на поделки вроде мускля. А если статик контент отдать tux'У... . Вобщем у полонников краснокожих нет ни шансов ни аргументов.

Насчет apache и thttpd: не спорю: все эти thttpd и tux - по скорости сделают апач. Так сказать, "простая и быстрая альтернатива". Равно как и php делал по скорости и простоте perl. В свое время. Но...история движется по спирали. PHP как и Apache, сначала вырастают из пеленок, потом - настает их звездный час, потом - понемногу начинают становиться монстриками, а после - и монстрами. И на смену приходят новые "самые быстрые и удобные" технологии. PHP-то еще поживет, но IMHO вот-вот следует ожидать чего-то "нового, революционного, непревзойденного" (по крайней мере по мнению разработчиков).

Да-а-а... Сделали бы демона по switching технологии (без глупых форков). А скрипты бы ему через маленькие интерфейсные модули кормили - класный был бы язык! А если-б ему еще и кэш байт-кода приделать?

>Все они хотят иметь возможность писать в свои
>домашние каталоги из скриптов. Я пробовал suexec.
В случае с PHP в качестве модуля, все решается правильной расстановкой прав.
suexec - обьясни чем он тормозен?

>Соответственно ни о каком модуле при таком раскладе речи не идет, а
>все прелести самого крутого вебсервера всех времен и народов
>растворяются как дым. Зато вылезают все его кривости - огромный
>аппетит на ресурсы при минимуме отдачи.
На хосте с 1GB ОЗУ живет более 300 вирт. хостов.
С разграничением всяких там прав, чтобы никто друг-другу в каталог не залез. Да возможно они похуже твоих нескольких десятков, но их больше.
И что самое интересное почти все ХОТЯТ ПХП, причем во многих случаях они его не используют дальше вставки текущей даты. Или бесплатных форумов(типа PHPBB2),порталов.
И хотят перл, используя только различные бесплатные скрипты под него, типа глючного formmail.
Среди тех 300 есть несколько и более серьезных.
Мускул также довольно сильно юзается.
mod_perl - не использую, т.к. не было требований.

> Сделали бы демона по switching технологии (без глупых форков). А
> скрипты бы ему через маленькие интерфейсные модули
это a-la FastCGI?8) а поподробнее про switching можно?

2roller Можешь сказать с какими опциями компилил Apache? У меня из коробки (FreeBSD) при 20 сапросах в секунду после нескольких часов работы съедает 1.5G памяти и уходит в ступор.

Долго мучался сначала, ибо компилилось на кучу машин сразу(идентичных). Что требовалось - особо никто не говорил. Поэтому в итоге там много лишнего получилось.
Использовал apachetoolbox(1.5.58). Хотья коечто пришлось руками подправить. Сейчас 1.3.26 везде стоит. На 1.3.27 переходить - во первых работать надо как платят, а во вторых когда заикнулся(там много че обновить надо) сказали, подожди скоро на друг. систему перейдем.

export SSL_BASE=/usr/local
export EAPI_MM=/root/install/Apachetoolbox-1.5.58/src/mm-1.1.3
export CFLAGS=""
export LIBS=""
export INCLUDES=""
./configure --with-layout="RedHat" \
--enable-suexec \
--suexec-caller=nobody \
--suexec-docroot=/home/www \
--enable-shared=max \
--enable-module=access \
--enable-module=auth_db \
--disable-module=digest \
--enable-module=imap \
--enable-module=mime \
--enable-module=setenvif \
--disable-module=usertrack \
--enable-module=auth \
--enable-module=cern_meta \
--enable-module=expires \
--enable-module=log_config \
--enable-module=proxy \
--enable-module=vhost_alias \
--disable-module=auth_anon \
--enable-module=cgi \
--enable-module=headers \
--disable-module=log_referer \
--enable-module=rewrite \
--enable-module=userdir \
--enable-module=asis \
--enable-module=autoindex \
--disable-module=example \
--disable-module=log_agent \
--enable-module=negotiation \
--enable-module=status \
--enable-module=actions \
--enable-module=auth_dbm \
--enable-module=dir \
--enable-module=include \
--enable-module=mime_magic \
--enable-module=unique_id \
--enable-module=alias \
--enable-module=auth_digest \
--enable-module=env \
--disable-module=info \
--enable-module=mmap_static \
--enable-module=speling \
--enable-module=ssl \
--activate-module=src/modules/perl/libperl.a \
--add-module=/root/install/Apachetoolbox-1.5.58/src/mod_bandwidth.c \
--add-module=mod_frontpage.c --activate-module=src/modules/dav/libdav.a \
--activate-module=src/modules/fastcgi/libfastcgi.a \
--activate-module=src/modules/php4/libphp4.a \

Насчет памяти. Может поможет MaxRequestsPerChild. Наблюдался такой баг, что не хватало памяти и все дохло. После установки этой директивы и RLimitMEM все ок.

P.S.: не судите строго за выбор модулей, включил почти все что смог, ибо не известно было что дальше потребуют. Реально mod_perl,mod_dav,fastcgi,auth_db, auth_dbm.... не используется, и отключены с конфигов.
P.S.:Frontpage мне тоже не нравится.

а может всех в тюрьму (jail) ? и все работает.

> В случае с PHP в качестве модуля, все решается правильной расстановкой прав.

Например? Разрешать везде запись для юзера, под которым
работает веб-сервер? Спасибо, я еще жить хочу.

> suexec - обьясни чем он тормозен?

Я тесты проводил. Apache+suexec в 2(!) раза медленнее, чем аналогичная встроенная функция, вызываемая из легкого веб-сервера.

> все ХОТЯТ ПХП, причем во многих случаях они его не используют дальше вставки текущей даты.

У меня не так. У всех крутятся серьезные приложения - магазины и информационные системы. У всех больше 10тыс
хитов в сутки. Апач сосет.

А что у тебя не "сосет" не пользуещь? Что исп. в качестве WEB-сервера?

2anonymous (*) (2003-02-21 02:03:33.535)

Это самопальная вещь с частично заимствованным кодом и идеями
из разных мелких веб-верверов.

>> В случае с PHP в качестве модуля, все решается правильной >>расстановкой прав. >Например? Разрешать везде запись для юзера, под которым >работает веб-сервер? Спасибо, я еще жить хочу. на homedir 0550 + група апачевая в homedir каталог www, права 0770 + група апачевая юзеры разумеется в эту группу не входят таким образом юзер не может войти в чужой каталог. а чтобы PHP скрипты не могли юзать чужие каталоги используем safe_mode и open_basedir >> suexec - обьясни чем он тормозен? >Я тесты проводил. Apache+suexec в 2(!) раза медленнее, чем >аналогичная встроенная функция, вызываемая из легкого веб-сервера. А если поискать то можно найти еще более легкий веб-сервер где она будет в 3 раза быстрее апачевой, и в полтора быстрее той, что сейчас ты используешь. >> все ХОТЯТ ПХП, причем во многих случаях они его не используют >дальше вставки текущей даты. >У меня не так. У всех крутятся серьезные приложения - магазины и >информационные системы. У всех больше 10тыс >хитов в сутки. Апач сосет. Апач не сосет. Для каждого дела нужен свой софт. Не устраивает апач - не юзай. Медлителен suexec - перепиши его, только не забудь что он не просто так сделан.

>> В случае с PHP в качестве модуля, все решается правильной
>>расстановкой прав.
>Например? Разрешать везде запись для юзера, под которым
>работает веб-сервер? Спасибо, я еще жить хочу.

на homedir 0550 + група апачевая
в homedir каталог www, права 0770 + група апачевая
юзеры разумеется в эту группу не входят таким образом юзер не может войти в чужой каталог. а чтобы PHP скрипты не могли юзать чужие каталоги используем safe_mode и open_basedir

>> suexec - обьясни чем он тормозен?
>Я тесты проводил. Apache+suexec в 2(!) раза медленнее, чем
>аналогичная встроенная функция, вызываемая из легкого веб-сервера.

А если поискать то можно найти еще более легкий веб-сервер где она будет в 3 раза быстрее апачевой, и в полтора быстрее той, что сейчас ты используешь.

>> все ХОТЯТ ПХП, причем во многих случаях они его не используют
>>дальше вставки текущей даты.
>У меня не так. У всех крутятся серьезные приложения - магазины и
>информационные системы. У всех больше 10тыс
>хитов в сутки. Апач сосет.
Апач не сосет. Для каждого дела нужен свой софт. Не устраивает апач - не юзай. Медлителен suexec - перепиши его, только не забудь что он не просто так сделан.

> на homedir 0550 + група апачевая
> в homedir каталог www, права 0770 + група апачевая

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

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

The PHP safe mode is an _attempt_ to _solve_ the shared-server
security problem. It is architecturally _incorrect_ to try to
solve this problem at the PHP level, but since the alternatives
at the web server and OS levels aren't very realistic, many
people, especially ISP's, use safe mode for now.

Просто подумай, что если кроме php требуется perl/cgi?
А у меня половина юзеров имеет еще и shell. Все понятно?

> А если поискать то можно найти еще более легкий веб-сервер

Ну и? Что хотел сказать этим? Если найду, конечно поставлю.

> Апач не сосет. Для каждого дела нужен свой софт.

Перефразирую: Апач сосет в данном деле (профессиональный хостинг). А так же в другом деле (непрофессиональный хостинг). И для индивидуального пользования тоже сосет.
А так же... извини, не оталось мест, где он не сосет ;)

>> на homedir 0550 + група апачевая
>> в homedir каталог www, права 0770 + група апачевая

>Э, нет, дорогой. Уж лучше сразу отдать ключи от квартиры, где деньги >лежат. Извини, но ты ничего не понимаешь в безопасности.
Точно.
Я исче только учусь, и не отрицаю этого.
У меня еще вся жизнь впереди.

>Для левого вшивого хостинга это с трудом еще подходит, при
>условии, что никто ни за что не отвечает и никакой материальной
>ответственности не несет.
несет.

> Ведь даже в мануале про safe_mode в
>самом начале черным по экрану тебя честно предупреждают: ....

В половине пакетов которые у тебя установлены есть аналогичные надписи. Просто надо пользоватся фичей до тех пор, пока не будет доказанно что она не работает. А после этого надо обновится :)

>Просто подумай, что если кроме php требуется perl/cgi?
>А у меня половина юзеров имеет еще и shell. Все понятно?
А в чем проблема то?
Прочитай внимательней.
Юзер не может войти в чужой каталог.
CGI программа не может залезть в чужой каталог.
PHP скрипт может писать только на файлы внутри каталогы юзера, если на эти файлы есть соответственные права.


>?Ну и? Что хотел сказать этим? Если найду, конечно поставлю.
Именно.
А завтра исче раз.
А послезавтра...
А потом обнаруживается что в гонке за чем-то мифическим у тебя сдохла система.


>Перефразирую: Апач сосет в данном деле (профессиональный хостинг). А
> так же в другом деле (непрофессиональный хостинг). И для
>индивидуального пользования тоже сосет.

http://www.netcraft.com/survey/
http://uptime.netcraft.net/up/today/requested.html
http://uptime.netcraft.com/up/today/top.avg.html
Сколько там идиотов. Надо им срочно всем письма написать, чтобы на thttpd переходили, или лучше еще свое произведение им предложи.

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

>А так же... извини, не оталось мест, где он не сосет ;)

точно. не осталось. ты его так раком поставил, что он у всех отсосал.

~s/круче/иное то/

> А в чем проблема то?

Мне неудобно объяснять очевидные вещи. Подумай сам на досуге.

> Сколько там идиотов.

Могу тебя заверить, что идиотов намного больше, чем ты себе представляешь.

> Надо им срочно всем письма написать, чтобы на thttpd переходили,

О нет, таких советов лично я не давал.

> Пользователь в большинстве случаев хочет IIS либо апач.

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

Тупик.
Все козлы.
Я один умный.
Все сосут.

Дык.

> Просто подумай, что если кроме php требуется perl/cgi? > А у меня половина юзеров имеет еще и shell. Все понятно? а про chroot Вы никогда не слышали? что надо? cgi-wrapper (e.g. sbox), chroot-patch для sshd/ftpd, safe_mode - php.

> Просто подумай, что если кроме php требуется perl/cgi?
> А у меня половина юзеров имеет еще и shell. Все понятно?
а про chroot Вы никогда не слышали?
что надо? cgi-wrapper (e.g. sbox), chroot-patch для sshd/ftpd, safe_mode - php.

реально проблема только с cron (пока проблема).