примерно вот так в 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;
оч хорошая статья, боюсь потерять на неё ссылку
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
Оригинал статьи тут, себе копирую, чтоб не потерять.
Объявляем новый 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 например для залогиненных пользователей.
Хозяйке на заметку
у сайта есть много доменов .ру .орг .ком и т.п. хочу чтоб был один и главный
в разделе server{}
пишу
[cc lang=”bash”]if ($host != ‘your_domain.com’ ) {
rewrite ^/(.*)$ http://your_domain.com/$1 permanent; }[/cc]
Кому не понятно, в первой строке смотрим если ваш домен отличается от искомого, то редиректим на искомый
Число проектов на сервере росло, а оперативная память не добавлялось так получилось что старый метод на большом числе проектов поедает много оперативной памяти. и вот пришло время разобраться с 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