code'n'coffee spb., вводный доклад по оптимизации...
DESCRIPTION
Ознакомительный вводный доклад, предположительное начало трека докладов на тему оптимизации производительности для Code'n'Coffee SPb.TRANSCRIPT
Оптимизация производительности web-систем для всех
В популярном изложении
2
Давайте познакомимся
• Разработчик ПО с 98-го года• [email protected]• 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
Вопросы и предложения
• Хотите, я прочитаю вам еще один доклад? Еще четыре доклада?
• • • • • Спасибо за внимание!