Re: Проблема кеширования медленного удаленного фронтэнда

Пн Июл 11 17:24:32 UTC 2011

1)  канал 512к - это не НАСТОЛЬКО плохо, имхо, у вас просто неоптимально
сделанный сайт. дайте адрес боевого сайта, хочу там кое-что посмотреть ? ну
сколько туда абитуриентов зайдет ? даже 10 одновременно - это фигня

по мелочам

2) вы не указали gzip_min_length, на маленьких объектах у вас будет
увеличение размера, пропишите, например, 500

3) отдавать gzip статикой - это актуально при больших потоках данных. одно
ядро прекрасно жмет на уровне компрессии 6 со скоростью 24 мегабайта в
секунду. с вашими каналами можно не заморачиваться )) причем, если жмется
потоком (от апстрима), то диск не нагружается, а если отдавать
компресованную статику, то нагружается.

4) на свежих версиях nginx можно писать (причем, это разрешает отдачу
сжатого контента в сторону MSIE6sp2):

gzip_disable msie6;

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

8 июля 2011 г. 22:28 пользователь burguyd <nginx-forum на nginx.us> написал:

> Приветствую всех.
> Кротко опишу проблему.
> В ВУЗе, где я работаю, есть сайт.
> Расположен он на сервере в DMZ локальной
> сети. Исходящий канал в интернет всего
> 0,5 Мбит/с (да такой ужас).  Веб сервер
> смотрит в интернет одним интерфейсом и
> в локальную сеть другим.
> Конфигурация сервера: FreeBSD 8.2, Apache 2.2, php
> 5.2, mysql 5.1. Сам сайт писан на drupal.
> У сайта есть несколько особенностей:
> Первая собенность в том, что его очень
> интенсивно используют юзеры локальной
> сети. Постоянно добавляют и
> редактируют контент. Но т.к. в локальной
> сети коннект 100 Мбит/с, чувствуют они
> себ достаточно комфортно.
> Вторая особенность в том, что во время
> вступительной кампании внешний
> траффик на сайт резко возрастает.
> Связано это с тем что в это время
> абитуриенты ломятся познакомится с
> ВУЗом и мониторят проходной бал на свои
> специальности, который меняется в
> реальном времени на сайте.
> Из-за значительной нагрузки и узкого
> канала в интернет у внешних
> пользователей сайт практически не
> грузится.
> Возможности расширить канал пока нет.
> Мы придумали решение - арендоваnm VPS и
> повесить на него фронтэндом nginx. Идея
> состояла в том, чтобы nginx сделал себе
> полный кеш сайта, и отдавал его, не
> напрягая фронтэнд.
> Так и сделали. Однако ощутимого
> прироста быстродействия не ощутили
> (проверяли с помощью loadimpact).
> В связи с этим у меня несколько
> вопросов.
> 1.  Правильной ли дорогой идем, товарищи?
> Или есть более изыщное решение.
> 2. Как заблаговременно сделать
> локальный кеш на сервере фронтэнде и
> синхнонизировать его скажем раз в
> пол-часа?
> 3. Каз сделать локальный .gz кеш на
> сервере фронтэнде, чтобы всю статику
> пусть и зазипованную не нянуть с
> удаленного сервера, а складировать у
> nginx'a локально и оттуда отдавать.
> Спасибо всем кто дочитал. Надеюсь на
> вашу помощь и снисходительность.
> Конфиг nginx :
> user _nginx;
> worker_processes  1;
> error_log  /var/log/nginx/error.log notice;
> events {
>    worker_connections  1024;
>    use kqueue;
> }
> http {
> include       mime.types;
> proxy_pass_header Cookie;
> proxy_cache_path /var/nginx/cache
> levels=1:2 keys_zone=my_cache:1024m max_size=3092m
> inactive=1d;
> proxy_cache my_cache;
> proxy_cache_valid 200 3h; # раз в три часа будем
> позволять себе обновлять кеш :)
> proxy_cache_valid any 0; # не кешируем 500 и 400
> ошибки
> proxy_cache_use_stale updating error timeout invalid_header http_500
> http_502 http_503 http_504 http_404; # если ваш скрипт
> отдал одну из описанных ошибок, ис
> пользовать вариант из кеша, если он
> есть, даже если он уже заэкспайрился
> proxy_cache_key "$scheme$proxy_host$uri$is_args$args$cookie_sid";
> proxy_redirect off;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> client_max_body_size 10m;
> client_body_buffer_size 128k;
> proxy_connect_timeout 1500;
> proxy_send_timeout 1500;
> proxy_read_timeout 1500;
> proxy_buffer_size 4k;
> proxy_buffers 4 32k;
> proxy_busy_buffers_size 64k;
> proxy_temp_file_write_size 64k;
> proxy_temp_path /var/nginx/proxy_temp;
> default_type  application/octet-stream;
> reset_timedout_connection  on;
> sendfileon;
> tcp_nopush      on;
> tcp_nodelay     on;
> keepalive_timeout  65;
> gzip  on;
> gzip_static on;
> gzip_http_version   1.1;
> gzip_proxiedexpired no-cache no-store private auth;
> gzip_disable"MSIE [1-6]\.";
> gzip_vary   on;
> gzip_comp_level 3;
> gzip_proxied any;
> gzip_types text/plain text/css application/x-javascript text/xml
> application/xml application/xml+rss text/javascript;
>    upstream backend {
>    server 75.205.198.2:80;
>  }
>       listen 80 default;
>       server_name localhost;
>       deny all;
>       }
> server {
> listen       80;
> server_name  www.site.ru site.ru;
> location / {
> proxy_pass http://backend;
> access_log off;
> }
> location ~ /\.ht {
> deny  all;
> }
> }
> }
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?21,212034,212034#msg-212034
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20110711/c96fc575/attachment.html>