Вот довольно давно отрыл вот такую вот весьма извращенную вещь: KLone: каркас для web-программирования на языке C.
Может кому пригодится, у самого пока руки не дошли попробовать.
FastNetMon
Monday, 23 June 2008
Sunday, 22 June 2008
Списочек легких HTTPD
Вот списочком:
Сам пока не придумал, для чего их можно использовать... но вот последний умеет CGI, так что можно какую-нить админку на нём довольно легко налабать :)
Сам пока не придумал, для чего их можно использовать... но вот последний умеет CGI, так что можно какую-нить админку на нём довольно легко налабать :)
Friday, 13 June 2008
Пара интересных веб сайтов -- хостинг на Nginx и rss2email
Сегодняшний день оказался довольно плодотворным по части поиска интересных сайтов.
Первый из них вот этот -- http://hosting.dekoda.net/index.html, как я понял из рекламных текстов, они занимаются хостингом на Nginx + MySQL + PHP (через PHP-FPM /* http://php-fpm.anight.org/about.html */ ) + Perl, первые три пункта у меня вопросов не вызвали, танцами и бубнами их можно заставить работать вместе... ну а Перл-то как они прикрутили? Обычный Перл как CGI прикрутить к Нджинксу без бэкэнда можно сказать нереально, остаётся единственный вариант -- подключение его как FastCGI, но тут вылазит куча проблем да и, вообще говоря, данная связка будет потреблять море ресурсов, что в конце-концов приведет к тому, что кто-нибудь из клиентов поест все ресурсы. Хотя с другой стороны предполагаю, что Перл написан на сайте ошибочно, но ради восстановления справедливости все же напишу в техподдержку как заинтересованный клиент :)
Второй сайт -- http://www.rss2email.ru/ представляет из себя типичный (никогда бы не подумал, что так скажу) WEB 2.0 проект. По сути в нём ничего необычного и выделяющегося нету -- просто сайт, где можно заказать перенаправление rss фидов на электронную почту. Но с другой стороны их "интерфейс настройки" ( http://www.rss2email.ru/ ) с моей точки зрения представляет собой идеал интерфейсостроения, ибо там лишь два поля, одно из них адрес -- rss фида, второе -- электронная почта, на которую слать его. Никаких тупых регистраций, никаких CAPTCHA, никаких лицензионных соглашений и прочих гадостей, одно слово -- идеал!
Ну вот, пожалуй, хватит на сегодня о сайтах, что нового найду -- обязательно напишу :)
А в ближайшее время постараюсь расковырять и найти применение встроенному в Нджинкс Перлу (да что интриговать, я его уже нашел -- озвученная в предыдущем посте централизованная авторизация) и попутно выложить аннотации к моим новым модулям на CPAN.
Первый из них вот этот -- http://hosting.dekoda.net/index.html, как я понял из рекламных текстов, они занимаются хостингом на Nginx + MySQL + PHP (через PHP-FPM /* http://php-fpm.anight.org/about.html */ ) + Perl, первые три пункта у меня вопросов не вызвали, танцами и бубнами их можно заставить работать вместе... ну а Перл-то как они прикрутили? Обычный Перл как CGI прикрутить к Нджинксу без бэкэнда можно сказать нереально, остаётся единственный вариант -- подключение его как FastCGI, но тут вылазит куча проблем да и, вообще говоря, данная связка будет потреблять море ресурсов, что в конце-концов приведет к тому, что кто-нибудь из клиентов поест все ресурсы. Хотя с другой стороны предполагаю, что Перл написан на сайте ошибочно, но ради восстановления справедливости все же напишу в техподдержку как заинтересованный клиент :)
Второй сайт -- http://www.rss2email.ru/ представляет из себя типичный (никогда бы не подумал, что так скажу) WEB 2.0 проект. По сути в нём ничего необычного и выделяющегося нету -- просто сайт, где можно заказать перенаправление rss фидов на электронную почту. Но с другой стороны их "интерфейс настройки" ( http://www.rss2email.ru/ ) с моей точки зрения представляет собой идеал интерфейсостроения, ибо там лишь два поля, одно из них адрес -- rss фида, второе -- электронная почта, на которую слать его. Никаких тупых регистраций, никаких CAPTCHA, никаких лицензионных соглашений и прочих гадостей, одно слово -- идеал!
Ну вот, пожалуй, хватит на сегодня о сайтах, что нового найду -- обязательно напишу :)
А в ближайшее время постараюсь расковырять и найти применение встроенному в Нджинкс Перлу (да что интриговать, я его уже нашел -- озвученная в предыдущем посте централизованная авторизация) и попутно выложить аннотации к моим новым модулям на CPAN.
Nginx + HTTP Basic Authentication
Ну тема довольно простая и почти полностью описана в документации (http://sysoev.ru/nginx/docs/http/ngx_http_auth_basic_module.html), но все же опишу некоторые моменты.
Для начала открываем файл nginx.conf и ищем там следующие строки:
И заменяем их на следующее:
Рестартанув Нджинкс, можно увидеть, что при открытии сайта выскакивает окошечко требующее авторизацию. Теперь нам нужно создать файл с логинами и паролями пользователей, имеющих доступ к данной страничке.
Файл паролей положим в папку conf -- conf/htpasswd, его формат таков:
"-b" -- указываем считывание имени файла с паролями с командной строки
"-c" -- указываем создать новый файл
htpasswd -- имя вновь создаваемого файла
nrg -- имя добавляемого туда пользователя
12345 -- пароль пользователя
В итоге получаем файлик следующего содержания:
Хм, а вот интересно, можно ли подружить Nginx c PAM или LDAP? А-то держать полтора десятка баз пользователей никакого удовольствия, а так можно было бы все сложить в одну базу. Если у кого есть мысли на этот счет, буду благодарен, если оставите их в комментах (:
Для начала открываем файл nginx.conf и ищем там следующие строки:
location / { root html; index index.html index.htm; }
И заменяем их на следующее:
location / {
auth_basic "closed site";
auth_basic_user_file htpasswd;
root html;
index index.html index.htm;
}Рестартанув Нджинкс, можно увидеть, что при открытии сайта выскакивает окошечко требующее авторизацию. Теперь нам нужно создать файл с логинами и паролями пользователей, имеющих доступ к данной страничке.
Файл паролей положим в папку conf -- conf/htpasswd, его формат таков:
# комментарийПароли генерируются функцией crypt, также для их создания можно воспользоваться утилитой от веб сервера Apache -- htpasswd, ей мы и воспользуемся.
имя1:пароль1
имя2:пароль2:комментарий
имя3:пароль3
sudo htpasswd -cbd htpasswd nrg 12345"-d" -- выбираем криптофункцию "crypt"
"-b" -- указываем считывание имени файла с паролями с командной строки
"-c" -- указываем создать новый файл
htpasswd -- имя вновь создаваемого файла
nrg -- имя добавляемого туда пользователя
12345 -- пароль пользователя
В итоге получаем файлик следующего содержания:
nrg:G8XDed1YWlwlMИ рестартим Нджинкс, после этого при попытке открыть главную страницу сайта должна выскакивать страница авторизации :)
Хм, а вот интересно, можно ли подружить Nginx c PAM или LDAP? А-то держать полтора десятка баз пользователей никакого удовольствия, а так можно было бы все сложить в одну базу. Если у кого есть мысли на этот счет, буду благодарен, если оставите их в комментах (:
Установка nginx из исходников
Вот после долгого затишья я снова тружусь на благо телекома :)
Сегодня мы будем заниматься легким веб сервером nginx (http://sysoev.ru), который мне понадобился для раздачи небольшого количества статики.
Сама установка выглядит довольно тривиально: сливаем дистрибутив 0.6й ветки вот отсюда: http://sysoev.ru/nginx/download.html и ставим тривиальным набором команд :
Довольно стандартная схема без всяких сложностей... ну разве configure скрипт попросит вас поставить zlib и pcre, но относить это к сложностям как-то несерьёзно :) Как Вы могли заметить, мы ставим nginx не в саму систему, а в папку /opt/nginx, так как захламлять рабочую систему кучей хлама у меня лично нету никакого настроения.
Ну а теперь стоит вопрос, как нам все это дело удобно использовать (ну не каждый же день руками делать /opt/nginx/sbin/nginx), а в связи с тем, что в поставке nginx я не обнаружил готового скрипта для init.d, то нам придётся его писать или найти готовый (полагаю, второй вариант намного предпочтительнее) :)
Конечно же, я нашел готовый и его немного модифицировал, оригинал же взят отсюда: http://ssh3.livejournal.com/29252.html?thread=32836 , за что большое спасибо автору.
Скрипт управления сервером nginx:
Теперь остаётся добавить скрипт в систему и все заработает,
как это сделать я описывать отдельно не буду, ssh3 отлично описал этот пункт,
поэтому позволю себе немного плагиата :)
Для автоматического страрта при загрузке системы достаточно скопировать
стартовый скрипт nginx в каталог /etc/init.d и выполнить следующие
команды:
#chkconfig --add nginx
#chkconfig --level 345 nginx on
Проверить статус можно командой:
#chkconfig --list | grep nginx
nginx 0:off 1:off 2:off 3:on 4:on 5:on 6:off
Ну вот, вроде, и все, в идеале, конечно, из этого стоило бы собрать deb / rpm пэкадж, но это уже дело каждого.
Сегодня мы будем заниматься легким веб сервером nginx (http://sysoev.ru), который мне понадобился для раздачи небольшого количества статики.
Сама установка выглядит довольно тривиально: сливаем дистрибутив 0.6й ветки вот отсюда: http://sysoev.ru/nginx/download.html и ставим тривиальным набором команд :
mkdir -p ~/nginx
cd ~/nginx
wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz
tar -xf nginx*
cd nginx*
./configure --prefix=/opt/nginx
make
sudo make install
Довольно стандартная схема без всяких сложностей... ну разве configure скрипт попросит вас поставить zlib и pcre, но относить это к сложностям как-то несерьёзно :) Как Вы могли заметить, мы ставим nginx не в саму систему, а в папку /opt/nginx, так как захламлять рабочую систему кучей хлама у меня лично нету никакого настроения.
Ну а теперь стоит вопрос, как нам все это дело удобно использовать (ну не каждый же день руками делать /opt/nginx/sbin/nginx), а в связи с тем, что в поставке nginx я не обнаружил готового скрипта для init.d, то нам придётся его писать или найти готовый (полагаю, второй вариант намного предпочтительнее) :)
Конечно же, я нашел готовый и его немного модифицировал, оригинал же взят отсюда: http://ssh3.livejournal.com/29252.html?thread=32836 , за что большое спасибо автору.
Скрипт управления сервером nginx:
#!/bin/bash # v.0.0.3 # nginx - This shell script takes care of starting and stopping nginx. # chkconfig: 345 20 80 # author site: nginx.net, sysoev.ru # description: nginx [engine x] is light http web/proxy server # that answers incoming ftp service requests. # processname: nginx # config: /opt/nginx/conf/nginx.conf # # Исходная версия: http://ssh3.livejournal.com/29252.html?thread=32836 # Изменённая версия: nrg [ at ] cpan [ dot ] org ( http://phpsuxx.blogspot.com/ ) # # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 RETVAL=0 NGINX=/opt/nginx CONFIG=$NGINX/conf/nginx.conf EXEC=$NGINX/sbin/nginx PID=$NGINX/logs/nginx.pid PROG=nginx [ -x $EXEC ] || exit 0 start() { echo -n $"Starting NGINX: " # Start daemons. if [ -e $CONFIG ] ; then $EXEC -t -c $CONFIG 2> /dev/null [ $? -eq 0 ] && $EXEC -c $CONFIG & RETVAL=$? else RETVAL=1 fi if [ $RETVAL -eq 0 ] ; then echo_success else echo_failure fi echo return $RETVAL } stop() { # Stop daemons. if [ -e $PID ] ; then echo -n "Shutting down $PROG: " kill -QUIT `cat $PID` RETVAL=$? else echo -n "Nginx not runned." RETVAL=1 fi if [ $RETVAL -eq 0 ] ; then echo_success else echo_failure fi echo return $RETVAL } restart() { # Reload daemons. if [ -e $PID ] ; then echo -n "Reload $PROG: " kill -HUP `cat $PID` RETVAL=$? else echo -n "Nginx not runned." RETVAL=1 fi if [ $RETVAL -eq 0 ] ; then echo_success else echo_failure fi echo return $RETVAL } # See how we were called. case "$1" in start) start ;; stop) stop ;; restart) restart ;; reconfigure) restart ;; status) status $NAME RETVAL=$? ;; *) echo $"Usage: $0 {start|stop|restart|reconfigure|status}" exit 1 esac exit $RETVAL
Теперь остаётся добавить скрипт в систему и все заработает,
как это сделать я описывать отдельно не буду, ssh3 отлично описал этот пункт,
поэтому позволю себе немного плагиата :)
Для автоматического страрта при загрузке системы достаточно скопировать
стартовый скрипт nginx в каталог /etc/init.d и выполнить следующие
команды:
#chkconfig --add nginx
#chkconfig --level 345 nginx on
Проверить статус можно командой:
#chkconfig --list | grep nginx
nginx 0:off 1:off 2:off 3:on 4:on 5:on 6:off
Ну вот, вроде, и все, в идеале, конечно, из этого стоило бы собрать deb / rpm пэкадж, но это уже дело каждого.
Saturday, 3 May 2008
Подсветка синтаксиса VIM
В один прекрасный момент осознал, что стандартная подсветка синтаксиса (с белым фоном! о ужас!) в моём любимом vim'е меня категорически не устраивает и хочется чего-то чёрного и более приятного для глаз.
Ну что же, недолго побродив по vim.org я нашёл целую кучу цветовых схем, вот наиболее понравившаяся мне wombat
Ссылочка на скачку: http://www.vim.org/scripts/script.php?script_id=1778
Теперь будем перекрашивать гном :)
Вот и Гном перекрашен вот в это: http://gnome-look.org/content/show.php/Murrina-Black?content=46287
А для полного счастья вот и css для моей любимой пастилки http://php.suxx.us/s/paste.org.ru.css :)
ПЫСЫ: тырнет свёл на нет все преимущества тёмного стиля, т.к. постоянное чередование сайтов с белым и чёрным фонами очень сильно убивает зрение, в итоге поставлено было вот это.
Ну что же, недолго побродив по vim.org я нашёл целую кучу цветовых схем, вот наиболее понравившаяся мне wombat
Ссылочка на скачку: http://www.vim.org/scripts/script.php?script_id=1778
Теперь будем перекрашивать гном :)
Вот и Гном перекрашен вот в это: http://gnome-look.org/content/show.php/Murrina-Black?content=46287
А для полного счастья вот и css для моей любимой пастилки http://php.suxx.us/s/paste.org.ru.css :)
ПЫСЫ: тырнет свёл на нет все преимущества тёмного стиля, т.к. постоянное чередование сайтов с белым и чёрным фонами очень сильно убивает зрение, в итоге поставлено было вот это.
Sunday, 27 April 2008
Автодополнение в Bash
Довольно часто при тестировании и отладке приходится рестартить апача для рекомпиляции приложения на mod_perl (тому, кто скажет, как от этого избавится или делать без рестарта Апача, буду несказанно благодарен), для чего приходилось использовать либо su, либо sudo.
Сегодня после небольшого ликбеза по sudo перелез на него с su. Но тут незадача -- если набивать sudo apache2ct<ТАБ>, то автодополнение НЕ сработает и придётся набивать название команды ручками, что жутко нервирует, когда кол-во таких "набивов" приближается к сотне за день.
Решений как всегда в линуксе несколько:
1) Прописать в ~/.bashrc
2) Либо поступить более кОмплексно и поставить пакет bash-completion, который к указанной фиче предоставит ещё ряд вкусностей, про которые можете прочитать на http://www.debian-administration.org/articles/316
Попутно мне понадобилось внести коррективы в переменную среды PATH, т.к. в моей Сусе по соображениям безопасности в PATH для простых юзеров не включаются директории бинариков */sbin.
Фиксится это одной строкой в указанно ~/.bash_rc:
Первая идея была взята с: ссылко
Сегодня после небольшого ликбеза по sudo перелез на него с su. Но тут незадача -- если набивать sudo apache2ct<ТАБ>, то автодополнение НЕ сработает и придётся набивать название команды ручками, что жутко нервирует, когда кол-во таких "набивов" приближается к сотне за день.
Решений как всегда в линуксе несколько:
1) Прописать в ~/.bashrc
# включаем автодополнение для sudo
complete -cf sudo
2) Либо поступить более кОмплексно и поставить пакет bash-completion, который к указанной фиче предоставит ещё ряд вкусностей, про которые можете прочитать на http://www.debian-administration.org/articles/316
Попутно мне понадобилось внести коррективы в переменную среды PATH, т.к. в моей Сусе по соображениям безопасности в PATH для простых юзеров не включаются директории бинариков */sbin.
Фиксится это одной строкой в указанно ~/.bash_rc:
# добавим sbin в юзерский патч
PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH
Первая идея была взята с: ссылко
Saturday, 19 April 2008
Скачиваем видео с Youtybe посредством wget, sed и linux :)
Вот решил скачать для локального использования давно полюбившийся мне клип группы Леон "Метро 2033".
Искать "ещё один супер пупер качальщик с Ютуба" категорически не хотелось, поэтому довольно быстро было найдено решение, прямо-таки по Unix-way, а именно скрипт на Shell, который скачивает flv и ложит в текущую папку его :)
Скрипт вот:
Взято: http://linux.byexamples.com/archives/302/how-to-wget-flv-from-youtube/#comment-18455
После того, как был слит клип в flv ещё и оказалось, что он отлично играется моим любимым плеером vlc :)
Искать "ещё один супер пупер качальщик с Ютуба" категорически не хотелось, поэтому довольно быстро было найдено решение, прямо-таки по Unix-way, а именно скрипт на Shell, который скачивает flv и ложит в текущую папку его :)
Скрипт вот:
RAW=`wget -O - $1 | grep 'fullscreenUrl' | sed 's/^.*video_id=//'`
TITLE=`echo $RAW | sed 's/^.*title=//' | sed 's/[^a-zA-Z0-9]//g'`
ID=`echo $RAW |sed 's/&fs.*$//'`
wget -O $TITLE.flv "http://www.youtube.com/get_video.php?hl=en&video_id=$ID"
Взято: http://linux.byexamples.com/archives/302/how-to-wget-flv-from-youtube/#comment-18455
После того, как был слит клип в flv ещё и оказалось, что он отлично играется моим любимым плеером vlc :)
Thursday, 17 January 2008
Решение проблемы с Apache2::ModSSL OpenSuse 10.3
При установке данного модуля высыпается несколько проблем -- первая из них, идёт много ругани на отсутствие mod_perl.h, но если путь с этим файликом жёстко прописать в Makefile.PL (который был предварительно сгенерирован посредством perl Makefile.PL, все файлы лежат по пути ~/.cpan/build/Apache2-ModSSL-0.03-некоторые_символы):
То высыпется ещё целая прорва ошибок сборки, которая решается прописыванием путей к заголовочным файлам библиотеки apr:
Ну и конечно же, devel версии пакетов Apache2 и mod_perl должны стоят в системе :)
INC = -I/usr/include/apache2 -I/usr/include/apache2/modules/perl
То высыпется ещё целая прорва ошибок сборки, которая решается прописыванием путей к заголовочным файлам библиотеки apr:
INC = -I/usr/include/apache2 -I/usr/include/apache2/modules/perl -I/usr/include/apr-1
Ну и конечно же, devel версии пакетов Apache2 и mod_perl должны стоят в системе :)
Wednesday, 16 January 2008
Немного о CPAN
Как удалить модуль с хранилища модулей (локального, конечно же) CPAN?
В общем случае никак (?), но бывают исключения. В конфигурационном файле CPAN (/usr/lib/perl5/5.8.8/CPAN/Config.pm) есть переменная ('build_dir'), отвечающая за расположение папки для временного хранения модулей перед установкой. Как можно понять, в этой папке хранятся инсталяцонные файлы модулей, которые представляют из себя стандартный комплект -- Makefile.PL / Build.pl и обычно уже созданный Makefile (т.к. данные модули уже были установлены Вами), который и устанавливает модуль в хранилище. А у Данного Make файла присутствует цель uninstall, т.е. можно выполнить make uninstall и либо удалить модуль сразу, либо получить рекомендации для удаления.
Но, к несчастью, данный метод не универсальный, но почти во всех случаях, когда мне было необходимо по тем или иным причинам удалить модуль, он срабатывал :)
Конфигурирование CPAN.
CPAN при запуске очень любит доставать вопросами о конфигурации. Чтобы отучить его заниматься сим противным занятием давайте напрямую отредактируем конфиг файл /usr/lib/perl5/5.8.8/CPAN/Config.pm
(его расположение меняется от дистрибутива к дистрибутиву, так что если что проявите смекалку и отыщите его). Ниже привожу свой конфиг файл.
# This is CPAN.pm's systemwide configuration file. This file provides
# defaults for users, and the values can be changed in a per-user
# configuration file. The user-config file is being looked for as
# ~/.cpan/CPAN/MyConfig.pm.
$CPAN::Config = {
'build_cache' => q[100],
'build_dir' => q[/home/nrg/.cpan/build],
'cache_metadata' => q[1],
'cpan_home' => q[/home/nrg/.cpan],
'cpan_version_check' => q[1],
'dontload_hash' => { },
'ftp' => q[/usr/bin/ftp],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[/usr/bin/gpg],
'gzip' => q[/bin/gzip],
'histfile' => q[/home/nrg/.cpan/histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[/home/nrg/.cpan/sources],
'lynx' => q[],
'make' => q[/usr/bin/make],
'make_arg' => q[],
'make_install_arg' => q[],
'makepl_arg' => q[INSTALLDIRS=site],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[/usr/bin/less],
'prerequisites_policy' => q[follow],
'scan_cache' => q[atstart],
'shell' => q[/bin/bash],
'tar' => q[/bin/tar],
'term_is_latin' => q[1],
'unzip' => q[/usr/bin/unzip],
'urllist' => [q[ftp://cpan.makeperl.org/pub/CPAN], q[ftp://cpan.nx1.ru/], q[ftp://cpan.rinet.ru/pub/mirror/CPAN/], q[ftp://ftp.aha.ru/CPAN/], q[ftp://ftp.chg.ru/pub/lang/perl/CPAN/], q[ftp://ftp.spbu.ru/CPAN/], q[http://ftp.silvernet.ru/CPAN/], q[http://mirror.rol.ru/CPAN/]],
'wget' => q[/usr/bin/wget],
};
1;
__END__
Вот примерно такой вид должен иметь наш конфиг файл, но в случае проблем при его использовании придётся переконфигурировать Цпан вручную, это делается довольно просто -- удаляем указанный конфиг файл Цпана и запускаем сам cpan :)
А вот для пользователей убунту данный конфиг стоит искать по адресу: /etc/perl/CPAN/Config.pm
Как бороться с ошибками вида: "Has already been unwrapped into directory /root/.cpan/build/ИМЯ_модуля-некая_уникальная_последовательность" ?
Такое бывает, когда сваливаются тесты модуля или Вы любите поэксперементировать с Цпаном. Это решается в лоб: rm -r /root/.cpan/build/ИМЯ_модуля-*
В общем случае никак (?), но бывают исключения. В конфигурационном файле CPAN (/usr/lib/perl5/5.8.8/CPAN/Config.pm) есть переменная ('build_dir'), отвечающая за расположение папки для временного хранения модулей перед установкой. Как можно понять, в этой папке хранятся инсталяцонные файлы модулей, которые представляют из себя стандартный комплект -- Makefile.PL / Build.pl и обычно уже созданный Makefile (т.к. данные модули уже были установлены Вами), который и устанавливает модуль в хранилище. А у Данного Make файла присутствует цель uninstall, т.е. можно выполнить make uninstall и либо удалить модуль сразу, либо получить рекомендации для удаления.
Но, к несчастью, данный метод не универсальный, но почти во всех случаях, когда мне было необходимо по тем или иным причинам удалить модуль, он срабатывал :)
Конфигурирование CPAN.
CPAN при запуске очень любит доставать вопросами о конфигурации. Чтобы отучить его заниматься сим противным занятием давайте напрямую отредактируем конфиг файл /usr/lib/perl5/5.8.8/CPAN/Config.pm
(его расположение меняется от дистрибутива к дистрибутиву, так что если что проявите смекалку и отыщите его). Ниже привожу свой конфиг файл.
# This is CPAN.pm's systemwide configuration file. This file provides
# defaults for users, and the values can be changed in a per-user
# configuration file. The user-config file is being looked for as
# ~/.cpan/CPAN/MyConfig.pm.
$CPAN::Config = {
'build_cache' => q[100],
'build_dir' => q[/home/nrg/.cpan/build],
'cache_metadata' => q[1],
'cpan_home' => q[/home/nrg/.cpan],
'cpan_version_check' => q[1],
'dontload_hash' => { },
'ftp' => q[/usr/bin/ftp],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[/usr/bin/gpg],
'gzip' => q[/bin/gzip],
'histfile' => q[/home/nrg/.cpan/histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[/home/nrg/.cpan/sources],
'lynx' => q[],
'make' => q[/usr/bin/make],
'make_arg' => q[],
'make_install_arg' => q[],
'makepl_arg' => q[INSTALLDIRS=site],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[/usr/bin/less],
'prerequisites_policy' => q[follow],
'scan_cache' => q[atstart],
'shell' => q[/bin/bash],
'tar' => q[/bin/tar],
'term_is_latin' => q[1],
'unzip' => q[/usr/bin/unzip],
'urllist' => [q[ftp://cpan.makeperl.org/pub/CPAN], q[ftp://cpan.nx1.ru/], q[ftp://cpan.rinet.ru/pub/mirror/CPAN/], q[ftp://ftp.aha.ru/CPAN/], q[ftp://ftp.chg.ru/pub/lang/perl/CPAN/], q[ftp://ftp.spbu.ru/CPAN/], q[http://ftp.silvernet.ru/CPAN/], q[http://mirror.rol.ru/CPAN/]],
'wget' => q[/usr/bin/wget],
};
1;
__END__
Вот примерно такой вид должен иметь наш конфиг файл, но в случае проблем при его использовании придётся переконфигурировать Цпан вручную, это делается довольно просто -- удаляем указанный конфиг файл Цпана и запускаем сам cpan :)
А вот для пользователей убунту данный конфиг стоит искать по адресу: /etc/perl/CPAN/Config.pm
Как бороться с ошибками вида: "Has already been unwrapped into directory /root/.cpan/build/ИМЯ_модуля-некая_уникальная_последовательность" ?
Такое бывает, когда сваливаются тесты модуля или Вы любите поэксперементировать с Цпаном. Это решается в лоб: rm -r /root/.cpan/build/ИМЯ_модуля-*
Monday, 14 January 2008
Новое в Перл 5.12 и немного о my и local
В то время, как весь мир судачит о грядущем Перл6, разработчики 5го Перла прикручивают очень вкусные фишки к языку, вот ссылочка с примерным списком нововведений.
Вот уже третий день усиленно вычитываю статьи на opennet.ru, вот сегодня наткнулся на очень хорошее описание разницы (хотя не совсем разницы, скорее указываются тонкости применения каждого из них) между my и local в Перл5, а вот и ссылка.
Вот уже третий день усиленно вычитываю статьи на opennet.ru, вот сегодня наткнулся на очень хорошее описание разницы (хотя не совсем разницы, скорее указываются тонкости применения каждого из них) между my и local в Перл5, а вот и ссылка.
Sunday, 13 January 2008
MVC Catalyst + Apache2 mod_perl
Ах, кто к нам такой пришёл ?) А пациентом у нас сегодня будет Perl приложение (простите, но скриптом уже язык не поворачивается называть) на очень прогрессивном MVC фреймворке Catalyst... стоп, а что за Каталист-то? А вот, пожалуйста статья.
По ссылке довольно хорошее введение в предмет, так что не думаю, что возникнет много вопросов. В этой же статье описывается создание простейшего (но вот "простоту" своего нового Стартапа определяете сами :) приложения на данной платформе, у меня оно будет расположено по следующему пути: /home/nrg/dev/my_catalyst_app/lib, так что все последующие конфиги будут идти с учётом оного.
А вот по данной ссылке можно наблюдать описание процесса настройки mod_perl2 для исполнения Каталист приложений. Открываем конфиг файл /etc/apache2/conf.d/mod_perl.conf и внутри тегов <IfModule mod_perl.c> и </IfModule> после всех остальных записей добавляем следующее:
Строчка с PerlSwitches указывает веб серверу путь, по которому искать наш обработчик событий для mod_perl (им и будет наше приложение), директива "PerlModule my_catalyst_app" указывает о том, что компиляция нашего проекта будет проведена сразу после запуска Апача, а о назначении остальных строк, думаю, можно догадаться самим, там всё предельно просто - указываем тип обработчика и выбираем наше приложение обработчиком.
После данных манипуляция, перезапускаем Апача - service apache2 restart и смотрим tail -n20 /var/log/apache2/error_log, если там присутствует ошибка Can't locate Catalyst/Engine/Apache2/MP20.pm in @INC, то от имени суперпользователя root устанавливаем недостающий модуль: cpan Catalyst::Engine::Apache2::MP20
Ну вот, пожалуй, и всё, снова перезапускаем сервер и открываем страницу http://127.0.0.1/cat, где видим красивый лейбл Каталиста :)
Добавление от 24 июня.
Вот приобрел хостинг на Дебияне, нашел более удобный способ конфигурирования -- добавить все настройки в отдельный файл /etc/apache2/mods-available/perl.load (который создан ранее).
В итоге у меня получился вот такой небольшой конфиг для Каталиста на отдельном домене:
По ссылке довольно хорошее введение в предмет, так что не думаю, что возникнет много вопросов. В этой же статье описывается создание простейшего (но вот "простоту" своего нового Стартапа определяете сами :) приложения на данной платформе, у меня оно будет расположено по следующему пути: /home/nrg/dev/my_catalyst_app/lib, так что все последующие конфиги будут идти с учётом оного.
А вот по данной ссылке можно наблюдать описание процесса настройки mod_perl2 для исполнения Каталист приложений. Открываем конфиг файл /etc/apache2/conf.d/mod_perl.conf и внутри тегов <IfModule mod_perl.c> и </IfModule> после всех остальных записей добавляем следующее:
PerlSwitches -I/home/nrg/dev/my_catalyst_app/lib
PerlModule my_catalyst_app
<Location /cat>
SetHandler perl-script
PerlResponseHandler my_catalyst_app
</Location>
Строчка с PerlSwitches указывает веб серверу путь, по которому искать наш обработчик событий для mod_perl (им и будет наше приложение), директива "PerlModule my_catalyst_app" указывает о том, что компиляция нашего проекта будет проведена сразу после запуска Апача, а о назначении остальных строк, думаю, можно догадаться самим, там всё предельно просто - указываем тип обработчика и выбираем наше приложение обработчиком.
После данных манипуляция, перезапускаем Апача - service apache2 restart и смотрим tail -n20 /var/log/apache2/error_log, если там присутствует ошибка Can't locate Catalyst/Engine/Apache2/MP20.pm in @INC, то от имени суперпользователя root устанавливаем недостающий модуль: cpan Catalyst::Engine::Apache2::MP20
Ну вот, пожалуй, и всё, снова перезапускаем сервер и открываем страницу http://127.0.0.1/cat, где видим красивый лейбл Каталиста :)
Добавление от 24 июня.
Вот приобрел хостинг на Дебияне, нашел более удобный способ конфигурирования -- добавить все настройки в отдельный файл /etc/apache2/mods-available/perl.load (который создан ранее).
В итоге у меня получился вот такой небольшой конфиг для Каталиста на отдельном домене:
LoadModule perl_module /usr/lib/apache2/modules/mod_perl.so
PerlSwitches -I/home/nrg/MyApp/lib
<VirtualHost 72.4.76.1:80>
ServerName www.goosync.ru
ServerAlias host.ru *.host.ru
<IfModule mod_perl.c>
PerlModule MyApp
SetHandler perl-script
PerlResponseHandler MyApp
</IfModule>
</VirtualHost>
Saturday, 12 January 2008
Циклические ссылки и сборщик мусора в Perl (perl trash garbage)
Я, конечно, понимаю, что из-за одной ссылки делать целый пост аморально, но статья очень хорошая и для разработчика под mod_perl и FastCGI относится к разряду MUST READ, ссылка в студию: http://www.opennet.ru/base/dev/perl_destruction.txt.html
Apache2 MPM Worker + mod_perl2 на OpenSuse 10.3
В установке данной связки ничего сильно сложного нету, но тем не менее на некоторые моменты стоит обратить внимание. Для начала ставим пакеты apache2, apache2-worker, apache2-utils, apache2-mod_perl и apache2-example-pages через Yast2 или вручную, это уже зависит от Ваших предпочтений. В заголовке статьи я специально сделал акцент на то, что настройка именно для Опенсусе, т.к. некоторые моменты при конфигурировании могут отличаться от дистрибутива к дистрибутиву. Все рассуждения и выводы будут основаны на данной статье.
После того, как всё было успешно (а я ,надеюсь, это так и будет) установлено переходим к настройке. Для начала запустим Апач командой service apache2 start, после этого будет выведено: Starting httpd2 (worker) done, это означает, что запуск веб сервера Apache2 c MPM Worker выполнен успешно.
Далее нам необходимо просмотреть список модулей, которые загружаются сервером, для этого можно воспользоваться командой: apache2ctl -t -D DUMP_MODULES, как можно видеть, там нету perl_module (именно так зовётся модуль mod_perl), поэтому нам нужно сообщить серверу о том, что мы хотим использовать именно его. Список модулей, загружаемых Apache2, хранится в файле /etc/apache2/sysconfig.d/loadmodule.conf, но его особенность в том, что все изменения в нём живут до перезапуска сервера, т.к. в это время конфиг файл затирается и приводится в первоначальную форму. Как можно понять, добавлять в этот конфиг mod_perl2 бесполезно, но куда же его прописывать? Некоторое время поломав голову, я-таки понял, что где-то есть внешний конфиг файл, где и хранится список модулей, на основе которого и создаётся loadmodule.conf - это файл /etc/sysconfig/apache2. Открываем его на редактирование любимым редактором текстов, например vim, ищем строку APACHE_MODULES="а здесь список модулей" и добавляем в неё mod_perl, не забывая, что имена модулей отделяются друг от друга пробелами.
Далее снова ерезапускаем Apache2 и смотрим список модулей командой apache2ctl -t -D DUMP_MODULES, теперь же в этом списке должен появиться "perl_module (shared)". Ещё один способ убедиться в успешной загрузке mod_perl - это команда tail -n20 /var/log/apache2/error_log, далее ищете в лог файле строку наподобие вот этой:
[Sat Jan 12 11:51:58 2008] [notice] Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.8e mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations
Теперь попробуем запустить обычный perl cgi скрипт. Просмотрев конфиг файл /etc/apache2/default-server.conf, можно понять, что обычным местом для CGI приложений является папка /srv/www/cgi-bin (если её нету, то Вам потребуется её создать). В указанной папке создаём файл hello.pl следующего содержания:
После этого нам нужно поставить права 755 для файла hello.pl, для этого можно использовать команду chmod a+rx hello.pl. Всё, можете пробовать открыть ссылку http://127.0.0.1/cgi-bin/hello.pl, если отобразится "Standard CGI!", то с настройкой обычного CGI мы закончили. Переходим непосредственно к настройке к mod_perl.
Создадим папку для наших mod_perl2 приложений - mkdir /srv/www/cgi-fast. Далее переименуем старый конфиг mod_perl2 mv /etc/apache2/conf.d/mod_perl.conf /etc/apache2/conf.d/conf_old, т.к. мы его будем заменять на новый, а старый лишь сохраняем на всякий случай, вдруг пригодится.
Создаём файл /etc/apache2/conf.d/mod_perl.conf следующего содержания:
Далее в папке /srv/www/cgi-fast создаём файл test.pl следующего содержания:
Выставляем права chmod a+rx test.pl, проверяем http://127.0.0.1/cgi-fast/test.pl, скрипт должен напечатать строки: Standard CGI from mod_perl folder! и mod_perl/2.0.3, что повествует о работоспособности mod_perl. Как можно понять, в этом случае мы произвели запуск обыкновенного Perl скрипта через mod_perl.
Создаём в папке /srv/www/perl-lib подпапку MyApache2 и во вновь созданной папке создаём файл Rocks.pm следующего содержания:
Теперь добавляем в конфиг /etc/apache2/conf.d/mod_perl.conf следующий блок:
Таким образом конфиг примет вид:
Теперь открываем http://127.0.0.1/rocks и, надеюсь, радуемся увиденному :)
После того, как всё было успешно (а я ,надеюсь, это так и будет) установлено переходим к настройке. Для начала запустим Апач командой service apache2 start, после этого будет выведено: Starting httpd2 (worker) done, это означает, что запуск веб сервера Apache2 c MPM Worker выполнен успешно.
Далее нам необходимо просмотреть список модулей, которые загружаются сервером, для этого можно воспользоваться командой: apache2ctl -t -D DUMP_MODULES, как можно видеть, там нету perl_module (именно так зовётся модуль mod_perl), поэтому нам нужно сообщить серверу о том, что мы хотим использовать именно его. Список модулей, загружаемых Apache2, хранится в файле /etc/apache2/sysconfig.d/loadmodule.conf, но его особенность в том, что все изменения в нём живут до перезапуска сервера, т.к. в это время конфиг файл затирается и приводится в первоначальную форму. Как можно понять, добавлять в этот конфиг mod_perl2 бесполезно, но куда же его прописывать? Некоторое время поломав голову, я-таки понял, что где-то есть внешний конфиг файл, где и хранится список модулей, на основе которого и создаётся loadmodule.conf - это файл /etc/sysconfig/apache2. Открываем его на редактирование любимым редактором текстов, например vim, ищем строку APACHE_MODULES="а здесь список модулей" и добавляем в неё mod_perl, не забывая, что имена модулей отделяются друг от друга пробелами.
Далее снова ерезапускаем Apache2 и смотрим список модулей командой apache2ctl -t -D DUMP_MODULES, теперь же в этом списке должен появиться "perl_module (shared)". Ещё один способ убедиться в успешной загрузке mod_perl - это команда tail -n20 /var/log/apache2/error_log, далее ищете в лог файле строку наподобие вот этой:
[Sat Jan 12 11:51:58 2008] [notice] Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.8e mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations
Теперь попробуем запустить обычный perl cgi скрипт. Просмотрев конфиг файл /etc/apache2/default-server.conf, можно понять, что обычным местом для CGI приложений является папка /srv/www/cgi-bin (если её нету, то Вам потребуется её создать). В указанной папке создаём файл hello.pl следующего содержания:
#!/usr/bin/perl print "Content-type: text/plain\n\n"; print "Standard CGI!\n";
После этого нам нужно поставить права 755 для файла hello.pl, для этого можно использовать команду chmod a+rx hello.pl. Всё, можете пробовать открыть ссылку http://127.0.0.1/cgi-bin/hello.pl, если отобразится "Standard CGI!", то с настройкой обычного CGI мы закончили. Переходим непосредственно к настройке к mod_perl.
Создадим папку для наших mod_perl2 приложений - mkdir /srv/www/cgi-fast. Далее переименуем старый конфиг mod_perl2 mv /etc/apache2/conf.d/mod_perl.conf /etc/apache2/conf.d/conf_old, т.к. мы его будем заменять на новый, а старый лишь сохраняем на всякий случай, вдруг пригодится.
Создаём файл /etc/apache2/conf.d/mod_perl.conf следующего содержания:
Alias /cgi-fast/ /srv/www/cgi-fast/ <IfModule mod_perl.c> PerlRequire "/etc/apache2/mod_perl-startup.pl" <Location /cgi-fast/> SetHandler perl-script PerlResponseHandler ModPerl::Registry # PerlResponseHandler ModPerl::PerlRun # выбор конкретного модуля определяется # условиями решаемой задачи # более подробно про модули на search.cpan.org PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all </Location> </IfModule>
Далее в папке /srv/www/cgi-fast создаём файл test.pl следующего содержания:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Standard CGI from mod_perl folder!\n";
print $ENV{MOD_PERL};
Выставляем права chmod a+rx test.pl, проверяем http://127.0.0.1/cgi-fast/test.pl, скрипт должен напечатать строки: Standard CGI from mod_perl folder! и mod_perl/2.0.3, что повествует о работоспособности mod_perl. Как можно понять, в этом случае мы произвели запуск обыкновенного Perl скрипта через mod_perl.
Создаём в папке /srv/www/perl-lib подпапку MyApache2 и во вновь созданной папке создаём файл Rocks.pm следующего содержания:
#file:MyApache2/Rocks.pm
#----------------------
package MyApache2::Rocks;
use strict;
use warnings;
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::Const -compile => qw(OK);
sub handler {
my $r = shift;
$r->content_type('text/plain');
print "mod_perl2 application rocks!!!\n";
return Apache2::Const::OK;
}
1;
Теперь добавляем в конфиг /etc/apache2/conf.d/mod_perl.conf следующий блок:
<Location /rocks> SetHandler perl-script PerlResponseHandler MyApache2::Rocks </Location>
Таким образом конфиг примет вид:
Alias /cgi-fast/ /srv/www/cgi-fast/ <IfModule mod_perl.c> PerlRequire "/etc/apache2/mod_perl-startup.pl" <Location /cgi-fast/> SetHandler perl-script PerlResponseHandler ModPerl::Registry # PerlResponseHandler ModPerl::PerlRun PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all </Location> <Location /rocks> SetHandler perl-script PerlResponseHandler MyApache2::Rocks </Location> </IfModule>
Теперь открываем http://127.0.0.1/rocks и, надеюсь, радуемся увиденному :)
Apache2 prefork vs worker
Довольно продолжительное время при установке веб сервера Apache я сомневался, ставить ли мне apache2-worker или apache2-prefork, вот и настал момент, когда стоит устранить все неясности в этом выборе и явно описать, что и когда лучше использовать.
Официальная документация сервера говорит о следующем:
Переводить всё не возьмусь, смысла в этом не вижу, но постараюсь описать в двух словах, чем занимаются каждый из указанных модулей.
В документации рассказывается, что у сервера Apache2 мультипоточность реализована посредством подключаемых модулей - MPM (по поводу перевода я сомневаюсь, но, на мой взгляд, лучше перевести как "модули мультипоточной обработки", хотя далее я буду использовать аббревиатуру в виду громоздкости данного названия), которые являются платформозависимыми. Существует две основных модели MPM модулей - это worker MPM и prefork MPM.
Worker работает следующим образом - при запуске создаётся несколько дочерних процессов, по несколько потоков в каждом (сколько именно подразумевается под "несколько" задаётся в конфиг файле Apache2). В качестве преимущества данного модуля указывается пониженное потребление памяти по сравнению с Prefork модулем. Также этот модуль рекомендуется для высоконагруженных веб серверов.
Prefork же создаёт некоторое количество дочерних процессов, но в отличие от Worker, в каждом из них ровно по одному потоку. Т.е. каждый процесс обрабатывает только одно соединение. По поводу скорости указывается, что скорость обоих модулей более-менее соизмерима, но Prefork потребляет больше памяти. Использование безпоточного модуля Prefork предпочтительно в случае использования модулей, который не обладают безопасной мультипоточностью. Также рекомендуется использовать Prefork на платформах, где отладка мультипоточных приложений не реализована на должном уровне (к слову говоря, отлаживать мультипоточные приложения даже на системах с хорошей поддержкой оного - занятие не из простых).
В заключение хотелось бы добавить, что однозначного выбора не существует, всё определятся решаемыми задачами, но следует помнить, что модель Prefork (она, кстати, была единственной моделью, которую поддерживали сервера на Apache 1.3) является заведомо более стабильной, т.к. сбой в одном процессе не затрагивает другие процессы, а в случае Worker сбой в одном потоке может вывести из строя ещё несколько соседних потоков, хотя Worker показывает более высокую скорость в определённом спектре задач (в частности высоконагруженные сервера).
А вот данные реального тестирования: http://www.camelrichard.org/apache-prefork-vs-worker
Стабильности серверов в обоих случаях была 100%, а вот Worker почти в 2 раза обогнал Prefork, но тем не менее это не значит, что и на большем количестве соединений результаты будут в том же самом соотношении да и тест синтетический, в реальных условиях всё может быть иначе.
А вот на тему скорости работы: http://www.camelrichard.org/apache-prefork-vs-worker (mpm worker показывает двухкратный прирост производительности на Solaris!) Для Линукса такого роста, к несчастью, нету: http://www.thrull.com/corner/webserver/prefork-vs-worker/
Сейчас попробуем провести тесты, как будет работать Apache+ mod_fcgi PHP в конфигурациях Prefork и Worker.
Официальная документация сервера говорит о следующем:
Choosing an MPM
Apache 2.x supports pluggable concurrency models, called Multi-Processing Modules (MPMs). When building Apache, you must choose an MPM to use. There are platform-specific MPMs for some platforms: beos, mpm_netware, mpmt_os2, and mpm_winnt. For general Unix-type systems, there are several MPMs from which to choose. The choice of MPM can affect the speed and scalability of the httpd:
* The worker MPM uses multiple child processes with many threads each. Each thread handles one connection at a time. Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM.
* The prefork MPM uses multiple child processes with one thread each. Each process handles one connection at a time. On many systems, prefork is comparable in speed to worker, but it uses more memory. Prefork's threadless design has advantages over worker in some situations: it can be used with non-thread-safe third-party modules, and it is easier to debug on platforms with poor thread debugging support.
For more information on these and other MPMs, please see the MPM documentation
Переводить всё не возьмусь, смысла в этом не вижу, но постараюсь описать в двух словах, чем занимаются каждый из указанных модулей.
В документации рассказывается, что у сервера Apache2 мультипоточность реализована посредством подключаемых модулей - MPM (по поводу перевода я сомневаюсь, но, на мой взгляд, лучше перевести как "модули мультипоточной обработки", хотя далее я буду использовать аббревиатуру в виду громоздкости данного названия), которые являются платформозависимыми. Существует две основных модели MPM модулей - это worker MPM и prefork MPM.
Worker работает следующим образом - при запуске создаётся несколько дочерних процессов, по несколько потоков в каждом (сколько именно подразумевается под "несколько" задаётся в конфиг файле Apache2). В качестве преимущества данного модуля указывается пониженное потребление памяти по сравнению с Prefork модулем. Также этот модуль рекомендуется для высоконагруженных веб серверов.
Prefork же создаёт некоторое количество дочерних процессов, но в отличие от Worker, в каждом из них ровно по одному потоку. Т.е. каждый процесс обрабатывает только одно соединение. По поводу скорости указывается, что скорость обоих модулей более-менее соизмерима, но Prefork потребляет больше памяти. Использование безпоточного модуля Prefork предпочтительно в случае использования модулей, который не обладают безопасной мультипоточностью. Также рекомендуется использовать Prefork на платформах, где отладка мультипоточных приложений не реализована на должном уровне (к слову говоря, отлаживать мультипоточные приложения даже на системах с хорошей поддержкой оного - занятие не из простых).
В заключение хотелось бы добавить, что однозначного выбора не существует, всё определятся решаемыми задачами, но следует помнить, что модель Prefork (она, кстати, была единственной моделью, которую поддерживали сервера на Apache 1.3) является заведомо более стабильной, т.к. сбой в одном процессе не затрагивает другие процессы, а в случае Worker сбой в одном потоке может вывести из строя ещё несколько соседних потоков, хотя Worker показывает более высокую скорость в определённом спектре задач (в частности высоконагруженные сервера).
А вот данные реального тестирования: http://www.camelrichard.org/apache-prefork-vs-worker
Стабильности серверов в обоих случаях была 100%, а вот Worker почти в 2 раза обогнал Prefork, но тем не менее это не значит, что и на большем количестве соединений результаты будут в том же самом соотношении да и тест синтетический, в реальных условиях всё может быть иначе.
А вот на тему скорости работы: http://www.camelrichard.org/apache-prefork-vs-worker (mpm worker показывает двухкратный прирост производительности на Solaris!) Для Линукса такого роста, к несчастью, нету: http://www.thrull.com/corner/webserver/prefork-vs-worker/
Сейчас попробуем провести тесты, как будет работать Apache+ mod_fcgi PHP в конфигурациях Prefork и Worker.
Subscribe to:
Posts
(
Atom
)