Ознакомительный вводный доклад, предположительное начало трека докладов на тему оптимизации производительности для Code'n'Coffee SPb.

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

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

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

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

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

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

7. Что делать?
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"
8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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