Трансформация и перевод на другие языки web-сайтов на лету при помощи Nginx

Nginx
Как и в прошлый раз мы будем трансформировать сайт example.com в example.ru. Не буду рассказывать о настройке и установке Nginx (об этом много статей), а лучше расскажу о конкретных полезных настройках.
Читать дальше

Установка и настройка: Nginx + php5-fpm

Nginx
В данной заметке, будет показано как поставить связку Nginx + php5-fpm (php5.3) на Debian Lenny и настроить безопасную конфигурацию.

Установка и настройка

Важно: все команды от root'а.
Добавляем репозитарии и генерируем ключи:
echo "deb http://backports.debian.org/debian-backports lenny-backports main" >> /etc/apt/sources.list
echo "deb http://php53.dotdeb.org stable all" >>   /etc/apt/sources.list
gpg --keyserver keys.gnupg.net --recv-key 89DF5277 && gpg -a --export 89DF5277 | apt-key add -

Обновляем:
aptitude update


Читать дальше

Модуль ustats: статистика запросов к бэкендам

Nginx
Приветствую!

В этой статье речь пойдет о новом модуле для nginx'а, цель которого — сбор и предоставление пользователю статистики обращений сервера к бэкендам. Под катом — подробности, примеры использования, скриншоты, ссылки, а также история создания.
Читать дальше

Используем Nginx, как кеширующий сервер

Nginx
В этой статье рассмотрим применениt Nginx’a в качестве кеширующего сервера. Подробно о HTTP кеширования написано в статьях о продвинутом кеширующем сервере Varnish. Сразу следует отметить, что Nginx полностью не заменяет Varnish по функционалу и возможностям, но тем не менее продставляет очень хорошое решение. Учитывая великолепную работу этого Web-сервера, наличие функциональности кеширования делает возможным подключить ее к своему сайту буквально за 2 минуты.

Что кешировать?

В предыдущих статьях уже неоднократно упоминалось про суть HTTP кеширования. Если не учитывать более сложных случаев, когда нужно учитывать персонализацию страниц, почти на всех сайтах можно кешировать странички для неавторизованных пользователей. Этот метод хорошо подойдет для информационных ресурсов (например, для этого блога).

Самый простой случай — кешировать страницы для неавторизованных пользователей. Время кеширования обычно выбирают небольшое — 5…10 минут. Тем не менее, при большой нагрузке, это может сэкономить огромное количество ресурсов.


Читать дальше

Nginx + Memcached + SSI - кеширование страниц и блоков (partials)

Nginx
В одной из предыдущих статей мы рассмотрели, каким образом можно реализовать кеширование страниц с помощью Varnish и ESI. В этой статье рассмотрим альтернативное решение — на основе двух суперзнаменитых продуктов — nginx и memcached.

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

Зачем нужно кешировать страницы?

Довольно детально принципы кеширования страниц и блоков были рассмотрены в предыдущей статье (Varnish + ESI).

В качестве краткого повторения, несколько основных идей и преимуществ кеширования на уровне странц:

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


Читать дальше

Используем Nginx как “long polling” (Comet) сервер

Nginx
Принцип “Long Polling” (или “Comet“) позволяет сделать возможным установление постоянного соединения клиента с Web приложением и также периодичной отправки данных клиенту в рамках этого соединения (без необходимости клиента постоянно делать HTTP запросы для проверки новых данных). Другими словами, эта модель позволяет реализовать постоянные HTTP соединения для получения данных порциями. Наиболее популярное применение — чаты, твиттеры и другие live-updated потоки — клиент постоянно “слушает” сервер на предмет появления новых сообщений, и как только новые сообщения появляются — они мгновенно доставляются ему.

Сам принцип не несет в себе инноваций в HTTP протоколе, т.к. этот подход реализуем обычными средствами. Проблема заключается в том, что стандартное решение — установка постоянного соединения с обычным Web сервером (а значит и с обслуживающей платформой, например php-бекендом) — крайне ресурсоемкое и не применимо на практике. Другой подход — постоянно опрашивать приложение на предмет появления новых данных является еще более ресурсоемким.

Решением этой проблеммы стали т.н. HTTP-PUSH (или comet) сервера, позволяющие облуживать огромное количество постоянных соединений эффективно расходуя ресурсы. Как они устроены и как применяются на практике?

Читать дальше

Nginx Log Analyzer

Nginx
Nginx Log Analyzer — небольшая утилита для анализа логов nginx. Полезный инструмент для обнаружения слабых (а точнее медленных) мест Вашей Web системы, если Вы пользуетесь этим популярным Web-сервером. Использование этой утилиты полезно для оценочного отлавливания медленных скриптов (и не только скриптов).

Читать дальше

apache + nginx + gzip_static + yuicompressor

Руководство
В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

Nginx

Nginx – сервер легкий; он запускает указанное число процессов (обычно число процессов = числу ядер), и каждый процесс в цикле принимает новые соединения, обрабатывает текущие. Такая модель позволяет с низкими затратами ресурсов обслуживать большое количество клиентов. Однако, при такой модели, нельзя выполнять длительные операции при обработке запроса (например mod_php), т.к. это по сути повесит сервер. При каждом цикле внутри процесса по сути выполняются две операции: считать блок данных откуда-то, записать куда-то. Откуда-то и куда-то – это соединение с клиентом, соединение с другим веб-сервером или FastCGI-процессом, файловая система, буфер в памяти. Модель работы настраивается двумя основными параметрами:


Читать дальше

Модуль проверки на Accept: image/*

Nginx
Суть идеи в том, что если в заголовках браузера присутствует Accept: image/* то переменная $isaccept устанавливается в 1.

Как у нас часто водится, за работу не заплатили, так что модуль может принадлежать всем и каждому (с сохранением авторских прав). Лицензия BSD. Исходники здесь

Проверку осуществлял черезе лог, часть конфига:

http {

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" accept=$isaccept ';

access_log logs/access.log main;
error_log logs/error.log debug;
....
}


некоторый вывод лога из разных браузеров:

127.0.0.1 - - [30/Oct/2010:03:00:58 +0400] "GET / HTTP/1.1" 200 151 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ru-ru) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19" "-" accept=0 
127.0.0.1 - - [30/Oct/2010:03:02:53 +0400] "GET / HTTP/1.1" 200 151 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ru; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19" "-" accept=0 

127.0.0.1 - - [30/Oct/2010:03:03:36 +0400] "GET / HTTP/1.0" 200 151 "-" "Lynx/2.8.6rel.5 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8m" "-" accept=0 
127.0.0.1 - - [30/Oct/2010:03:04:19 +0400] "GET / HTTP/1.1" 200 151 "-" "HTTP%20Client0.9.1 CFNetwork/438.14 Darwin/9.8.0 (i386) (MacBookPro2%2C1)" "-" accept=1


модуль можно легко доработать до анализа любых заголовков и их значений. Кто угадает какие строки надо изменить?

Установка: nginx + php-cgi + mysql + eaccelerator + memcache на Debian 5.0 «lenny»

Debian
Данная заметка является шпаргалкой для новичков в установке нормально работающего комплекса, описанного в заголовке. Все пункты установки протестированы несколько раз на разных vds, поэтому проблем с нехваткой чего-то быть не должно, как это обычно бывает, когда ставишь что-то по мануалам, надерганных из разных источников. Подробно описания настроек и «тюнинга» в заметке нет, т.к. это всё очень индивидуально и требует понимания что, как и зачем делается, а это невозможно охватить в одной даже очень большой шпоре. :)

Перво-наперво обновляем список пакетов:
apt-get update

Ставим необходимое для ручной установки и некоторых других хитрым манипуляций:
apt-get install build-essential

NGINX


Ставим библиотеки, необходимые для установки nginx в той конфигурации, которую мы будем ставить (pcre обязательная всегда, ssl — опционально, если конфигурируем nginx с ней):
apt-get install libpcre3-dev
apt-get install openssl
apt-get install libcurl4-openssl-dev

В пакетах Дебиана, к сожалению, в стабильном варианте валяется очень старая версия nginx, поэтому будем ставить сервер вручную. Заходим в темп:

Читать дальше