Архивы: nginx

Nginx сжатие для google pagespeed

примерно вот так в nginx.conf

gzip on;
gzip_disable "msie6";

gzip_comp_level 6;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/js
    text/xml
    text/javascript
    application/javascript
    application/x-javascript
    application/json
    application/xml
    application/xml+rss;

Кэширование Nginx

оч хорошая статья, боюсь потерять на неё ссылку
http://devacademy.ru/posts/razbiraemsya-v-http-proksi-nginx-balansirovke-nagruzki-buferizatsii-i-keshirovanii/
это перевод вот этой статьи
https://www.digitalocean.com/community/tutorials/understanding-nginx-http-proxying-load-balancing-buffering-and-caching

Кэширование nginx: Мониторинг

Оригинал статьи тут, себе копирую, чтоб не потерять.

Объявляем новый log_format в nginx.conf:

log_format rt_cache '$remote_addr - $upstream_cache_status [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

в server разделе вашего vhost:

И замените

access_log /var/log/nginx/example.com.access.log;
На вот такое:

access_log /var/log/nginx/example.com.access.log rt_cache;

Или можно поступить как-то так.

access_log /var/log/nginx/example.com.access.log;
access_log /var/log/nginx/example.com.cache.log rt_cache;

обратите внимание, что в разных логах различаются имена файлов.

Анализируем логи:

HIT vs MISS vs etc

Можно посмотреть статистику из access.log:

awk '{print $3}' access.log | sort | uniq -c | sort -r

Sample output:

800 HIT
779 -
392 BYPASS
19 EXPIRED
14 MISS

Важно: тире (“-“) означает прочие коды return 403, return 444, и возможно всякие файлы, что не попали к нам в локейшин в котором действует кэш.

Посмотреть список уролов с MISS

awk '($3 ~ /MISS/)' access.log | awk '{print $7}' | sort | uniq -c | sort -r

BYPASS Requests URLs

awk '($3 ~ /BYPASS/)' access.log | awk '{print $7}' | sort | uniq -c | sort -r
MISS v/s BYPASS

MISS – Это промахнулись мимо кэша, возможно это первое обращение, после которого кэш создаётся.

BYPASS – это пропуск к бэкэнду минуя кэн nginx например для залогиненных пользователей.

Редирект на nginx

Хозяйке на заметку

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

в разделе server{}

пишу

[cc lang=”bash”]if ($host != ‘your_domain.com’ ) {
rewrite ^/(.*)$ http://your_domain.com/$1 permanent; }[/cc]

Кому не понятно, в первой строке смотрим если ваш домен отличается от искомого, то редиректим на искомый

Запускаем Django на uwsgi + nginx

Число проектов на сервере росло, а оперативная память не добавлялось так получилось что старый метод на большом числе проектов поедает много оперативной памяти. и вот пришло время разобраться с uwsgi – это WSGI сервер с некоторыми фенями, сам умеет пере запускаться когда обновляется код проекта (как в devserver) умеет сам убивать потомком если они начинают “тупить”.

Теперь по порядку
[cc lang=”bash”]aptitude install python-pip build-essential python-dev libxml2-dev
easy_install install uwsgi[/cc]

Для виртуал хоста используем примерно вот такой конфг, найденный на просторах тырнета

[cc lang=”bash”]
server {
listen 80;
listen 443;

# указываем свой домен
server_name odmin4eg.org www.odmin4eg.org;

# здесь мы задаем абсолютные пути к логам.
# как я упоминал уже выше, каталог с логами у меня хранится в каталоге
# с проектом, поэтому пути следующие:
access_log /home/odmin4eg.org/logs/nginx_access.log;
error_log /home/odmin4eg.org/logs/nginx_error.log;

# ниже указывается каталог с django-проектом. как я указывал выше,
# я храню его в подкаталоге www, поэтому путь такой:
root /home/odmin4eg.org/www/;

location /
{
# ниже надо указать путь к socket’у, при помощи которого
# nginx и uwsgi будут сообщаться.
# в данном случае путь это ‘/var/tmp/odmin4eg_uwsgi.sock’
uwsgi_pass unix:///var/tmp/odmin4eg_uwsgi.sock;
include uwsgi_params;

# 8 — число буфферов
# 128k — размер буфера
# фактически, мы сможем передать от Django в nginx только 1 мб информации.
# играйтесь с этим значением при поднятии своего проекта
uwsgi_buffers 8 128k;
}

# ниже описывается директория со статическими файлами проекта (css,js,etc)
# /static/ — это STATIC_URL, который вы должны посмотреть в
# в settings.py своего django проекта.
location /static/ {
# а вот здесь указываем абсолютный путь к директории со
# статическими файлами
alias /home/odmin4eg.org/www/static/;
expires 30d;
}
# Это уже у кого как статика для админки
location /media_admin {
alias /usr/local/lib/python2.6/dist-packages/django/contrib/admin/media;
}

}[/cc]

Дальше конфигурируем uwsgi – создаём файл
/home/odmin4eg.org/www/uwsgi.yaml
[cc lang=”bash”]
uwsgi:
# указываем socket, при помощи которого будет происходить
# взаимодействие между nginx и uwsgi
socket: /var/tmp/odmin4eg_uwsgi.sock
# здесь указываем путь к django-проекту
pythonpath: /home/odmin4eg.org/www
# устанавливаем переменную окружения, которая хранит имя settings файла
env: DJANGO_SETTINGS_MODULE=settings
# это имя модуля, который будет запускаться на выполнение
# в такой постановке, будет запускаться wsgi.py из директории
# указанной выше в ‘pythonpath’
module: wsgi
# путь к лог файлу
daemonize: /home/odmin4eg.org/logs/uwsgi.log
# прочие настройки, значения который можно посмотреть на сайте uWSGI
max-requests: 5000
buffer-size: 32768
harakiri: 30
reload-mercy: 8
master: 1
no-orphans: 1
# если выполнить команду “touch <имя ниже указанного файла>“,
# то произойдет перезапуск uwsgi демона.
touch-reload: /home/odmin4eg.org/uwsgi[/cc]

ну и создаём файлик который будем пинать для перезагрузки демона
[cc lang=”bash”]touch /home/odmin4eg.org/uwsgi[/cc]

ну и последнее осталось написать wsgi.py и положить его в каталог указанный в pythonpath (i.g., в /home/odmin4eg.org/www). wsgi.py выглядит до безумия просто:

[cc lang=”python”]
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()[/cc]

запускаем
[cc lang=”bash”]
service nginx restart
uwsgi -y /home/odmin4eg.org/conf/uwsgi.yaml[/cc]

У меня всё поехало после этого.
по мативам kalnitsky.org