Настройка производительности для высокопроизводительных веб-сайтов.

Проверка «узких» мест сайта.

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

Continue Reading

Ищем файлы m4a в текущей папке и конвертируем их в mp3

find . -type f -name '*.m4a' -exec bash -c 'avconv -i "$0" "${0/%m4a/mp3}"' '{}' \;

для удаления файлов m4a запускаем команду

find . -type f -name '*.m4a' -exec bash -c 'rm "$0"' '{}' \;

При возникновении  ошибка socket () failed (24: Too many open files)

Причина в лимитах. По умолчанию на процесс выдается возможность открыть 1024 файла. посмотрим текущие лимиты.

#for pid in `pidof nginx`; do echo "$(< /proc/$pid/cmdline)"; egrep 'files|Limit' /proc/$pid/limits; echo "Currently open files: $(ls -1 /proc/$pid/fd | wc -l)"; echo; done

Получим отчет

nginx: worker process
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files     
Currently open files: 1009
nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files     
Currently open files: 16

 

вносим изменения  в nginx.conf

#mcedit /etc/nginx/nginx.conf

добавляем директиву

#worker_rlimit_nofile 8192;

и перезагружаем nginx

#service nginx restart

посмотрим лимиты после вненсения изменений

nginx: worker process
Limit                     Soft Limit           Hard Limit           Units     
Max open files            8192                 8192                 files     
Currently open files: 1180
nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Limit                     Soft Limit           Hard Limit           Units     
Max open files            1024                 4096                 files     
Currently open files: 18

 

В консоли запустим

#ulimit -n 16384

 

#mcedit /etc/security/limits.conf

*       soft    nofile  16384
*       hard    nofile  16384

 

 

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

apt-get install erlang  gnuplot-nox libtemplate-perl libhtml-template-perl libhtml-template-expr-perl make

Создадим папку перейдем в нее и загрузим дистрибутив программы утилитой wget.

mkdir ./src; cd ./src &&  wget http://tsung.erlang-projects.org/dist/tsung-1.5.1.tar.gz

 

Извлекаем файлы из архива

tar -xvzf tsung-1.5.1.tar.gz

переходим в распакованную папку

#cd ./tsung-1.5.1

и проводим конфигурирование и установку

#./configure && make && make install

 

Также необходимо создать каталог с именем .tsung

#mkdir  ~/.tsung/

Для того, чтобы сгенерировать тестовые планы, можно воспользоваться утилитой tsung-recorder. После того, как вы делаете tsung-recorder start, на порту 8090 подымается http-прокси. В настройках системы (или браузера) пропишите прокси localhost:8090 и дальше притворитесь пользователем и прощелкайте сайт. После того этого, выполните tsung-recorder stop, и у вас появится файл вида ~/.tsung/tsung_recorder20150603-11.xml.

Выглядит этот файл приблизительно вот так.

 

 

И самое интересное, желаемая нагрузка. Tsung симулирует посещения юзеров. Следующий пример иллюстрирует 4 фазы.

Первая длится 5 минут и каждую секунду сайт посещает 1 новых пользователей (Interarrival), итого 5 минут x 5 юзеров/сек = 1500 юзеров.

Вторая фаза еще более повышает нагрузку и длится 10 минут, каждые 100 миллисекунд будет создаваться новый пользователь(Interarrival), в секунду приходит 10 юзеров, в сумме 6 000 юзеров.

Третья фаза  длится 15 минут и каждую секунду сайт посещает 10 новых пользователей(Interarrival), итого 15 минут x 10 юзеров/сек = 9000 юзеров.

Четвертая фаза длится 20 минут и каждую секунду сайт посещает 100 новых пользователей(arrivalrate), итого 20 минут x 100 юзеров/сек = 120000 юзеров.

 

<load>
 <!-- several arrival phases can be set: for each phase, you can set the mean inter-arrival time between new clients and the phasedura
 <arrivalphase phase="1" duration="5" unit="minute">
 <users interarrival="5" unit="second"></users>
 </arrivalphase>
 <arrivalphase phase="2" duration="10" unit="minute">
 <users interarrival="0.100" unit="second"></users>
 </arrivalphase>
 <arrivalphase phase="3" duration="15" unit="minute">
 <users interarrival="10" unit="second"></users>
 </arrivalphase>
 <arrivalphase phase="4" duration="20" unit="minute">
 <users arrivalrate="100" unit="second"/>
 </arrivalphase>
 <user session="rec20150603-1101" start_time="0" unit="second"></user>
</load>

Количество конкурентных пользователей можно задавать двумя способами. Interarrival. Мы указываем, через какое время создавать нового пользователя. В данном примере каждые 100 миллисекунд будет создаваться новый пользователь. Или можно это сделать по-другому, используя «arrival rate»: мы указываем, сколько пользователей создавать за единицу времени (за секунду в данном случае). Также мы можем задавать какие-то специфические сессии. Можно их встраивать в середину нагрузки для имитации запуска каких-то тяжеловесных сервисов или проверок.       Также Tsung может имитировать разные User Agent. Мы можем имитировать, в частности, разные браузеры, задав вероятность (probability) этим параметрам: вероятность присвоения какого-либо User Agent каждому пользователю. В том числе можно имитировать поисковые боты. По умолчанию, если не задавать эти параметры, им присваивается значение tsung.       После этого мы запускаем tsung start. Он проведет нагрузочное тестирование, а дальше получим результаты с помощью tsung_stats.pl   посмотрим созданную папку в папке log

#ls -l  ~/.tsung/log/

 

итого 8
drwxr-xr-x 2 root root 4096 июня 3 19:30 20150603-1930

переходим в нее

#cd   ~/.tsung/log/20150603-1930

и запускаем tsung_stats.pl

#/usr/lib/tsung/bin/tsung_stats.pl

 

 

sudo apt-get install siege
Для проверки сделаем первый тест. Будем симулировать 10 пользователей, которые безостановочно загружают главную страницу в течении 5 минут.
siege -c 10 -b -t 5m http://mysites.com/

Эмитация работы пользователя
Для того чтобы посмотреть на нагрузку создаваемою при открытии страниц сайта, мы воспользуемся логом сервера. И скопируем  из него все url запросов.

cat access.log | grep -o -P '(GET|POST) .* HTTP'| awk '{print "http:// mysites.com "$2}'| sort -u | grep -v -P -i '(admin)' >> /tmp/urls.txt

Разберем его поподробнее:

**cat access.log** - выводит лог, где на месте access.log должен быть путь к логу доступа apache
**grep -o -P '(GET|POST) .* HTTP'** - ищем с помощью регулярного выражения url
**awk '{print "http://mysites.com "$2}'** - удаляем шум, добавляем имя хоста (**http://mysites.com замените на свое**) **sort -u** - сортируем, удаляем дубликаты **grep -v -P -i '(admin)'** - фильтруем url, по которым ходить не надо с помощью регулярных выражений Для фильтрации статики, можно применить: **grep -v -P -i '\.(css|js|jpg|png|gif|txt)$' ** **>> /tmp/urls.txt** - отправляем результат в файл

В результате получаем файл, содержащий множество реальных url.  Приводим нашу команду к такому виду:

siege -c 10 -b -t 5m -f /tmp/urls.txt

Чтобы заставить утилиту брать URL из файла не последовательно, а случайно, добавьте опцию '-i':

При необходимости вы можете увеличить диапазон случайно временной задержки между отправкой запросов при помощи опции '-d'. Например, чтобы siege выдерживал случайную паузу между запросами в пределах между 0 и 5 секундами:

siege -c 10 -d 5 -b -t 5m -i -f /tmp/urls.txt
Некоторые опции:
-b - не будет делать паузу между запросами
-c - количество параллельных запросов, отправляемых за один раз
-r - количество повторов запроса
-v - показывает текущие запросы и ответы в консоли
-t - время теста, можно использовать h,m,s
-f - список URL-ов из файла
-i - брать ULR-ы из файла рандомно