Высокая производительность

Всем привет!

Я Павел Мурзаков, тимлид серверной команды Badoo. Мы обожаем PHP, вкладываемся в его развитие и развитие сообщества вокруг него. 21 сентября планируем провести третий Badoo PHP Meetup. Приглашаем спикеров и гостей!

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

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

Регистрация по ссылке, начало в 12:00, гостей встречаем с 11:00. 

Несколько месяцев назад я упомянул в одном посте, что это миф, будто бы const помогает включать оптимизации компилятора в C и C++. Я решил, что нужно объяснить это утверждение, особенно потому, что раньше я сам верил в этот миф. Начну с теории и искусственных примеров, а затем перейду к экспериментам и бенчмаркам на реальной кодовой базе — SQLite.

Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

Представляю продолжение своей статьи «Облачные сервисы для игры на слабых ПК, актуальные в 2019 году». В прошлый раз мы оценивали их достоинства и недостатки, используя открытые источники. Сейчас же я протестировала каждый из сервисов, о которых говорилось в прошлый раз. Результаты этой оценки — ниже.

Отмечу, что оценить абсолютно все возможности этих продуктов за вменяемое время не представляется возможным — слишком много нюансов. Но я постаралась добавить в статью наиболее важные технические характеристики, которые и стали своеобразными «реперными точками» статьи. Disclaimer: Обзор субъективный, это не научное исследование.

Сергей Куксенко — перформанс-инженер, видевший Java еще версии 1.0. За это время успел поучаствовать в разработке мобильных, клиентских, серверных приложений и виртуальных машин. Производительностью Java занимается c 2005 года и в данный момент в Oracle работает над улучшением производительности JDK. Один из самых популярных докладчиков на Joker и JPoint.

Этот хабрапост — большое интервью с Сергеем, посвященное следующим темам:

• Культ Производительности;
• Когда и что нужно оптимизировать, изначальный дизайн языка и библиотеки;
• Перспективные направления для дальнейшей оптимизации;
• Как можно поучаствовать в разработке и что можно сломать оптимизациями;
• Компиляторные трюки, размещение регистров;
• Можно ли собрать кошку из фарша;
• Когда тесты работают пять дней подряд и прочая бытовуха;
• Как стать перформанс-инженером;
• Подготовка доклада на следующий Joker.

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

Лето выдалось холодным, а это хороший повод потратить дождливые деньки на просмотр пары-тройки лекций по frontend-разработке. 27 июня прошел первый SmartMail Meetup, посвященный фронтенду. С техническими докладами выступили сотрудники команды frontend-разработки Почты. Вместе с ними и еще 300 участниками мы обсудили, чем живут фронтендеры Mail.ru Group и каково это, работать с высоконагруженными сервисами.

Техника кеширования позволяет создавать более масштабируемые приложения, запоминания результаты некоторых запросов в быстрое in-memory хранилище. Однако, некорректно реализованное кеширование может сильно ухудшить впечатление пользователя о вашем приложении. Эта статья содержит некоторые базовые понятия о кешировании, различные правила и табу, которые я извлек из нескольких прошлых своих проектов.

Не используйте кеширование.

Ваш проект работает быстро и не имеет никаких проблем с производительностью?
Забудьте о кешировании. Серьезно :)

Оно сильно усложнит операции чтения из базы без каких-либо бенефитов.

Правда, Мохамед Саид в начале этой статьи делает некоторые вычисления и доказывает, что в некоторых случаях оптимизация приложения на миллисекунды способна сэкономить кучу денег на вашем AWS счету. Так что, если прогнозируемая экономия на вашем проекте больше, чем 1.86 долларов, возможно, реализация кеширования — неплохая идея.

Этот хабрапост объединяет десять лучших докладов от таких спикеров, как Nicolai Josuttis, Timur Doumler, Андрей Давыдов и многих других.

C++17/20/23, concepts, immutable data structures, concurrency, parallelism, metaprogramming — всё это темы конференции C++ Russia 2019, прошедшей этой весной в Москве. Более шести сотен участников, известные международные спикеры, глубокие доклады. Обратите внимание — доклады такие, что устареют очень нескоро, а применить полученные знания можно хоть сейчас.

Формат таков:

• Обязательное видео на YouTube
• Подробное описание доклада на русском языке (со слайдами, если они есть)
• Краткая биография докладчика

Не стесняйтесь писать комментарии! Кстати, в плейлисте, опубликованном под катом, есть не только топ-10. И мы выключили рекламу на YouTube, так что никто не будет мешать.

Привет!

Меня зовут Илья Аблеев, я работаю в команде мониторинга Badoo. 21 августа приглашаю на традиционную, пятую, встречу сообщества специалистов по Zabbix в нашем офисе!

Поговорим о вечной боли — хранилищах исторических данных. Многие сталкивались с проблемами производительности, вызванными типичными причинами: низкой скоростью дисков, недостаточно хорошим тюнингом СУБД, внутренними процессами Zabbix, которые удаляют старые данные и т.п. Но не всегда всё сводится к стандартным решениям. 

«Из коробки» в Zabbix’е доступно два вида бэкенда: MySQL и PostgreSQL. Не так давно добавили поддержку noSQL хранилища — Elasticsearch. В то же время на рынке есть множество других решений, которые могут хорошо решать задачу хранения и отдачи исторических данных, например, ClickHouse, TimescaleDB, Cassandra.

На митапе мы обсудим опыт внедрения хранилищ, отличных от MySQL и Postgresql, поговорим об их плюсах и минусах, поделимся результатами производительности. 

Трансляция будет на YouTube. Под катом информация о формате и экспертах.

Эта статья о том, что будет означать добавление дженериков в Go, и почему я считаю, что нам это следует сделать. Также я коснусь возможного изменения архитектуры языка ради добавления дженериков.

Go вышел 10 ноября 2009-го. Меньше чем через сутки появился первый комментарий про дженерики. В нём также упомянуты исключения, которые мы добавили в язык в виде паники и восстановления (panic and recover) в начале 2010-го.

За три года наблюдений отсутствие дженериков всегда входило список трёх главных проблем, которые необходимо исправить в языке.

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

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

Неожиданное поведение приложения в отношении работы с базой приводит к войне между DBA и разработчиками: DBA кричат: «Ваше приложение роняет базу», разработчики — «Но ведь до этого всё работало!». Хуже всего, что DBA и разработчики не могут помочь друг другу: одни не знают про нюансы работы приложения и драйвера, другие не знают про особенности, связанные с инфраструктурой. Было бы неплохо такой ситуации избежать.

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

Примерно 4 года назад мы перенесли нашу систему отчётности с Oracle на SAP Hana. Сегодня в ней хранится около 10 000 таблиц, ею пользуется 38 000 человек и в ней ежедневно происходят более 5000 процессов загрузки. На текущий момент наш комплекс, на котором работает система, представляет собой 8 серверов с 14 Тб памяти. Каждый день в системе отчётности обрабатывается 1,5 Пб данных. При этом Hana оказалась примерно в 20 раз производительнее Oracle, DB2 и MySQL. И сегодня я хочу рассказать, как мы в рамках интеграции «М.Видео» и «Эльдорадо» дополнительно повышали производительность системы отчётности, какие оптимизации вносили.

Как вырасти в 10 раз под количеству запросов к БД не переезжая на более производительный сервер и сохранить работоспособность системы? Я расскажу, как мы боролись с падением производительности нашей базы данных, как оптимизировали SQL запросы, чтобы обслуживать как можно больше пользователей и не повышать расходы на вычислительные ресурсы.

Классическое PHP-приложение — однопоточность, тяжелая загрузка (если вы, конечно, не пишите на микрофреймворках) и неизбежная смерть процесса после каждого запроса… Такое приложение тяжелое и медленное, но мы можем дать ему вторую жизнь гибридизацией. Чтобы ускорить — демонизируем и оптимизируем утечки памяти, чтобы добиться большей производительности — внедрим собственный сервер РНР-приложений RoadRunner на Golang, чтобы добавить гибкости — упростим PHP-код, расширим стек и разделим ответственность между сервером и приложением. По сути, заставим наше приложение работать, как если бы мы писали его на Java или другом языке.

Благодаря гибридизации ранее медленное приложение перестало страдать 502 ошибками под нагрузками, уменьшилось среднее время ответа на запросы, производительность увеличилась, а деплой и сборка стали проще за счет унификации приложения и избавления от лишней обвязки в виде nginx + php-fpm.


Антон Титов (Lachezis) — технический директор и соучредитель SpiralScout LLC с опытом активной коммерческой разработки на PHP в 12 лет. Последние несколько лет активно внедряет Golang в стек разработки компании. Об одном из примеров Антон рассказал на PHP Russia 2019.

СУБД InterSystems IRIS поддерживает любопытные структуры для хранения данных — глобалы. По сути это многоуровневые ключи с различными дополнительными плюшками в виде транзакций, быстрых функций для обхода деревьев данных, блокировок и своего языка ObjectScript.

Подробнее о глобалах в цикле статей «Глобалы — мечи-кладенцы для хранения данных»:

Деревья. Часть 1
Деревья. Часть 2
Разреженные массивы. Часть 3

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

Материалы из нашего блога об IaaS и Tg-канала про IT-инфраструктуру.

^{/ фото NASA, Rawpixel CC BY}

Аналитические заметки

• Как прошла конференция VMware EMPOWER 2019 Это — саммари о поездке специалистов «ИТ-ГРАД» в Лиссабон, где VMware проводили свою ежегодную тематическую конференцию. Прямую трансляцию с места событий мы вели у себя в Telegram-канале, а на Хабре публиковали ежедневные отчеты с заметками о представленных новинках и наиболее обсуждаемых технологиях: день первый (интеллектуальные решения, информационная безопасность, конец эры NSX-V), день второй (сетевые решения, IoT, МО), день третий (виртуализация СХД и восстановлении данных). Помимо этого мы подвели итоги и в хабрапосте.

Язык Go набирает популярность. Настолько уверенно, что появляется все больше конференций, например, GolangConf, а язык входит в десятку самых высокооплачиваемых технологий. Поэтому уже имеет смысл разговаривать о его специфических проблемах, например, производительности. Кроме общих для всех компилируемых языков проблем, у Go есть и свои собственные. Они связаны с оптимизатором, стеком, системой типов и моделью многозадачности. Способы их решения и обхода иногда бывают весьма специфическими.

Даниил Подольский, хоть и евангелист Go, тоже встречает в нем много странного. Все странное и, главное, интересное, собирает и тестирует, а потом рассказывает об этом на HighLoad++. В расшифровке доклада будут цифры, графики, примеры кода, результаты работы профайлера, сравнение производительности одних и тех же алгоритмов на разных языках — и все остальное, за что мы так ненавидим слово «оптимизация». В расшифровке не будет откровений — откуда же они в таком простом языке, — и всего, о чем можно прочесть в газетах.

Привет, Хабр! Каждый SRE в нашей команде когда-то мечтал спокойно спать по ночам. Мечты имеют свойство сбываться. В этой статье я расскажу про это и про то, как мы достигаем производительности и устойчивости своей системы Dodo IS.