Оптимизация производительности web-систем для всех презентация

Оптимизация производительности web-систем для всех В популярном изложении

Давайте познакомимся Разработчик ПО с 98-го года alexander.chistyakov@dataart.com root@*.kupikupon.ru root@<a number of other domains> Индивидуальный предприниматель Консультант, performance engineer http://alexclear.livejournal.com

Вы? Нынешние или будущие CEO Нынешние или будущие CTO Разработчики ПО Founders, co-founders, owners, entrepreneurs И просто творческие хорошие люди

О чем пойдет речь? В зале кто-нибудь занимается оптовыми поставками никеля? В зале кто-нибудь занимается проектированием и разработкой веб-сайтов? Речь пойдет о веб-сайтах

Веб-сайт в идеальном мире Пришел Запустил Победил

Веб-сайт в реальном мире Пришел Запустил

Что делать?

Что, все-таки, делать? Нужно получить контроль над ситуацией Нужно было контролировать ситуацию с самого начала «Premature optimization is the root of all evil» D.Knuth Взаимоисключающие пункты? "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

Как контролировать ситуацию? Sizing, capacity planning Определение и устранение узких мест в приложении Нагрузочное тестирование

Мифы и легенды - 1 Клиент – владелец большого холдинга Приложение – тематический портал, находится в стадии разработки ТЗ Клиент утверждает со слов консультантов, что ему понадобятся 100 серверов Два года спустя все еще используется один сервер, портал не входит в top 10 по своей тематике

Что было неправильно - 1 Внешние консультанты часто имеют свой интерес (особенно, интеграторы) Эффективность инфраструктуры не имеет однозначной зависимости от стоимости Размер инфраструктуры некоторых классов проектов рассчитать очень просто – достаточно посмотреть на соседей Не надо покупать мощности до того, как появится нагрузка

Мифы и легенды - 2 Проект уровня страны Закуплена тяжелая техника, определены сроки сдачи в эксплуатацию, запланирована интеграция с внешними инфраструктурами В день запуска оказывается, что производительность системы на два порядка ниже необходимой Далее все как на картинке «План эвакуации»

Что было неправильно - 2 Эффективность инфраструктуры не имеет однозначной зависимости от стоимости Прежде чем что-то сдать в эксплуатацию, его хорошо бы протестировать Прежде чем что-то принять в эксплуатацию, его хорошо бы протестировать Всегда необходимо заранее знать, что вы будете делать, если система не справляется с нагрузкой

Мифы и легенды - 3 “Nobody ever got fired for buying Cisco” Место действия – офис крупной компании, канал 50 Мбит, из них реально используется 10, потому что Cisco 28x не держит нагрузку Переключение роутинга на уже имеющийся в компании стоечный сервер решает проблему, нагрузка на сервер при этом нулевая Что нужно было сделать с коллегой, который купил Cisco следующей серии на замену?

Что было неправильно - 3 Эффективность инфраструктуры не имеет однозначной зависимости от стоимости Прежде чем что-либо купить, необходимо оценить его эффективность Необходимо помнить про альтернативные решения и оценивать также их эффективность

Мифы и легенды - 4 Место действия – компания в США с уже существующим веб-приложением Ожидается большой приток новых пользователей, проводится тестирование нагрузки Выясняется, что нагрузка слишком велика Покупается самый многоядерный инстанс на Amazon EC2 для переноса на него базы Производительность СУБД не изменилась

Что было неправильно - 4 Прежде чем что-либо купить, необходимо оценить его эффективность В любой книге или блоге, посвященной производительности СУБД сказано, что узкое место – не процессор, а дисковая подсистема

Мифы и легенды - 5 Место действия – повсеместно Идея – «мы купим хостинг у облачного провайдера и отмастштабируем инфраструктуру вверх, когда нагрузка увеличится» Результат – полный провал, нагрузка растет быстрее, чем возможности нового более мощного узла

Что неправильно - 5 IaaS-облака вообще не предназначены для масштабирования «вверх» Производительность дисковой подсистемы инстанса IaaS-облака заметно ниже, чем могла бы быть у обычной машины по ряду причин Ваше приложение, скорее всего, не готово к горизонтальному масштабированию

Мифы и легенды - 6 Место действия – популярный отраслевой новостной ресурс Для уменьшения нагрузки на БД включен стандартный компонент кэширования записей Инвалидация кэша сломана – удаленные комментарии некоторое время доступны в RSS лентах

Что было неправильно - 6 Времена Delphi прошли безвозвратно, разработка не может быть сведена к набрасыванию компонентов мышью Если применяете какой-то компонент третьей стороны, убедитесь, что он применим и правильно работает Применяйте только те решения, в которых ваша команда может разобраться

Мифы и легенды - 7 Место действия – стартап Сайт компании не является основным продуктом и был отдан на аутсорс Взята популярная CMS, в ней включен файловый кэш После падения сервера сайт перестает работать, потому что CMS видит в кэше невалидный XML-файл

Что было неправильно - 7 Думайте об условиях применимости выбираемых решений, их авторы часто не делают этого, так как заняты продажами или отдыхом на курорте Если вы не хоститесь на массовом хостинге, не используйте трюки, предназначенные для тех, кто там хостится – эти трюки придуманы от безысходности

Мифы и легенды - 8 Место действия – Россия “php-fpm быстрее чем Apache+mod_php” Знаю коллегу, который задает этот вопрос на собеседовании, завидую его нервам Сам задаю такой же по смыслу вопрос про nginx и Apache и каждый раз плачу php-fpm не быстрее Apache+mod_php на реальных приложениях

Что неправильно - 8 Не надо верить маркетологам, даже если они не выглядят как маркетологи Проверяйте любые утверждения относительно производительности самостоятельно и в вашем собственном окружении

Мифы и легенды - 9 Сайт, хорошо отвечающий требованиям бизнеса и плохо – требованиям нагрузки Прогноз на существенный рост посещаемости Проблема – 170 SQL-запросов на показ главной страницы Запросы кэшируются в memcached

Что было неправильно - 9 Все было правильно, так как эту оптимизацию делал я Шутка В моменты инвалидации кэша происходила гонка за ресурсы, и сайт мог пару минут подтормаживать, пока не разогреется кэш Такие вещи надо учитывать, тем более, что в новой библиотеке php-memcached есть атомарные операции

А как же тогда правильно? Не ожидайте, что к вам придет Дед Мороз с верным решением, скорее, к вам придет дедлайн Вспомните лабораторные работы на уроках физики в школе В оптимизации производительности очень много от физического эксперимента

Измеряйте Если вы не знаете, какие именно параметры измерять, измеряйте все параметры, до которых можете дотянуться Стройте графики, даже если вы не знаете объяснения тому, что происходит, тренды можно будет видеть на графиках Стандартный набор параметров для любого узла веб-системы мониторится любой подходящей утилитой по умолчанию

Меняйте условия среды У системы множество параметров, которые можно изменить Даже если ничего не знать об устройстве системы внутри, меняя эти параметры, можно получать различные результаты Наилучший вариат – когда вам удается изменить ровно один параметр при зафиксированных остальных

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

Интерпретируйте результат - без ног не слышит Знайте свои инструменты и окружение, в котором вы работаете В процессоре всего-то 300 миллионов транзисторов, неужели он умнее вас? К тому же, компьютер это полностью детерминированная система (счетчик Гейгера был против этой моей реплики)

Архитектурные решения Архитектурные решения применяются при постройке зданий При разработке ПО применение архитектурных решений не спасает от действий разработчика Васи по написанию плохо оптимизированного кода Чем проще ваша система – тем лучше

Простота В отказоустойчивой системе количество узлов минимально Чем проще ваш код, тем его проще адаптировать к среде, предоставляющей нужные вам сервисы Не изобретайте велосипед Шаблон «Inversion of Control» был придуман после долгих лет скитаний в пустыне EJB2

Выводы Даже если вы – CEO, необходимо представлять себе возможности вашего приложения и требования к нему Тем более, если вы CEO Линейка, штангенциркуль и весы – по-прежнему ваши друзья Никому не верьте на слово, даже мне Хотя, нет, мне верьте

Вопросы и предложения Хотите, я прочитаю вам еще один доклад? Еще четыре доклада? Спасибо за внимание!