shoorick: (Рыжий)
Apache 2.2 у маленьких конфигурационных файлов, вызываемых из основного, не использует расширение (хотя и не запрещает его применячть, конечно же). Старый Апач 1.3 — использовал. Как выяснилось методом тыка и чтения stackoverflow, новый Апач 2.4 — снова использует, во всяком случае команды a2ensite something и a2dissite something пытаются найти файл sites-available/something.conf. Да и в остальных каталогах /etc/apache2/*-available — куча conf-файлов.

Кусок конфигурационного файла

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

http://shoorick.ru/2016/09/18/dot-conf/
shoorick: (Рыжий)
Как я только не запускал перловые скрипты на веб-серверах — и как CGI, и как mod_perl (на обоих апачах), и как FastCGI через nginx.

А какой способ принято сейчас использовать?

Мы завели отдельную железяку под перловый хостинг, чтоб выселить туда всё перловое: несколько сайтов на Mojolicious, Catalyst и Movable Type плюс древний самописный кошмар, который давно переписать на чём-нибудь современном.

Хочется сделать это хорошо и правильно. Как быть? Что читать?
shoorick: (Default)
Обновлял сегодня php и его модули на сервере с FreeBSD — получил сообщение:
Your apache does not support DSO modules
Обновил апач — после этого и php5-* нормально обновились.
shoorick: (Default)
Каталистовое приложение жрёт достаточно много памяти

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

С другой стороны, более правильным методом было бы устранение утечек, а не отстрел процессов. Для этого есть куча методов: например, на xpoint.ru лежит список модулей, помогающих обнаружить утечки памяти. Попробовал запустить сервер, используя Devel::LeakTrace::Fast — всё затормозилось: только запуск ждать пришлось минут десять, если не больше, а отрисовка страницы занимала от одной до трёх минут. В результате в STDERR вывалился здоровенный список дырявых мест, причём бóльшая их часть — не в нашем приложении, а во внешних модулях.

Что делать — непонятно. Для начала, думаю, надо посмотреть и разобраться, что же мы сами-то написали.
shoorick: (Default)
Перенёс накопленное в траке со своей машины в редмайн на боевом сервере. Переношу subversion в том же направлении и задумался об оптимизации серверной части.

Svnserve, конечно, быстрый, но вводить пароли при доступе через svn+ssh:// задолбало, да и по непонятной причине он игнорирует ключ -r, а длинные URL типа svn+ssh://name.of.server/many/many/dirs/before/repo/project/trunk как-то плохо выглядят.

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

Nginx не все методы поддерживает и, следовательно, на роль обработчика запросов к svn как-то не очень годится — разве что воткнуть его прокси-сервером (а смысл?)

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

Продолжаю гуглить...

upd/00:45: Надоело гуглить, воткнул апач, спрятал за нгинксом (just for lulz) — работает. Надо снести ненужные модули и лечь спать.
shoorick: (Default)
Обновил trac 0.11.5 → 0.11.6. Нечаянно. Специально, помня предыдущий апдейт, я его бы обновлять не стал. Как всегда, всё сломалось. Пока пытался починить, выяснил, что в системе одновременно было установлено три питона: python24-2.4.5_4, python25-2.5.4_2, python26-2.6.4. Апач пытался найти трак среди приложений питона 2.5, при том, что основным был питон 2.6.

Починить удалось путём отсечения Змею двух голов из трёх замены двух старых версий питона на одну новую (portuprgade -o lang/python26 lang/python25; env FORCE_PKG_REGISTER=1 portuprgade -o lang/python26 lang/python25) и последующей пересборкой апачного mod_python.

Попутно, раз уж взялся налаживать trac, всё-таки настроил автоматическое приписывание комментариев к тикетам — трак может, встретив в комментарии к коммиту ссылку на тикет (например, вида re #123), добавить в этот тикет комментарий, а в некоторых случаях (fix #456)— и закрыть его.

Раньше подобный фокус не удавался: на машине используется много хранилищ трака и лишь одно, общее — у subversion; в результате hooks/post-commit всегда получал один и тот же адрес SVN-хранилища, вне зависимости от того, в какой из частей дерева был сделан коммит. Научить скрипт распознавать, в какой части дерева сделаны изменения и, соответственно, к какому траковому проекту обращаться — задача тривиальная; странно, что я не сделал это два года назад. В общем, надо добавить в hooks/post-commit одну строку, и ещё одну — поменять:
PROJECT=`/path/to/svnlook dirs-changed $REPOS -r $REV | head -n 1 | cut -f1 -d/`
TRAC_ENV="/path/to/trac/db/$PROJECT"
shoorick: (Default)
Предыдущие замеры производительности каталистовых серверов были не вполне чисты: на некоторых серверах использовалась тестовая версия БД, на некоторых — боевая. Хоть обе базы живут на одной машине и управляются одни SQL-сервером, их содержимое не совпадает. Понятно, что различие в содержимом может оказывать влияние на скорость — надо было сразу взять напильник в руки и настроить все серверы на использование одной и той же версии базы.

Сегодня протестировал с одинаковой базой — выяснил, что скорости апача и nginx + Catalyst::Engine::HTTP::Prefork совпадают. Более того, апач иногда проигрывает несколько процентов. Получается, что выбор не той базы давал апачу незаслуженное преимущество, достигавшее нескольких десятков процентов.

В итоге данные заметно поменялись: И теперь график выглядит так: )
shoorick: (Default)
Попробовал позавчера найти экспериментальным путём лучшее (с точки зрения производительности) количество дочерних процессов, с которыми следует запускать nginx + Catalyst::Engine::HTTP::Prefork и Apache + mod_perl.

Апач настраивал изменением параметра MaxClients в httpd.conf.

Связку нгинкса с каталистовым сервером — чуть сложнее: нгинкс не трогал, а менял параметры каталистового сервера: методу AppName->run можно, помимо прочих параметров, передать max_servers, задающий максимально допустимое количество создаваемых сервером дочерних процессов.

Картина получилась достаточно странная:

Зависимость производительности от числа запущенных процессов

Хотя результат по-прежнему зависит непонятно от чего: например, сегодня оба варианта показали бóльшую производительность, но с прежним соотношением: 9 к 12.

Либо можно попытаться ускорить само каталистовое приложение (Как? Менять шаблонизатор? Оптимизировать SQL-запросы? Апгрейдить железо? Выбрасывать бэкенд на отдельную машину?) — и не забивать себе голову подобными соревнованиями.

upd/21.01.2010: Более точное тестирование показало равную производительность апача и нгинкса.
shoorick: (Default)
По результатам гуглений и бубнений настроил nginx и каталист для совместной работы. В нгинксовом конфигурационном файле в моём случае надо указать, что фронтенд должен передать бэкенду не только своё имя, но и порт:
proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Host $http_host;
proxy_set_header   X-Forwarded-Port $http_port;
Это связано с тем, что оба работают на одной машине на разных портах. А каталистовому приложению надо сказать, что оно может быть спрятано от внешнего мира за прокси-сервером. Существуют разные методы, простейший из них — добавить в конфигурацию параметр using_frontend_proxy, равный единице. Чтобы не засорять модули, добавит его в конфиг.yml — это проще всего и вполне работоспособно.

Если не сделать такой настройки, то каталистовая функция uri_for будет возвращать ссылки на адреса бэкенда, который посетителю показывать совсем не надо.

Теперь осталось убедиться в корректной работе получившейся связки, проверить способность нгинкса к старту при загрузке системы — и можно будет запускать весь этот комбайн в космос боевую эксплуатацию.
shoorick: (Default)
Тестирование производительности по-разному запущенного каталистового приложения показывает неожиданные результаты: апач с мод_перлом с точки зрения производительности оказались более предпочтительными, чем другие варианты: и встроенный сервер (как в конфигурации по умолчанию, так и с CATALYST_ENGINE='HTTP::Prefork'), и nginx+FastCGI работают заметно медленнее, чем апач.

Из всех испробованных вариантов помимо чистого апача годится ещё nginx+Apache — статичные файлы можно раздавать nginx'ом, а динамику — апачем. Хотя сам апач прекрасно справляется и с раздачей статики, он жрёт гораздо больше памяти, чем nginx. С учётом того, что аппетит апача в отношении памяти можно ограничить директивами MaxClients (апач работал и с пятью дочерними процессами — скорость была не хуже скорости с пятьюдесятью процессами) и MaxRequestsPerChild (время жизни дочернего процесса (в принятых запросах), по умолчанию дочерние процессы живут бесконечно, что в данном случае не годится) — видимо такую систему и придётся сооружать (после того, как разберусь с uri_for).

График спрятан )
shoorick: (Default)
Удалось запустить подопытный сайт через nginx+FastCGI. Предварительно пришлось поставить p5-FastCGI-ProcManager, который почему-то не был автоматически поставлен при установке каталиста и обновить libtool, без которого FastCGI::ProcManager не желал ставиться.

Наблюдается интересная картина: производительность, судя по результатам работы ab, в 2–2,5 раза хуже, чем при использовании Apache+mod_perl (но во столько же лучше, чем у каталистового тестового сервера), однако расход памяти заметно ниже: апач на каждый процесс сразу отъедал около 60 метров памяти, процессы размножались и раздувались (до 200 метров на процесс — легко!), потребляя в сумме несколько гигабайт (стремясь сожрать всю доступную память: и физическую, и виртуальную); при использовании FastCGI всё не так: запускается всего 2 процесса со сходными аппетитами на память, один из них ничего не делает, зато другой делает, видимо, всё остальное:
$ top
  PID USERNAME THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
72718 as         1 125    0 57400K 49068K RUN    1   0:55 74.72% perl
72715 as         1   8    0 56896K 44720K wait   0   0:03  0.00% perl
Статичные файлы, как можно догадаться, раздаются непосредственно nginx'ом. Лёгкие файлы (например, иконка весом менее килобайта) выдаются раза в 2 быстрее, чем апачем, тяжёлые (например, prototype.js — больше 100 кБ) — примерно с одинаковой скоростью.
shoorick: (Default)
Попробовал между клиентом и каталистом воткнуть nginx.

Ну воткнул, ну запустил (настроив выдачу статики nginx'ом, а остального, как и раньше — апачем) — а пользы не видно: как апачные процессы жрали процессор — так и жрут, как mod_perl отъедал всё больше и больше памяти — так и отъедает.

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

В чём смысл-то? Разве что вынести backend на другую железяку (или завести несколько бэкендов на разных машинах) — может быть, что-то улучшится. Или попробовать FastCGI в надежде на уменьшение потребления памяти? Непонятно.

Толкового мануала к nginx'у нет (во всяком случае, на сайте разработчика). Ни на русском, ни на английском — лишь какие-то обрывки да разрозненные статьи, раскиданные по интернетам. Вот их и придётся изучать...
shoorick: (Default)
Апач, будучи запущен штатным путём, по-прежнему дохнет. Если воспользоваться советом с http://www.opennet.ru/openforum/vsluhforumID1/67639.html
# truss /usr/local/sbin/httpd
покажет на каком модуле вылеает apache
то апач успешно стартует, но truss на ошибки не ругается.
shoorick: (Default)
Апач сдох и не желает воскресать: при попытке выполнить apachectl start молча помирает, оставив после себя /httpd.core.
Погуглил. Подумал.
Подправил в httpd.conf степень разговорчивости:
LogLevel debug
Изучив лог, на всякий случай закомментировал использование mod_ssl (потому что не нужен). Не помогло. Постучал в бубен. Всё равно не помогло.

Думаю дальше...

upd/15:29: Обновил php. Апач неожиданно заработал. Но как?!
shoorick: (Default)
Задача — протестировать сайт на работу при большой нагрузке. Попробовали 2 способа:
  1. При помощи ab послали вагон запросов на какую-то одну страницу, попутно пытаясь пользоваться сайтом в обычном режиме,
  2. Посадили за компьютеры пару десятков юзеров и попросили их усиленно покликать по ссылкам.
Оба метода, хоть и не совсем бессмысленны, создают совсем не ту нагрузку, которая нужна: в первом случае нет хождения по ссылкам (или я ман плохо читал?), а во втором интенсивность кликов явно меньше той, что может обеспечить ab.

Что делать?
shoorick: (Default)
По умолчанию trac, когда работает через mod_python, всё своё содержимое выдаёт через него, хотя с раздачей статичных файлов — картинок, стилей и яваскриптов — сам апач справляется не хуже и, что главное, существенно быстрее: на моей, нагруженной иксами, машине, где заодно живёт и апач с траком, разница в скорости (по результатам замеров файрбагом) достигает ста и более раз.

С одной стороны, можно сменить адреса некоторых общих картинок
find /var/db/trac -name trac.ini -exec perl -pi -e 's{= common}{= /trac}' '{}' ';'
и раздавать эти картинки статически:
<IfModule alias_module>
Alias /trac/ /path/to/trac/htdocs/
Но зачем нам полумеры? Надо всю статику быстро раздавать. Поэтому подкаталог chrome не должен обрабатываться мод_питоном:
<LocationMatch "/projects/[^/]+/chrome">
SetHandler None
</LocationMatch>
Чтоб апач не ругался «404 Not Found», надо создать алиасы для этих каталогов. По идее, для этого должна использоваться директива AliasMatch, но у меня она не заработала: апач, вместо того, чтоб отдавать файлы, начинает бесконечно перенаправлять браузер по всё более длинному адресу, что браузеру достаточно быстро надоедает. Поэтому приходится ставить кучу директив
Alias /projects/projectname/chrome/common /path/to/trac/htdocs/
которые можно получить командой
ls /var/db/trac | perl -nl -e 'print "\t\tAlias /projects/$_/chrome/common /usr/local/www/trac/htdocs"'
Метод, конечно, какой-то неправильный, но всё-таки вполне работоспособный.
shoorick: (Default)
Пишем в перлоскрипте:
use URI;
use Digest::MD5 'md5_hex';

my $uri = URI->new('some_uri');
$uri->query_form( \%args );
my $md5_of_uri = md5_hex( $uri );
В итоге всё, вроде-бы, работает, да перл ругается в STDERR (ну или в апачный лог):
&Digest::MD5::md5_hex function called with reference argument
Но стóит чуть-чуть изменить код:
my $md5_of_uri = md5_hex( $uri->as_string );
и всё приходит в норму.
shoorick: (Default)
После апгрейда trac с 0.10.4 через какие-то промежуточные версии до 0.11_2, он благополучно перестал работать. Апач в логи пишет: кучу текста )

Оказалось, старая версия устанавливалась в /usr/local/lib/python2.5/site-packages/trac, а новая — в /usr/local/lib/python2.5/site-packages/Trac-0.11-py2.5.egg/trac. Попробовал простейший из путей — сделал симлинк: tracTrac-0.11-py2.5.egg/trac. Заработало.
shoorick: (Default)
Хозяйке на заметку:
кодировка, в которой, по мнению апача, написан скрипт — в переменной окружения SOURCE_CHARSET,
кодировка, в которой живёт браузер клиента — в переменной окружения CHARSET.

upd/17:50: Но это справедливо не всегда, а лишь тогда, когда в конфигах выставлено Options MultiViews и имя файла заканчивается на код языка, например, на .ru
shoorick: (Default)
Что-то рабочая машина тормозит. Конечно, она слегка занята: помимо запущенных иксов, файрфокса с тандербёрдом параллельно перегоняется музыка из mp3 в ogg vorbis, компиляется свежая Xara LX, apache и trac обрабатывают запросы, и amarok, заикаясь, пытается петь песни «Несчастного случая».

Работать при этом как-то некомфортно... Чё бы прибить?

Profile

shoorick: (Default)
shoorick

December 2016

S M T W T F S
    1 23
45678910
11121314151617
18 19 2021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 20th, 2017 02:29 pm
Powered by Dreamwidth Studios