Posts Tagged ‘ Web

Debian Jessie: WEB-сервер — ускоряемся … (memcached, xcache)

Это заметка из цикла стетей моего небольшого HowTo по Debian Jessie.

Попробуем немного ускорить выдачу сервером web-контента. Начнем с простого пятиминутного тюнинга … сессии. По умолчанию сессии пользователей на сервере хранятся в виде отдельных файликов на файловой системе в директории /var/lib/php5/sessions Это вполне отлично при малом количестве посетителей ресурса, но становится проблемой при увеличении посещаемости, так как дисковые операции очень «дорогие» и «тяжелые» с точки зрения сервера. Такой способ хранения сессий порождает излишнюю нагрузку на дисковую подсистему сервера и замедляет выдачу контента пользователям. Выход придуман давным давно — перенести сессии в RAM-у сервера. Простейшим решением является сервис memcached который представляет из себя key value базу данных работающую исключительно в оперативной памяти. Это, кстати, таит в себе и побочный неприятный момент — в случае перезапуска сервиса memcached или сервера целяком — база очищается, а значит пользователям придется «перелогиниться». Если это критичный для вас момент — тогда лучше использовать сервис который синкает базу данных на диск, например couchbase или redis. Но я не дорожу своими сессиями, потому что пользователей у меня чуть больше чем 1 🙂 поэтому буду использовать memcached
Установим необходимые пакеты:

gw:~$ sudo apt-get install memcached php5-memcached

Открываем основной конфиг memcached:

gw:~$ sudo vim /etc/memcached.conf

По умолчанию сервис запускается с базой в 64MB, для меня это мало (чуть позже расскажу почему) — ставлю 128 MB:

-m 128

Запускаем службу memcached:

gw:~$ sudo systemctl start memcached

Проверяем что служба «слушает» порт 11211:

gw:~$ sudo netstat -lnp |grep mem
tcp  0  0 127.0.0.1:11211   0.0.0.0:*     LISTEN      3187/memcached  
udp  0  0 127.0.0.1:11211   0.0.0.0:*                 3187/memcached  
gw:~$

Теперь перестроим php таким образом чтобы он хранил сессии в memcached, а не в файлах на диске. Открываем конфиг php.ini для fpm:

gw:~$ sudo vim /etc/php5/fpm/php.ini

Ищем там секцию [Session] и настраиваем ее вот так (привожу только те параметры что поменял, остальные оставляем по дефолту):

session.save_handler = memcached
session.save_path = "127.0.0.1:11211"
session.gc_probability = 1

Перезапускаем сервис php5-fpm:

gw:~$ sudo systemctl restart php5-fpm.service

Если вы используете в apache2 модуль php5 то у него есть отдельный конфиг ( /etc/php5/apache2/php.ini ), операцию по перестройке его на memcached сессионное хранилище нужно повторить по аналогии с php5-fpm, после чего перегрузить сервис apache2

Поскольку memcached давно откатанный и стабильный вариант работы с RAM хранилищем в PHP (и не только) в различных WEB проектах его используют не только для хранения сессий, но и как хранилку кеша. Для популярных CMS есть готовые модули которые умеют запихивать в memcache куски страниц или даже целые страницы готового скомпилированного HTML-я. Это позволяем в разы увеличить скорость выдачи контента и при этом уменьшить нагрузку на сервер (магия?) но требует серьезной проработки кода проекта под фичу кеширования вцелом.
Вот примеры среди популярных бесплатных CMS:
— Drupal 6/7 — тыц
— WordPress — тыц
— Joomla — тыц
и тд.
Я отдал memcached-у 128MB RAM именно для этого варианта кеширования.
Ставим модуль, настраиваем, пользуемся и радуемся дикому приросту скорости отдачи контента. Имейте ввиду что кеш очищается при рестарте сервиса memcached.

С memcached вроде как все ясно, неясно одно — почему решение вопроса «кешировать или компилить» должен решать программист конкретного продукта с помощью сторонних приложений, а не сам php? Это вполне логичный вопрос и он имеет решение в виде модулей для php которые призваны этим заниматься. Их много, почитать коротко о них можно здесь, ИМХО — достаточно вменяемый на сегодняшний день XCache, он достаточно стабилен и продолжает развиваться. Достаточно часто встречал в сети лестные отзывы о нем. Пробую прикрутить …

Установим необходимые пакеты:

gw:~$ sudo apt-get install php5-xcache

Приятной особенностью данного модуля является наличие web-админки где можно посмотреть текущие настройки, статистику, очистить кеш и тп Это не обязательная фича данного модуля, можно не заморачиваться, но мне было интересно — решил настроить.
Генерим пароль в админку XCache (иначе никак):

gw:~$ echo -n "_mypassword_" | md5sum
34819d7beeabb9260a5c854bc85b3e44  -
gw:~$

Для настройки модуля xcache открываем его конфиг:

gw:~$ sudo vim /etc/php5/fpm/conf.d/20-xcache.ini

Вот такой конфиг получился (только то что поменял от дефолта):

[xcache.admin]
xcache.admin.enable_auth = On
; Configure this to use admin pages
xcache.admin.user = "xcache_admin"    
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "34819d7beeabb9260a5c854bc85b3e44"

xcache.size  =     64M
xcache.count =     2
xcache.gc_interval = 86400

xcache.var_size  = 8M
xcache.var_count = 2
xcache.var_gc_interval = 86400

xcache.optimizer = On

Перезапускаем сервис php5-fpm:

gw:~$ sudo systemctl restart php5-fpm.service

Про настройку WEB-интерфейса данного модуля расскажу чуть позже, настроим его вместе с другими популярными WEB-приложениями (PHPMyAdmin, PostfixAdmin, Roundcube).

Теоретически такой вариант кеширования должен работать быстрее чем основанный на memcached, чтобы убедиться в этом нужно тестировать, но это уже отдельная тема. Модуль работает сразу после его включения в php5. Для большей эффективности можно использовать плагины со стороны CMS, например для WordPress можно попробовать вот этот модуль. Устанавливается он не сложно, по инструкции. Дополнительных действий никаких, просто ждем пока наполнится кеш и наступит нирвана 🙂 Напомню что в данном варианте кеш очищается при рестарте сервиса php5-fpm

Незнаю будет ли кому полезно, получилось несколько сумбурно …

Хай щастить!

Debian Jessie: Настройка WEB сервера (Apache2/Nginx/PHP-FPM)

Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.

Чуть раньше я коротенько описал процесс установки и базовой настройки всех необходимых компонентов для WEB сервера:
Debian Jessie: Настройка apache2 + libapache2-mod-php5
Debian Jessie: Установка и настройка Nginx
Debian Jessie: Установка и настройка PHP5-FPM

Из этих компонентов мы сложим несколько вариантов настройки WEB сервера:
1. Nginx -> Apache2 -> libapache2-mod-php5
2. Nginx -> PHP5-FPM
3. Nginx -> PHP5-FPM в chroot

Поехали … Читать полностью

Debian Jessie: Установка и настройка PHP5-FPM

Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.

Современный Интернет трудно представить без языка PHP, но возможностей работать с PHP из коробки нет ни у кого среди WEB-серверов. С Apache2 мы уже разобрались, установив для него модуль php, а вот с Nginx не так просто — он умеет работать с PHP по протоколу CGI. Наиболее прогрессивной вариацией CGI на сегодняшний день является FastCGI, а менеджер процессов для него — PHP-FPM. Он есть в стандартных репозиториях Debian под именем php5-fpm.
Установим:

gw:~$ sudo apt-get install php5-fpm

Также для PHP наверняка понадобятся некоторые модули, если чегото не хватит — доустановим в процессе разворачивания сайтов:

gw:~$ sudo apt-get install php5-curl php5-mcrypt php5-mysql

Не забываем добавить сервис в автозагрузку:

gw:~$ sudo systemctl enable php5-fpm.service

Теперь к настройкам.
После установки пакетов у вас появится отдельная директория для настроек php-fpm — /etc/php5/fpm
В ней расположен основной конфиг сервиса — /etc/php5/fpm/php-fpm.conf Настраивать я там особо ничего не стал, просто проверил чтобы была настройка с инклудами пулов:

...
include=/etc/php5/fpm/pool.d/*.conf
...

Хорошим правилом на хостинге где много сайтов под каждый сайт настраивать отдельного системного пользователя и отдельный php пул. Это дает возможность гибко настраивать php для каждого отдельного сайта, а также, «изолировать» на уровне php сайты друг от друга. Настройка пулов совсем несложная. Конфиги расположены в директории /etc/php5/fpm/pool.d По умолчанию в php-fpm есть один пул — www с конфигом — /etc/php5/fpm/pool.d/www.conf Я обычно выключаю данный конфиг простым переименованием файла в example или default:

gw:~$ sudo mv /etc/php5/fpm/pool.d/www.conf /etc/php5/fpm/pool.d/default

и потом использую в качетсве шаблона при создании своих пулов. Как и обещал, в следующей статье про WEB я приведу примеры конфигов двух вариантов запуска пулов php-fpm: в chroot и без него. А сейчас хочу просто перечислить основные настройки пулов и коротко их описать.

Название пула. В самом верху конфига в квадратных скобках пишут название пула, например:
[www] или [somepool] и тп

Пользователь и группа:

user =
group =

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

user = www-data
group = www-data

Где слушаем подключения:

listen =

Может быть как TCP сокет, так и Unix сокет. Если указать только номер TCP порта, значит слушать этот порт на всех интерфейсах. Например:

listen = /var/run/php5-fpm.sock
listen = 127.0.0.1:9001
listen = 9001

Если в качетве listen используется Unix сокет — то нужны дополнительные параметры по правам доступа и владельцу, также обращаю внимание на то что user от которого запущен процесс пула должен иметь права записи на сокет, иначе работать не будет:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

С каких ip принимать запросы:

listen.allowed_clients =

Используется в случае listen TCP сокета на всех интерфейсах. Я бы рекомендовал закрывать фаерволом, но тем не менее на уровне сервиса можно контроллировать доступ к сокету просто перечислив необходимые ip — остальные «идут лесом» Например розрешим доступ только с двух ip:

listen.allowed_clients = 192.168.1.100, 192.168.1.200

Настройка менеджера процессов, это очень важная часть конфига:

pm =
pm.max_children =
pm.start_servers =
pm.min_spare_servers =
pm.max_spare_servers =

Тут трудно описать лучше чем в официальной документации, поэтому лучше прочтите сами и настраивайте с понимаением дела.

Время в секундах после которого простаивающие процессы будут убиты, работает только при pm = ondemand:

pm.process_idle_timeout =

Количество реквестов после которого fastcgi процесс полностью перезапустится:

pm.max_requests =

Это очень полезная опция, реально может помочь при работе с проектом в котором есть баги с утечками памяти. Конечно же это не решает проблему кривого кода, но зато существенно сокращает количество сегфолтов.
Вцелом хочу подитожить — грамотная настройка pm* опций в пуле php-fpm помогает «держать на плаву» даже самые безнадежные php поделия 🙂

Статистика пула:

pm.status_path =

Полезная опция для мониторинга и статистики, включить можно например так:
pm.status_path = /$pool-status
после чего настраиваем проксирование некоторого локейшена в домене localhost на данный URL. Пример:

server {
    listen 127.0.0.1:901;
    location = /backend-status {
        access_log off;
        fastcgi_pass 127.0.0.1:9001;
        fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
        include fastcgi_params;
        allow 127.0.0.1;
        deny all;
    }
}

после перезапуска nginx мы можем посмотреть что же там за статистика пула:

gw:~$ curl http://localhost:901/fpm-status
pool:                 backend
process manager:      dynamic
start time:           05/Nov/2015:18:19:39 +0000
start since:          40412
accepted conn:        5378
listen queue:         0
max listen queue:     0
listen queue len:     65535
idle processes:       9
active processes:     1
total processes:      10
max active processes: 3
max children reached: 0
slow requests:        0
gw:~$

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

Также для мониторинга доступности можно использовать более простой механизм ping-pong:

ping.path =

Значение по умолчанию /ping. Если данный URI спроксировать nginx-ом по образу и подобию приведенному выше, то в ответ будем получать 200-ку и некоторый ответ, который по умолчанию pong но можно задать кастомный следующей опцией:

ping.response =

Очень полезная фишка для простейшего мониторинга доступности сервиса.

Лог запросов, для дебага незаменимая опция:

access.log =

Просто задаем путь к логу, например так:
access.log = /var/log/php-fpm/$pool_access.log

Формат лога доступа:

access.format =

Огромный выбор различных параметров, смотрите сами в дефолтном конфиге для пула www.

Чаще на практике бывает что весь лог доступа не нужен, нужны только заведомо проблемные запросы. Таковыми являются те что долго выполняются. Для таких случаев есть отдельная опция — slowlog:

slowlog =

задает путь к файлу, например:
slowlog = /var/log/php-fpm/$pool_slow.log
а следующая опция задает время выполнения, после которого мы считаем запрос «медленным»:

request_slowlog_timeout =

А это опция для особо злых запросов:

request_terminate_timeout =

медленные запросы могут быть реальной проблемой. К тому же в какойто момент компиляция php файла по неким причинам может вообще затянуться на века … создавая никому ненужную нагрузку на сервер. Для таких случаев придумана данная опция, если выставить ее к примеру 10 секунд, то все запросы обрабатывающиеся fastcgi процессом более 10 секунд будут просто убиваться pm-ом.

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

rlimit_files =

Корневая директория для процессов пула, очень полезная опция для повышения безопасности. Особенно для shared-хостингов.

chroot =

Перенаправлять с воркеров stdout и stderr в родительский процесс.

catch_workers_output =

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

Розширения принимаемые для обработки можно задать явно:

security.limit_extensions =

Например:
security.limit_extensions = .php .php5
Файлы с другими розширениями обрабатываться не будут.

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

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

Ну и напоследок — переназначение глобальных настроек php.ini. Например:

php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/fpm-php.www.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 16M

Конкретные примеры будут приведены в следующей статье, а на данный момент все …

Хай щастить!

Debian Jessie: Установка и настройка Nginx

Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.

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

Для начала установим nginx (используются стандартные репы Debian Jessie):

gw:~$ sudo apt-get install nginx-extras

И поехали …
Читать полностью

Debian Jessie: Настройка apache2 + libapache2-mod-php5

Это статья из цикла стетей моего небольшого HowTo по Debian Jessie.

В данной статье мы установим и базово настроим apache2 — один из компонентов самой простой и популярной схемы WEB hosting-ов:

nginx -> apache2 -> mod_php5

Новичкам часто непонятно, зачем в современном вебе досих пор используется apache? Ведь Nginx якобы эффективно отдает статику (png, jpg, css, js … etc), а php-fpm отлично работает с php-кодом и подружить их вместе не составляет труда. Но тут есть небольшая ложка дегтя в виде файлов .htaccess/.htpasswd которые не умеет обрабатывать nginx, а apache умеет 🙂 Данные файлики очень часто используются web-мастерами для различного рода настроек, таких например как реврайты, права доступа, опции php и тд. Простыми словами, это дает пользователю возможность самому, без перезапуска сервисов, настраивать множество нюансов связанных как с apache так и с php. В отличии от этого, перенастройка компонентов связки Nginx + PHP-FPM возможна только со стороны админа и требует перезапуска сервиса. Читать полностью

Перестраиваем apache22 + mod_php5 -> nginx + apache22 + mod_php5

На одном из серверов понадобилось добавить чуть больше гибкости web-серверу. Система FreeBSD, web-сервер настроен по олдскульной классике: Apache22 -> mod_php5 -> MySQL. Поскольку ковырять старичка апача особо желания нет, решил просто «накрыть» его nginx-ом и докрутить в нем все свои хотелки (GeoIP, bandwidth limit, различные варианты отдачи в зависимости и User Agent и тд.) Тоесть нужна вот такая схема: Nginx -> Apache22 -> mod_php5 -> MySQL
Основная задача — свести к минимуму Downtime.
Итак, поехали … Читать полностью

Pentaho + Saiku = Nginx «Error 400 Illegal character in path…»

Блин, последнее время часто натыкаюсь на какието нёхи … притом на ровном месте 🙂
Решил за nginx засунуть Pentaho и Pentaho-DI, сделал по этой статье … на данном этапе проблем не возникло. А вот установленный в Pentaho плагин Saiku Analytics отказался фильтровать данные при постройке OLAP-ов … После тучи угробленного времени с дебагом java, решил копнуть в сторону nginx, и правильно сделал 🙂 Он то зараза мне свинью и подсунул в виде вот такой ошибки:

122.122.100.2 - - [13/Dec/2014:09:07:01 +0000] "GET /pentaho/plugin/saiku/api/api/query/2CA565443-5B4B-3841-AC54-168602DCE65C/result/metadata/hierarchies/%5Bboss.default%5D/levels/fio?result=true&searchlimit=3000&_=1418720804584 HTTP/1.1" 400 990 "https://pentaho.somedomain.com/pentaho/content/saiku-ui/index.html?biplugin5=true&ts=1418720803760" "Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0" "-"

Ошибка эта изза того что jQuery саиковский генерит GET запрос содержащий символы «[]» которые nginx лихо преобразовывает в «%5B» и «%5D» и уже в таком виде отдает tomcat-у … на что томкат рычит и запрос не понимает, тупо отбрасывает с ошибкой.
Для решения данной проблемки достаточно в конфиге nginx убрать слеш в параметре proxy_pass. Короче … делай как я! Читать полностью

Два сервера Ubuntu 14.04 (Trusty Tahr) — настройка GlusterFS

Понадобился файловый кластер в Linux, вот и подвернулся случай опробовать нашумевший в свое время GlusterFS. Альтернативой для gluster может быть drbd, о нем я тоже напишу както попозже … на этот раз подымаем Gluster!
Имеем, 2 сервера с установленной Ubuntu 14.04 LTS. IP адреса 100.100.100.100 (www-srv1) первый и 100.100.100.200 (www-srv2) второй.
Действия ниже делаются на обоих серверах, в случае необходимости я буду указывать что делается на одном сервере, также это можно понять из приветствия консоли!
1. Начинаем как всегда сначала, обновляем информацию о пакетах:

apt-get update

2. Теперь добавляем репозиторий с пакетами GlusterFS версии 3.4:

apt-get install python-software-properties
add-apt-repository ppa:semiosis/ubuntu-glusterfs-3.4
apt-get update

И поехали дальше …. Читать полностью

Joomla 1.7.3 Upgrade to 1.7.5: Error Undefined property: stdClass::$category_note

Сломался у меня на днях один сайтик, ну точнее не совсем у меня и не совсем сломался … ну то детали. Какеры постарались, мать их! Ну Joomla была лохматой версии 1.7.3 и как она досих пор прожила без присмотра — для меня загадка. Но речь не об том. Почистив гору всякого контрафактного файла и восстановив доступ к админке, я решил Jooml-у обновить. Решил что минорного обновления до версии 1.7.5 в моем случае будет более чем достаточно. Несмотря на минорность в пакете обновления зашла приличная пачка различных security исправлений … чего мне и требовалось. Обновить данную CMS дело несложное, даже для полного нуба в Joomla как я, это особого труда не составило. Но после обновления вылезла неожиданная беда! На некоторых страницах вместо текста появились вот такие ошибки:

Notice: Undefined property: stdClass::$category_note in /home/www/templates/jblank/html/com_content/article/basic.php on line 6

И еще вот такие: Читать полностью

Roundcube 0.9.5 Upgrade to 1.0.3 — «DB Schema: NOT OK»

Тот кто сталкивался с обновлением Roundcube наверняка знает что обновить его это тот еще гемор 🙂 Вот и в этот раз я столкнулся с трудностями обновления с версии 0.9.5 до 1.0.3. То что конфиги разные и имеют разный формат — это ложка дегтя … ну да ладно. А вот обновления БД всегда были «поребриком» о который спотыкается каждый 🙂 Короче, наткнулся на такую вот ошибку: «DB Schema: NOT OK»
В инсталлере есть кнопочка «Update» которая якобы должна решить эту проблему, вот же она:

Roundcube - Upgrade SQL DB
но какую бы версию я не выбирал — ничего Читать полностью