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

В популярном изложении

2

Давайте познакомимся

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

3

Вы?

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

4

О чем пойдет речь?

• В зале кто-нибудь занимается оптовыми поставками никеля?

• В зале кто-нибудь занимается проектированием и разработкой веб-сайтов?

• Речь пойдет о веб-сайтах

5

Веб-сайт в идеальном мире

• Пришел• Запустил• Победил

6

Веб-сайт в реальном мире

• Пришел• Запустил•

7

Что делать?

8

Что, все-таки, делать?

• Нужно получить контроль над ситуацией• Нужно было контролировать ситуацию с

самого начала• «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"

9

Как контролировать ситуацию?

• Sizing, capacity planning• Определение и устранение узких мест в

приложении• Нагрузочное тестирование

10

Мифы и легенды - 1

• Клиент – владелец большого холдинга• Приложение – тематический портал,

находится в стадии разработки ТЗ• Клиент утверждает со слов консультантов,

что ему понадобятся 100 серверов• Два года спустя все еще используется один

сервер, портал не входит в top 10 по своей тематике

11

Что было неправильно - 1

• Внешние консультанты часто имеют свой интерес (особенно, интеграторы)

• Эффективность инфраструктуры не имеет однозначной зависимости от стоимости

• Размер инфраструктуры некоторых классов проектов рассчитать очень просто – достаточно посмотреть на соседей

• Не надо покупать мощности до того, как появится нагрузка

12

Мифы и легенды - 2

• Проект уровня страны• Закуплена тяжелая техника, определены

сроки сдачи в эксплуатацию, запланирована интеграция с внешними инфраструктурами

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

• Далее все как на картинке «План эвакуации»

13

Что было неправильно - 2

• Эффективность инфраструктуры не имеет однозначной зависимости от стоимости

• Прежде чем что-то сдать в эксплуатацию, его хорошо бы протестировать

• Прежде чем что-то принять в эксплуатацию, его хорошо бы протестировать

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

14

Мифы и легенды - 3

• “Nobody ever got fired for buying Cisco”• Место действия – офис крупной компании,

канал 50 Мбит, из них реально используется 10, потому что Cisco 28x не держит нагрузку

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

• Что нужно было сделать с коллегой, который купил Cisco следующей серии на замену?

15

Что было неправильно - 3

• Эффективность инфраструктуры не имеет однозначной зависимости от стоимости

• Прежде чем что-либо купить, необходимо оценить его эффективность

• Необходимо помнить про альтернативные решения и оценивать также их эффективность

16

Мифы и легенды - 4

• Место действия – компания в США с уже существующим веб-приложением

• Ожидается большой приток новых пользователей, проводится тестирование нагрузки

• Выясняется, что нагрузка слишком велика• Покупается самый многоядерный инстанс на

Amazon EC2 для переноса на него базы• Производительность СУБД не изменилась

17

Что было неправильно - 4

• Прежде чем что-либо купить, необходимо оценить его эффективность

• В любой книге или блоге, посвященной производительности СУБД сказано, что узкое место – не процессор, а дисковая подсистема

18

Мифы и легенды - 5

• Место действия – повсеместно• Идея – «мы купим хостинг у облачного

провайдера и отмастштабируем инфраструктуру вверх, когда нагрузка увеличится»

• Результат – полный провал, нагрузка растет быстрее, чем возможности нового более мощного узла

19

Что неправильно - 5

• IaaS-облака вообще не предназначены для масштабирования «вверх»

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

• Ваше приложение, скорее всего, не готово к горизонтальному масштабированию

20

Мифы и легенды - 6

• Место действия – популярный отраслевой новостной ресурс

• Для уменьшения нагрузки на БД включен стандартный компонент кэширования записей

• Инвалидация кэша сломана – удаленные комментарии некоторое время доступны в RSS лентах

21

Что было неправильно - 6

• Времена Delphi прошли безвозвратно, разработка не может быть сведена к набрасыванию компонентов мышью

• Если применяете какой-то компонент третьей стороны, убедитесь, что он применим и правильно работает

• Применяйте только те решения, в которых ваша команда может разобраться

22

Мифы и легенды - 7

• Место действия – стартап• Сайт компании не является основным

продуктом и был отдан на аутсорс• Взята популярная CMS, в ней включен

файловый кэш• После падения сервера сайт перестает

работать, потому что CMS видит в кэше невалидный XML-файл

23

Что было неправильно - 7

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

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

24

Мифы и легенды - 8

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

на собеседовании, завидую его нервам• Сам задаю такой же по смыслу вопрос про

nginx и Apache и каждый раз плачу• php-fpm не быстрее Apache+mod_php на

реальных приложениях

25

Что неправильно - 8

• Не надо верить маркетологам, даже если они не выглядят как маркетологи

• Проверяйте любые утверждения относительно производительности самостоятельно и в вашем собственном окружении

26

Мифы и легенды - 9

• Сайт, хорошо отвечающий требованиям бизнеса и плохо – требованиям нагрузки

• Прогноз на существенный рост посещаемости

• Проблема – 170 SQL-запросов на показ главной страницы

• Запросы кэшируются в memcached

27

Что было неправильно - 9

• Все было правильно, так как эту оптимизацию делал я

• Шутка• В моменты инвалидации кэша происходила

гонка за ресурсы, и сайт мог пару минут подтормаживать, пока не разогреется кэш

• Такие вещи надо учитывать, тем более, что в новой библиотеке php-memcached есть атомарные операции

28

А как же тогда правильно?

• Не ожидайте, что к вам придет Дед Мороз с верным решением, скорее, к вам придет дедлайн

• Вспомните лабораторные работы на уроках физики в школе

• В оптимизации производительности очень много от физического эксперимента

29

Измеряйте

• Если вы не знаете, какие именно параметры измерять, измеряйте все параметры, до которых можете дотянуться

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

• Стандартный набор параметров для любого узла веб-системы мониторится любой подходящей утилитой по умолчанию

30

Меняйте условия среды

• У системы множество параметров, которые можно изменить

• Даже если ничего не знать об устройстве системы внутри, меняя эти параметры, можно получать различные результаты

• Наилучший вариат – когда вам удается изменить ровно один параметр при зафиксированных остальных

31

Нагружайте систему

• Тестируйте систему под нагрузкой заранее• Подбирайте шаблон нагрузки таким

образом, чтобы он был похож на реальный• Помните о том, что нагрузка это не только

посетители сайта, но и контент, который вы храните и обрабатываете

• Пытайтесь предсказать место, в котором будет следующая горячая точка

32

Интерпретируйте результат

• - без ног не слышит

• Знайте свои инструменты и окружение, в котором вы работаете

• В процессоре всего-то 300 миллионов транзисторов, неужели он умнее вас?

• К тому же, компьютер это полностью детерминированная система (счетчик Гейгера был против этой моей реплики)

33

Архитектурные решения

• Архитектурные решения применяются при постройке зданий

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

• Чем проще ваша система – тем лучше

34

Простота

• В отказоустойчивой системе количество узлов минимально• Чем проще ваш код, тем его проще

адаптировать к среде, предоставляющей нужные вам сервисы

• Не изобретайте велосипед• Шаблон «Inversion of Control» был придуман

после долгих лет скитаний в пустыне EJB2

35

Выводы

• Даже если вы – CEO, необходимо представлять себе возможности вашего приложения и требования к нему

• Тем более, если вы CEO• Линейка, штангенциркуль и весы – по-

прежнему ваши друзья• Никому не верьте на слово, даже мне• Хотя, нет, мне верьте

36

Вопросы и предложения

• Хотите, я прочитаю вам еще один доклад? Еще четыре доклада?

• • • • • Спасибо за внимание!