Из документации о Blitz: Чрезвычайно быстрый и мощный шаблонизатор для очень больших интернет-проектов.

Приведу несколько фактов:

1. Это шаблонизатор используемый Хабром;
2. Этот шаблонизатор используется на высоко-нагруженных проектах, он написан на C, подключается как расширение PHP;
3. Его скорость сопоставима с самим php (бенчмарк под катом);
4. Верстальщики будт счастливы, так как в шаблонах нет логики приложения, нет циклов, ветвлений и т.д.;
5. Один из его авторов Алексей Рыбак fisher.

Мониторинг memcached — дело далеко не последней важности. Как на этапе тестирования, так и на этапе сопровождения уже работающего нагруженного ресурса. Средств «из коробки» для этого не так уж и много, а если вы работает с PHP, то зачастую ограничиваетесь средствами memcache (или memcached), а именно

Memcache::getStats()

$memcache = new Memcache;
$memcache->connect('localhost',11211);
print_r($memcache->getStats());


что возвращает типичный набор данных

Array ( [pid] => 25722 [uptime] => 4487286 [time] => 1308323074 [version] => 1.2.2 [pointer_size] => 64 [rusage_user] => 2646.005365 [rusage_system] => 17108.873237 [curr_items] => 37761 [total_items] => 10764857 [bytes] => 140070186 [curr_connections] => 5 [total_connections] => 17360659 [connection_structures] => 31 [cmd_get] => 89154830 [cmd_set] => 10764857 [get_hits] => 83452021 [get_misses] => 5702809 [evictions] => 0 [bytes_read] => 3527860756618 [bytes_written] => 4234517241183 [limit_maxbytes] => 2147483648 [threads] => 1 )

Вроде всё хорошо.
Мы видим, что у нас занято 133,5 Mb из 2 Gb выделенных под memcached и около 37 тыс. ключей.
Hits к misses относиться как 83/5, что тоже не внушает опасений.

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

1) Кэширование результатов выполнения запросов

• плюсы: высокая скорость доступа к данным
• минусы: требует компромисса между актуальностью данных и скоростью доступа, т.к. данные в кэше могут устареть, а удалять старые данные из кэша с последующим кэшированием новых — это дополнительные задержки и нагрузка на систему

2) NoSQL решения

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

Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).

Я продолжаю небольшой цикл статей на тему In-memory-data-grid.
В первой статье была раскрыта сама концепция IMDG без конкретных примеров и деталей реализации. Сегодня мы копнем чуть глубже.

Флеш-память уже производит в ЦОДах революцию: перенос данных на flash — следующий шаг в развитии многих централизованных ИТ-систем. Да, она довольно дорогая, обладает своими особенностями — и все же сегодня вопрос для администраторов ЦОДов уже не в том, использовать флеш-память или нет, а в том, как и когда это делать.



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

Ниже – советы, как определить, пора ли переходить на эту технологию или еще нет.

Вдохновение.

Пока 55% ненавидит…

А я выбрал «другое». Потому что люблю. Но не за то, что считаю удобнее других, а за то, что…

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

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

Базовой информации о самой системе много, в том числе и на Хабре: здесь, здесь и здесь. Мы же постарались собрать в одной статье несколько «рецептов» использования Puppet под действительно большими нагрузками — в «боевых условиях» Badoo.

О чём пойдет речь:

• Puppet: ликбез;
• кластеризация, масштабирование;
• асинхронный Storeconfigs;
• сбор отчётов;
• анализ полученных данных.

6 декабря в Москве состоится High Performance Conference 3.0 (http://hpc.itmozg.ru/) – третья конференция по высоконагруженным системам от ITmozg.

В программе – выступления экспертов Parallels, Microsoft Russia, Мамба, Jelastic Russia и часовая сессия вопросов-ответов.

В рамках конференции, я выступлю с докладом о применении облачной платформы Windows Azure для высоконагруженных задач. В рамках доклада будут рассмотрены кейсы проектов уже работающих с высокими нагрузками на Windows Azure. Рассмотрена архитектура обеспечения отказоустойчивой трансляции Олимпийских Игр 2012 года в Лондоне на базе Windows Azure Media Services.

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

В программе конференции (http://hpc.itmozg.ru/program):

Вчера около 22:00 по московскому времени криптохостинг Mega открылся для всех желающих. С первых минут на него хлынул поток пользователей. «Я никогда не видел ничего подобного, — пишет Ким Дотком, — с нуля до 10 Гбит/с заполнение канала за десять минут».

В первый же час на сайте зарегистрировалось более 100 тыс. пользователей. «Самый успешный стартап в истории интернета?», — пошутил Ким Дотком на этот счёт в твиттере. Через два часа после запуска сайт достиг отметки в 250 тыс. зарегистрированных пользователей. Сейчас он работает с перебоями. Даже если вы сможете на него зайти, то закачать файлы туда затруднительно.

В любом случае, запуск проекта можно признать успешным. Ким Дотком проснулся три часа назад — и сразу организовал пресс-конференцию.

Только что получил анонс, что на AWS стали доступны инстансы нового поколения Amazon EC2 High I/O. Данные типы инстансов базируются на новом поколении процессоров Intel Ivy Bridge. Каждый виртуальный CPU (vCPU) соответствует одному аппаратную потоку исполнения (hyperthread) процессора Intel Xeon E5-2670 v2 (Ivy Bridge).

Вот табличка:

Наша компания довольно давно занимается разработкой больших веб-приложений на Python / Django. В рунете крайне мало информации об этом замечательном языке программирования и фремворке на его основе. Мы решили исправить эту ошибку и рассказать о популярных высоконагруженных сайтах на этой технологии, а также дать много интересных технических подробностей. Для удобства сравнения сайтов между собой мы приводим еще и немного статистики к каждому из проектов. В целом сайтов на Python / Django, конечно, очень много в мире, мы охватим только наиболее интересные по нашему мнению.

Небольшая таблица известных проектов (на основе данных http://builtwith.com/), кликабельно:

Как только я заинтересовался Netmap’ом, меня сразу же стало одолевать любопытство, сколько пакетов в секунду можно будет «выжать» на обычном железе в режиме генерации пакетов и/или в режиме приёма и фильтрации пакетов? С какой производительностью можно будет фильтровать трафик различных, популярных на сегодняшний день атак и какие при этом будут потери пакетов.



Данные, которые показывает автор Netmap Luigi Rizzo весьма впечатляют. Как известно, по опубликованным Luigi тестам, Netmap легко генерирует 14Mpps и позволяет «поднять» поток в 14Mpps из сетевого кабеля в userspace, используя только одном ядро процессора Core i7. Стало интересно применить эту технологию в фильтрах очистки трафика.
Итак, на прошедшей в сентябре выставке InfosecurityRussia 2013 мы представили стенд, на котором по запросу всех желающих генерировали различные атаки и демонстрировали защиту от них, собирая статистику и отрисовывая различные графики Zabbix’ом.
В статье мы сконцентрируемся на некоторых особенностях архитектуры NETMAP, а также показателях скорости обработки пакетов, которые с его помощью получены на «обычном» железе.

Каждый разработчик, который работает на той или иной технологии, постоянно читает о ней что-то новенькое и углубляет свои знания. И мы не исключение. PHP довольно старый и популярный язык, на котором есть много разных фреимворков. Один из самых популярных и серьезных – это Symfony и так уж исторически получилось, что мы на нем пишем. По этому фреимфорку в рунете не так много информации, как хотелось бы, мы часто читаем разные статьи, обзоры и интервью на английском языке, чтобы быть в курсе последних событий. Эта статья – обзор больших сайтов, которые сделаны на PHP / Symfony с уникальной для рунета информацией, а также описание некоторых технологий, которые применяются в связке с ними. И да, мы знаем, что PHP «уже не торт» и что использовать его уже не модно, однако эта технология имеет большую долю рынка, много наработок и отличную документацию, поэтому мы её используем наравне с Python, Ruby, Java и другими.

Таблица известных проектов (на основе данных http://builtwith.com/), кликабельно:

На картинке изображен график роста траффика, который облачные адепты по всему миру продают в виде одного из сценариев, когда эластичное масштабирование имеет высокую ценность:



Это график посещений сайта Have I been pwned? (HIBP), который в один момент стал обслуживать со ~100 сессий в час до… 12000 сессий в час. Практически мгновенно.

Это случилось на неделе в сентябре, когда траффик буквально увеличился в 60 раз. 10 сентября – 2105 сессий, 11 сентября – 124036 сессий. Интересные вещи происходят, когда нагрузка увеличивается так резко, так быстро. Так что мне захотелось поделиться с вами несколькими вещами, которые я узнал – что было сделано мной хорошо и что следовало улучшить.

В NGINX версии 1.9.1 появилась новая возможность, позволяющая использовать сокетную опцию SO_REUSEPORT, которая доступна в современных версиях операционных систем, таких как DragonFly BSD и Linux (ядра 3.9 и новее). Данная опция разрешает открывать сразу несколько слушающих сокетов на одном и том же адресе и порту. При этом, ядро будет распределять входящие соединения между ними.

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.



Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?

Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.

Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.





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

Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.

Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.

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

Если у вас еще нет планов на выходные – у меня есть предложение: посмотрите доклады с DotNext 2016 Moscow, вчера мы выложили их в общий доступ.

Вообще, мой любимый формат поста про конференции – обзор лучших докладов. Жаль, делать его получается только один раз на конференцию… В любом случае, сегодня у нас есть о чем поговорить: мы открыли доступ к видеозаписям лучших докладов конференции DotNext 2016 Moscow и близимся к завершению программы DotNext 2017 Piter (Питер, 19-20 мая), о которой тоже скажу пару слов.



Все видео под катом.

Привет! Недавно я натолкнулся на довольно интересное описание архитектуры Pusher Channels и решил его перевести для вас. На мой взгляд, автор очень доступно описал подходы к построению высоконагруженной и масштабируемой архитектуры. Скорее всего, статья будет полезна новичкам, а также специалистам из смежных областей.

В офисе компании Pusher у нас висит небольшой счетчик с постоянно увеличивающейся цифрой. Он показывает количество доставленных сообщений за всё время существования Pusher Channels. В пятницу в 22:20 по UTC число увеличилось на один разряд и достигло 10.000.000.000.000. В нём 13 нулей — 10 трлн.

Вы можете подумать, что счётчик общего количества сообщений — бесполезная кичливая метрика. Но это число — ключевой индикатор успеха Pusher Channels, нашего продукта для коммуникации в режиме реального времени. Во-первых, данный счётчик отражает доверие, оказанное нам пользователями. Во-вторых, он измеряет масштабируемость нашей системы. Чтобы цифра увеличивалась, мы в Pusher должны сделать так, чтобы пользователи доверяли отправку сообщений нашему сервису, и мы должны быть уверены в том, что наша система способна обработать эти сообщения. Но что нам стоит доставить 10 трлн сообщений? Давайте посмотрим.

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



Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.