Высоконагруженные системы *

Привет, %username%
Тут я хочу рассказать о том, как я настраивал кеширование на одном сервере, точнее VDS. Характеристики сервера: 2000MHz, 2GB RAM, 80Gb HDD, технология виртуализации — OpenVZ.
Было решено использовать Nginx версии 0.7.64. На сервере находилось около 200 сайтов. И несколько высоко нагруженных проектов. Вот эти самые проекты и давали ощутимые тормоза и нагрузку на сервер. Мы будем рассматривать DLE в этом примере.

Dklab Realplexor — это Comet-сервер, позволяющий держать одновремено сотни тысяч долгоживущих открытых HTTP-соединений с браузерами пользователей. JavaScript-код, запущенный в браузере, подписывается на один или несколько каналов Realplexor-а и вешает обработчик на поступление данных. Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени и с минимальной нагрузкой для сервера.

^{Хотя идейным вдохновителем Realplexor-а был предыдущий проект, dklab_multiplexor, код Realplexor-а не имеет с ним практически ничего общего. Поэтому я и решил сменить название. Несопоставимы также возможности продуктов (см. ниже), да и размер кода увеличился в 7 раз.}

Realtime-направление сейчас довольно активно развивается на Западе, и в нем особенно выделяется продукт Tornado — событийно-ориентированный веб-сервер на языке Python. Правда, Tornado — это не столько Comet-сервер, сколько инструмент, с помощью которого можно запрограммировать «в том числе» и Comet-сервер. Ключевые слова: Comet, Push Server, Long polling, JavaScript, XMLHttpRequest.

Главные преимущества Realplexor-а:

• простота использования: наличие API для JavaScript, API для PHP (в будущем — и для других языков);
• простота конфигурирования;
• широкий функционал (либо отстутствующий, либо недоступный напрямую в аналогах).

Лучше один раз увидеть...

Я сделал отдельную онлайн-песочницу, чтобы продемонстрировать функционал нового Realplexor-а и то, для чего вообще нужны Comet-серверы (кстати, это физически тот же самый демон Realplexor-а, что использует мой новый стартап РуТвит). Песочница реализует что-то типа многоканального чата: зайдя, вы получите как будто бы 2 независимых «браузера», запущенных на разных компьютерах.

• Верхний «браузер» отображает каналы — в них моментально появляются новые сообщения, как только кто-то их туда отправляет на стороне сервера. Конечно же, эту страницу могут просматривать одновременно сотни тысяч пользователей, и они все будут видеть одно и то же (реализовано с использованием Realplexor JavaScript API). Можно «на лету» добавлять новые каналы (подписка) или скрывать уже имеющиеся (отписка).
• Нижний браузер содержит формы, позволяющие добавлять сообщение в произвольный канал, указав его имя. Форма AJAX-ом отправляется на сервер, и уже там PHP-скрипт записывает в Realplexor полученный текст через PHP API. (И да, так можно чатиться.)

По умолчанию на странице открыто 3 канала с именами Alpha, Beta и RuTvit. Но, конечно, вы можете закрыть эти каналы и открыть новые. Вот, например, страница с единственным открытым каналом по имени Habrahabr: http://rutvit.ru/realplexor/demo?ids=Habrahabr.



Песочница демонстрирует следующие функции Realplexor-а:

PHP-FPM — патч к PHP, предоставляющие альтернативный интерфейс FastCGI. Обычно используется с nginx в проектах с высокими нагрузками или дефицитом ресурсов. Для удобной и упрощенной инсталляции мы собрали PHP-FPM в пакет для Debian 5 Lenny. Последнюю пару недель тестировали и тюнили, сейчас выложили в публичный доступ. Над пакетами в поте лица трудился viliar, которому дружно направляем за это благодарности и карму. Багрепорты и замечания приветствуются, лучше комментами к посту.

Инструкция по установке

Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом

Заметка посвящена не столько возможным методам защиты (о них уже было много написано), сколько обзору небольшого списка для быстрой проверки при подготовке к возможных скачкам посещаемости. Судя по статистике нагрузки на электронные магазины на прошлой неделе (когда начался рождественский сезон продаж на Западе), даже для крупных магазинов время ответа может колебаться на 20%, что же говорить о менее крупных веб-сайтах?

Такую проверку обязательно нужно проводить перед выпусками новых продуктов, а также перед сезоном массовых покупок (для России это время в канун Нового Года и Рождества). Итак, с чего начать?

26 октября 2009 года состоялась SpeedGeeks L.A. в Южной Калифорнии.
Тематика — достижение высокой производительности веб-сайтов.

Вашему вниманию хотелось бы представить видео и презентации. Которые недавно были опубликованы.

Videos All

Вчера опубликован 34-й рейтинг мощнейших суперкомпьютеров мира Top 500, в котором произошёл ряд изменений. Совокупная мощность 500 лучших суперкомпьютеров мира за полгода выросла с 22,6 до 27,6 петафлопсов. И сменился лидер: на первое место вышел суперкомпьютер Jaguar (1,76 петафлопса), после апгрейда в Окриджской национальной лаборатории США.

В десятку Top 500 впервые попал и китайский суперкомпьютер, причём сразу на пятое место. Прорыв совершила машина Tianhe-1 (средняя производительность 563,1 терафлопса, пиковая — 1,2 петафлопса) на гибридной основе Intel-AMD. Вот оно, детище Национального университета оборонных технологий Китая.



За пару недель до публикации Top 500 китайцы уже нацелились на третье место и заявили, что стали второй страной в мире, которой покорился рубеж в 1 петафлопс. Но они жёстко просчитались по обоим пунктам. Место заняли лишь пятое, да и 1 петафлопс взяли одновременно с немцами.

Начиная с версии 0.8.11 в nginx появилась новая возможность для раздачи статики — использование AIO (Asyncronous Input-Output — неблокирующий ввод-вывод) для Linux и FreeBSD.

Чем это событие знаменательно? До этого момента nginx использовал неблокирующий режим только при работе с сетью — любая работа с файлами блокировала рабочий процесс. К чему это приводило? Если у вас есть много разного контента, который не весь находится в кэше ОС (фотохостинг, etc) — то рано или поздно все 50, 150, 200 процессов будут ждать дисковые операции и не смогут обслужить нового клиента — даже если нужный ему контент можно отдать из файлового кэша или запросить с бэкенда.

Разработчики из компании Google только что объявили, что работают над новым сетевым протоколом SPDY (читается как SPeeDY, то есть «быстрый»), который должен проапгрейдить протокол HTTP и значительно повысить скорость работы всех типов соединений.

SPDY позволяет вдвое уменьшить задержку (latency) при работе через HTTP. Делается это за счёт трёх методов:

1) мультиплексирование запросов;
2) расстановка приоритетов для запросов;
3) сжатие заголовков HTTP.

Чтобы продемонстрировать все возможности SPDY, инженеры Google подняли тестовый веб-сервер и выпустили специальную версию браузера Chrome.

По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.

Здравствуй, уважаемое хабрасообщество.

В предыдущих статьях мы рассмотрели OpenCL в целом, потом подробно вникли в суть стандарта и разобрали на каких идеях базируется эта технология.
OpenCL. Что это такое и зачем он нужен? (если есть CUDA)
OpenCL. Подробности технологии
Теперь настало время пощупать эту технологию живьем.

Здравствуй, уважаемое хабрасообщество.

В предыдущей статье про OpenCL был сделан обзор этой технологии, возможностей, которые она может предложить пользователю и ее состояния на настоящий момент.
Теперь рассмотрим технологию более пристально. Постараемся понять, как OpenCL представляет гетерогенную систему, какие предоставляет возможности по взаимодействию с устройством и какой предлагает подход к созданию программ.

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Год назад Ян Кларк, известный как создатель распределённой сети Freenet, выступил с ещё одной революционной инициативой. Он предложил создать новый язык программирования для распределённых вычислений, логика которого будет идти «не от данных, а от вычислений», чтобы любые написанные на таком языке программы можно было естественном образом распараллеливать по неограниченному количеству процессоров и серверов. Это очень важная задача, если учитывать повсеместный переход на распределённые вычисления. И до сих пор нет нормального фреймворка для создания распределённых программ.

Як Кларк сделал на базе Scala 2.8 первый прототип языка Swarm. Вот исходные коды и инструкция по установке.

Здравствуй, уважаемое хабра-сообщество.

Многие, наверное, слышали или читали на хабре об OpenCL – новом стандарте для разработки приложений для гетерогенных систем. Именно так, это не стандарт для разработки приложений для GPU, как многие считают, OpenCL изначально задумывался как нечто большее: единый стандарт для написания приложений, которые должны исполняться в системе, где установлены различные по архитектуре процессоры, ускорители и платы расширения.

Давление на Pirate Bay и другие торрент-трекеры приносит мало пользы в святом деле борьбы с пиратским ПО. Антипиратская компания V.I. Labs провела исследование и выявила, что результатом борьбы с торрентами стала лишь миграция вареза на анонимные файлохостинги. Для проверки эксперты составили список софта от 43 производителей, и 100% позиций этого списка нашлось на RapidShare.

Безусловное лидерство по количеству вареза принадлежит гиганту RapidShare, который уже вышел на 17 место среди крупнейших сайтов интернета. Официальный представитель RapidShare в недавнем интервью NY Times призналась, что их хранилище уже разрослось до 10 петабайт. И это несмотря на то, что по просьбам правообладателей они удаляют 1-2% всех файлов, загружаемых ежедневно (кстати, некоторым правообладателям RapidShare даёт прямой доступ к своей базе, и те могут мониторить загрузки в реальном режиме времени и удалять всё что хотят).

В пиковые моменты «Рапидшара» держит до 3 млн одновременных подключений (скачиваний и загрузок). По оценке аналитической компании Ipoque, один этот сайт генерирует примерно 5% всего трафика в интернете.

Dklab_multiplexor — это инструмент, который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Например, если на вашем сайте находится одновременно несколько сот тысяч посетителей, каждый из них может быть связан с сервером постоянным соединением, установленным из JavaScript. Это например, полезно при организации онлайн-чатов или мгновенных уведомлений.

Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях). Это лишь простейший инструмент, который наконец-то дошли руки опубликовать.

Зачем это нужно?

Предположим, посетители вашего сайта могут посылать друг другу сообщения. Если получатель в момент отправки находится на сайте (просматривает какую-либо страницу), ему немедленно выдается уведомление (всплывающее окошко на JavaScript).

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

Сегодня мы продолжим исследования различных новых и не очень технологий, необычного их применения или просто оригинальных вещей. Возможно, вы вспомните, я когда-то писал о проекте распределённого кеша EHcache для платформы Java. Сегодня настало время продолжить эту тему, однако в другом ракурсе — в виде отдельного RESTful сервера.

Инженер из компании Google весьма критически отозвался о технологиях Microsoft в области распределённой вычислительной инфраструктуры для веб-приложений.

Маленький скандальчик случился на конференции Structure 09, которая посвящена облачным вычислениям. Всё началось с выступления Наджама Ахмада (Najam Ahmad), главного менеджера по глобальным сетевым сервисам Microsoft. Он подробно рассказал, как Microsoft пытается увеличить производительность множества своих сервисов. Мол, проблема в огромном их количестве, так что невозможно подобрать настройки так, чтобы все эти сервисы одинаково эффективно работали на одной платформе. Приходится фрагментировать инфраструктуру, ставить разные серверы с разными настройками для отдельных приложений, таких как Messenger или Virtual Earth, и оптимизировать их по отдельности. Он подробно рассказал, как тщательно они сейчас оптимизируют Virtual Earth.

Сразу после этого слово взял Виджай Гилл (Vijay Gill), старший инженер по архитектуре из Google, и, как говорится, пропесочил конкурента по полной программе.

Привет. Сейчас я расскажу вам о механизме IO Completion Ports в Windows. Разработчики описывают порт завершения как «средство, повышающее производительность приложений, часто использующих операции ввода/вывода». В общем-то, они и не врут, поэтому IOCP часто используют при написании масштабируемых серверных приложений. Однако же считается, что порт завершения — тема мудреная и тяжелая для понимания.

Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

Wordpress является сейчас наиболее популярной платформой для одиночного хостинга блогов. Ряд хостинг-провайдеров уже даже предлагают площадки с предварительно установленным Wordpress, а в большом количества изданий рассуждают, как лучше заработать на новом блоге или правильно его использовать. Я собираюсь осветить один из основных вопросов, встающих перед администраторами блогов: как сделать так, чтобы сайт быстро работал. Нижеизложенный материал рассчитан на максимально широкую аудиторию пользователей.

Основные положения

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

• База данных
• Компиляция серверных скриптов (PHP)
• Статические страницы
• Клиентская составляющая