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

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

Очень часто необходимо реализовать простое легкое решение, которое должно отработать довольно быстро. А с использованием технологии AJAX это стало еще актуальнее. Это может быть как скрипт автокомплита, скрипт специфического поиска, вывод информации из справочника. Ранее использовались cgi скрипты. При больших нагрузках они оказались не очень эффективными и были разработаны протоколы fcgi и scgi. Следует заметить что производительность scgi сервера довольно-таки высокоя (более 1500 запр/сек) и памяти занимает всего 600K.

Протокол Simple Common Gateway Interface (SCGI) — это протокол по взаимодействию приложений с веб (http) серверами. Большинство современных WEB-серверов (Apache/nginx/lighttpd) имеют встроенную поддержку scgi. Ниже дано краткое описание использование простой библиотечки, которая представляет собой scgi сервер.

Исходники тут.

Поучительная история о техниках оптимизации наглядно.

Техзадание

Объявим в рамках топика небольшой конкурс по архитектурно-ориентированной оптимизации программного обеспечения.
Вкратце, код состоит из пачки функций, производящих невнятные на первый взгляд манипуляции с исходными данными, и примочки-драйвера, который n раз запускает неоптимизированную версию, затем оптимизированную, сравнивает насчитанные циферки, и, в случае их совпадения, выдает отношение времени выполнения. Вот так:

Executing original code… done
Executing optimized code… done
Checking results… PASSED
Number of runs: 3
Original code average time: 11.954537 sec.
Optimized code average time: 1.052994 sec.
Speedup: 11.35

Разрешено использовать любые техники оптимизации, компилятор GCC с любыми опциями, и, скажем, сервер с двумя четырехъядерными процессорами Intel Xeon E5420 2.5 GHz.
Вот, кстати, код:

Причем стоимость этой сделки может достигать почти миллиарда долларов — в настоящее время речь идет о сумме в 900 миллионов долларов США. Это немного заниженная цена, что сейчас является скорее исключением, чем правилам. В настоящее время среди ИТ-корпораций нормой является завышение цены для понравившегося стартапа или компании.

Следующее поколение серверных процессоров SPARC T4 будет с восемью ядрами вместо 16-ти в нынешнем SPARC T3. Такое решение приняла компания Oracle, которой сейчас принадлежит микропроцессорное подразделение Sun.

SPARC T3 после своего появления в сентябре 2010 года стал первым серверным процессором с 16-ю ядрами. Большое количество потоков лучше подходит для обработки веб-запросов и других легко распараллеливаемых задач, а не для ERP-систем, на которых специализируется Oracle. Поэтому и принято решение, что в SPARC T4 (ожидается в 2011 году) количество ядер сократят, чтобы улучшить производительность каждого отдельного треда.

Поскольку новость не пробежала на Хабре, но однозначно (с) будет интересна многим:

«Видео с пользовательской конференции по Sphinx (~8часов)
http://devconf.tv/user/sphinx».

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

Тема блочного кеширования и ssi не раз проскакивала на Хабре. Ниже я представлю еще одну реализацию, использующего блочное кеширование, а также исходники фреймворка, использующего эти принципы, которые можно найти тут. А как это работает — прочитать ниже.

Руководство корпорации Intel заявило, что сейчас в лабораториях этой компании ведется разработка процессора, который содержит около 1000 дискретных вычислительных ядер. Как известно, сейчас большая часть моделей процессоров включают намного меньшее количество ядер, от двух до шести. На Хабре проскакивало сообщение о том, что был представлен экспериментальный 48-ядерный процессор для серьезных научных разработок. И вот как раз на основе этого чипа и создается новый, 1000-ядерный процессор.

Высоконагруженный проект (web-сайт) — не обязательно популярная социальная сеть, видеохостинг или MMORPG. Простейший способ резко повысить требования сайта к железу — перенести хранение сессий в БД. В этой статье мы рассмотрим способ хранить данные в БД, и при этом не жертвовать производительностью. Пожертвовав небольшим объемом ОЗУ можно прилично сэкономить процессорное время. Мы говорим о стиуации, когда недоступны memcached и другие специальные средства кэширования.

Университет штата Индиана из США и несколько партнерских организаций смогли создать и запустить в работу коммерческую сетевую магистраль с передачей данных со скоростью в 100 гигабит/сек. Стоит отметить, что испытания велись не в США, а в Германии. Кроме того, в настоящее время на основе этой сети ведется испытание в «стрессовых» условиях, если так можно выразиться, файловой системы Люстре (Lustre) (кластерная файловая система). Пока что система показывает себя отлично.

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

Так как большинство авторов не удосуживается хотя бы залезть в документацию, то обычно в таких статьях вся информация базируется на неких слухах и пересказах слухов. Эти слухи бродят по сети и поражают википедию, хабрахабр и другие уважаемые ресурсы. В результате получаются опусы вроде "Вы наверное шутите, мистер Дал, или почему Node.js" (пунктуация автора сохранена): она, в основном, верная по сути, но изобилует неточностями, содержит ряд фактических ошибок и изображает предмет с какого-то непонятного ракурса.

Мне было сложно пройти мимо статьи, изобилующей фразами вроде «эффективные реализации polling'а на сегодняшний день имеются лишь в *nix-системах» (как будто poll() есть где-то, кроме некоторых *nix). Этот пост начинался как комментарий, разъясняющий уважаемому inikulin ошибки в его статье. В процессе написания оказалось, что проще изложить предмет с самого начала, что я собственно и делаю отдельным постом.
В моем очерке нет срыва покровов или каких-то неизвестных трюков, здесь просто описываются преимущества и недостатки разных подходов человеком, который проверял, как всё это работает на практике в разных операционных системах.
Для желающих просветиться — добро пожаловать под кат.

Предлагаю решение, как быстро и просто поставить на сервере легкий фронтэнд для отдачи картинок, css-файлов и прочей статики. С лета 2002 года я для данных целей использую 0W-httpd или ZeroWait httpd, как его часто называют в разных источниках (искать что-то о нем, помимо дистрибутива, лучше по второму названию).
Установить и настроить его достаточно просто (даже слишком просто):

Если ваш проект использует подсчет кликов и на нем есть какая-либо солидная нагрузка, то вы наверно задумывались об отдельном решении.

История разработки уходит в один проект торгово-рекламной площадки, где необходимо было учитывать кол-во переходов. Было решение на РНР. Но это давало видимую задержку в 0.5-1 сек, что очень раздражало разработчиков (в частности меня) и я думаю пользователей тоже.

По этому, когда пришлось разрабатывать аналогичный проект, мне пришлось искать альтернативы.

При анализе производительности приложений с целью ее повышения, наиболее мощной из доступных является методика детального анализа циклов центрального процессора. Традиционный анализ завершения инструкций вряд ли поможет, когда мы говорим об архитектуре, применяющей переупорядочивание инструкций (Out of Order, OOO), чья основная задача и состоит в том, что бы продолжать исполнять инструкции, пока их завершение невозможно.

Продолжение статьи: часть 1, часть 2, часть 3

Продолжение статьи: часть 1, часть 2, часть 4

Продолжение статьи: часть 1, часть 3, часть 4

Адаптация программного обеспечения для эффективного использования всех доступных процессоров наиболее критична в свете намечающегося многоядерного будущего современной вычислительной техники. Кроме всех прочих препятствий, которые могут быть встречены на этом пути, существуют проблемы, связанные с совместным использованием конечной пропускной способности существующих платформ и процессоров. Правильное использование событий производительности процессора Intel Core2 позволит определить точную причину, останавливающую приложение на пути к полноценному использованию всех доступных в системе ядер.

После третьего по счёту демонтажа городского дата-центра в поисках площадки, наиболее защищённой от стихийных бедствий, мэрия американского города Альтамонте-Спрингс (Флорида) нашла необычное место — старый неиспользуемый водяной резервуар в самом центре города. Это огромный бак, который раньше вмещал 2,9 млн литров воды. Рядом с ним сделали две пристройки: одна — для сетевого оборудования, вторая — офисные помещения.

По мнению инженеров городского IT-подразделения, лучше места не найти: 20-сантиметровые стены из железобетона великолепно защищают от любого шторма.

Правда, не совсем понятно, почему сетевое оборудование поместили в пристройке, а не непосредственно в защищённом здании.