close

Вход

Забыли?

вход по аккаунту

?

Очереди задач

код для вставкиСкачать
Проблема взрывного роста
аудитории: что делать, когда не
хватает мощностей?
Типичный случай интернет-проекта: он
становится популярным и с каждым днём
его аудитория растёт невиданными
темпами.
Каким образом наращивать мощность
оборудования и ПО с учётом того, что
останавливать проект нельзя?
310k – онлайновая игра
• Классическая LAMP система
• Прежде всего - чат со всеми сложностями в отдаче
информации в реальном времени
• Быстрый (крайне быстрый) рост аудитории со 100 до
3000 человек
• [-] плохая оптимизация кода
• [-] проблемы с бюджетом
INFON Spike
•
•
•
•
J2EE
365х24х7
миллионы запросов в сутки
каждый абонент – это живые, уже заплаченные им
деньги, поэтому запросы терять нельзя
• высокая нагрузка на биллинг
Diary.Ru
• LAMP система
• рост аудитории опережал добавление мощностей
• был достигнут «потолок» архитектуры (добавление
ещё одной машины ничего не решало)
• [-] MySQL и падение репликации мастер-мастер
• [-] узкое место – БД
• [-] экстенсивное наращивание БД и неоптимальная
логика работы приложения (к примеру – JOIN’ы)
• [-] отсутствие кэширования выборок
Когда становится
очевидным, что железо не
справляется?
Когда становится
очевидным, что железо не
справляется?
• когда оно странно пахнет…
• и дымится.
Когда становится
очевидным, что железо не
справляется?
•
•
•
•
время отклика
отказы запросов
отсутствие реакции на запрос
непонятные ошибки, которых ранее месяцами не
было
• когда падают сервера
–
–
–
–
–
нехватка памяти
сбои репликации
низкая производительность терминальных приложений
ошибки открытия сокетов
ошибки выделения потока на запрос
С чего начать
переделку?
С чего начать
переделку?
• с аудита системы!
Прежде всего, плясать
от пользователя!
Прежде всего, плясать от
пользователя!
• взять пользователя и очертить список его
задач
– какие типы пользователей есть в системе (сайте)?
– чем каждая группа отличается от других, что они
делают на сайте?
– какие задачи выполняют?
– какой процент запросов приходится на выполнение
той или иной задачи?
Прежде всего, плясать от
пользователя!
• внутренний путь пользователя по
системе
– разделить виды запросов пользователя к системе
(вызов френдленты, комментирование)
– взять наиболее часто встречающиеся виды
запросов и нарисовать их, стрелочками показывая
«а вот теперь он идёт туда» в сиквенс-диаграмме
Найти и оценить
проблемные блоки
Найти и оценить
проблемные блоки
• идти от внутреннего пути пользователя
• где больше всего теряется времени
– может сказаться на количестве свободных ниток
• где больше всего тратится процессорного времени
– может не хватить другим на обработку
• неразделяемые ресурсы, в очередях на обращение к
которым стоят модули программ
–
–
–
–
прежде всего - обращения к диску
общая память приложений
хранение сессий в частности
и, вообще, хранение данных
– гэтвей на приём и отправку запросов
• инфраструктура, накладывающая ограничения на
траффик
Только на этом этапе
стоит нарисовать всю
систему вцелом!
• аудит внутреннего пути
даст представление, с
какой подробностью и
какие блоки стоит
рисовать
• Если начать рисовать
раньше, то можно
оказаться в ловушке
«зашоренности сознания» представляя всю систему
При рисовании и
обсуждении системы
полезно воспользоваться
следущими приёмами:
Пригласить эксперта со
стороны
Пригласить эксперта со
стороны
Эксперт должен
говорить на одном с
вами языке!
• приглашать на
обсуждение типа
пользователей и их
внешнего пути, к
примеру, юзабилиста
можно и даже
рекомендуется
• а вот приглашать того
же юзабилиста на
оценку внутреннего
пути пользователя
Эксперт должен
говорить на одном с
вами языке!
• желательно так же,
чтобы эксперт имел
опыт работы с
подобными проблемами
• основное - даже не
успешное разрешение,
а знание «подводных
камней» и
практический опыт
White Board!
• рисовать всё слайдами
• подписывать каждый слайд и писать тезисы
обсуждения
• фотографировать слайд, после чего его
можно стирать или модифицировать
• по результатам обсуждения просмотреть
всем вместе все слайды и попытаться
уложить это в какой-то документ
• рисовать диаграммы не нужно, достаточно
использовать фотографии слайдов
• а вот расшифровать тексты тезисов с
фотографий и написать к ним комментарии
очень желательно
• очень-очень важно собирать все идеи, как
по текущей системе
Разработчики системы
• Прежде всего – сисадмин,
который самый первый
сталкивается с багами
• Дизайнер-юзабилистпрограммист клиента,
который разрабатывает
«морду сайта»
• Тестер, который знает все
баги прошлой системы
• И тот парень, который даёт
Планирование
Важно не забыть о:
– Рабочих руках.
• кто чем может заниматься и сколько
времени они могут потратить на
проект
• немаловажно – в какой промежуток
времени у них будет это время!
– Доступных ОС и языках
программирования
• это может быть важно, в случае,
если люди умеют писать на
нескольких языках
– Материальных ресурсах
•
•
•
•
•
прежде всего, количество серверов
сетевая инфраструктура (хостинг)
память
производительность машинок
лицензии на различные
проприетарные модули системы
• т.д.
– Времени на переделку вообще
• тут полезно задуматься об этапах
(милстоунах), к которым хотелось бы
что-то получить и договориться,
Какие части системы
очень не хочется
переделывать:
• «морда сайта»
– да и вообще дизайн,
потому что долго и
муторно, а дизайнер,
который это делал
давно уволился
– редизайн сайта в
условиях, когда
пользователям всё
нравится,
Какие части системы
очень не хочется
переделывать:
• интерфейсы
интеграции и связи
с внешними
партнёрами
– потому что
интерфейсы были
утверждены давно, их
формат – предмет
договора,
Какие части системы
очень не хочется
переделывать:
• формат базы данных
– и вообще
переделывать БД –
долго и муторно,
данные терять не
хочется и т.д.
Какие части системы
очень не хочется
переделывать:
• какие-то куски
бизнес-логики
– потому что они были
написаны каким-то
индусом из оффшорной
конторы и как они
работают без
буддисткого
мироощущения понять
Просто требуется
представить, как дальше
будет развиваться
проект
• Какая посещаемость будет у него
через год?
• А через два года?
• А через три?
Проектирование.
• Во время аудита
системы и
планирования
становится понятен
круг задач:
– что нужно будет
переделать точно
– какие есть критические
места (а значит и стоит
подумать над этими
Общая архитектура
системы
• предлагаются все-все идеи
новой системы, как она
должна функционировать,
из каких блоков состоять,
как в ней разрешены
указанные проблемы
• неплохо посмотреть на уже
готовые примеры (хотя бы
на уровне блок-схем)
• посмотреть достоинства и
недостатки каждой
предложенной архитектуры
и кратко рассмотреть, чем
это грозит в ближней
перспективе
– количество работ по
Типичные решения
проблемы
производительности
Более мощное железо?
• даёт быстрый рост
производительности
• не нужно переделывать
систему
– запас
производительности
быстро исчерпывается
– требует хорошей команды
админов для переноса
кода
Написать более
эффективный код
• помогает разгрузить
сервер
• может решить какие-то
замеченные проблемы со
стабильностью и
безопасностью
– к сожалению плохо помогает с
неразделяемыми и
разделяемыми ресурсами
– чаще всего тормозит или
нестабилен не плохой код, а
используемые чужие
библиотеки, сервера и БД
– уже в краткосрочной
Оптимизировать запросы
к БД
• правильно использовать
возможности БД – это
насущная необходимость
• от join’ов избавляться нужно –
это однозначно
• не стоит забывать
использовать выборки по
индексам!
• Вспомнить SQL (к примеру,
считать количество полей
cout’ом, а не выборкой)
• хранимые процедуры
позволяют существенно
увеличить
производительность
– уже в среднесрочной
Оптимизировать
структуру БД
•
Разделить поля по
типу записи и чтения
в них:
1. статические (редко
меняемые, такие, как user
info), оптимизированные
на чтение откроет
возможности для
кэширования
2. поля на запись (к
примеру, сообщения в
чате) позволит более
эффективно
Оптимизировать
структуру БД
•
разделение хранимой
информации по схемам:
»
к примеру, вынос
информации
пользователей, чьё имя
начинается от A до D в одну
схему, E-H – в другую и т.д.
1. позволит легко
переносить схемы между
различными серверами
БД, становится легче
добавлять новые машины
2. меньший объём
Оптимизировать
структуру БД
•
Более эффективная
структура БД позволит
расширять поля для
хранимой информации
Оптимизация данных
может помочь
эффективному
использованию индексов
•
–
–
серьёзная переделка БД
заставляет писать новую
бизнес-логику доступа к ней
хорошо, когда эта бизнес-
Использование
репликации БД
• Теперь выборки могут
производиться сразу на
нескольких серверах!
» Особенно эффективна
репликация по типу: пишем в
мастер, читаем со слейвов.
• Для многих серверов есть
готовые решения для
балансировки нагрузки,
зачастую даже
интегрированные с кэшем
выдачи
– в долгосрочной перспктиве
могут начаться отказы и
ошибки репликации при
определённой скорости
Кэшировать!
• Память всё дешевеет, а
производительности на
кэш не нужно (можно
использовать старые
машины)
» очень правильно выделить
отдельные машинки под
сервера кэша – это может быть
MemCached или JBoss Cache
• для этого очень помогает
выделение объектов,
которые не меняются во
время жизни сессии
пользователя. К примеру –
те же сессии или user info в
блоге или форуме
• когда кэш является
посредником к БД –
эффективно писать
Кэшировать!
• Основной минус: кэш
неэффективен, когда
объекты
запрашиваются редко
либо объектов так
много, что они просто
вытесняются более
новыми
– нужно считать, где кэш
будет эффективен
» для этого пригодится
аудит системы, знание
внешнего и внутреннего
путей пользователя
Использование множества
зеркал и балансировщика
между ними
• Более гладко распределяется нагрузка
• Можно за балансировщиком поставить различные
машинки для разных типов запросов
» к примеру ngnix как балансер, один сервер – для отдачи
картинок и прочей статики и пару серверов с ПХП
приложениями
– если за разными серверами, балансированными балансером
скрывается общий бэкэнд или неразделяемый ресурс (к
примеру, БД), то эффективность этого механизма резко падает
Очереди задач
Те вещи, которые
выполняются
периодически
(например, рассылка
комментариев по
почте) неплохо
выносить в
специальные
обработчики с
очередями задач к
ним.
Очереди задач
• главное достоинство –
иметь возможность
поместить какую-то задачу
в очередь и как только для
неё будут свободные
ресурсы – она выполнится
» это серьёзно позволяет
нормировать нагрузку на
сервер
• синхронизацию каких-то
частей тоже эффективно
производить через
очереди
» конвертация БД или
перекладывание данных из
одного формата в другой
• в обработку через очереди
Очереди задач
• Полезное
достоинство –
связывание частей
системы через
общие серверы
очередей
» класть в очередь могут одни части системы на
одной машине, а выполнять – другие, на другой,
что позволяет гибко нормировать нагрузку
Очереди задач
– основной минус
очередей –
асинхронность
выполнения, никто не
гарантирует
получения ответа в
заданный промежуток
времени
RPC (remote procedure
calling)
Использовать различные виды RPC,
начиная с CORBA и RMI с JMX’ом,
заканчивая Web Service и REST
архитектурами.
RPC
• Позволит вызывать
процедуру на одной
машине, а выполнять на
другой, что сразу же
делает архитектуру
масштабируемой
• В случае применения
кэширования и
использования
интерфейсов к доступу
к различным
структурам данных,
легко позволит ввести
кластеризацию
RPC
• К сожалению, большие
накладные расходы
» каждый запрос оборачивается
каким-то специфичным
контейнером, парсится как на
стороне клиента запроса, так
и на стороне сервера и т.д. –
отсюда дополнительные
издержки и время
• Сильно зависит от сетевой
инфраструтуры проекта
» если что-то не так с
роутингом, если есть потери
пакетов, то время существенно
увеличивается
• На программном уровне
возникает целый ряд
эксепшинов, связанных с
обработкой отказов сети и
потери целостности
сетевого контейнера из-за
Использование
аппликэйшн-серверов
• Не нужно думать о
кластеризации
самостоятельно, за
тебя (по идее) сделает
платформа
– Главный минус – в том,
что кластеризация в
аппликэйшн серверах
производится за счёт
того же RPC
» из-за чего наследуются все
его проблемы, да ещё
добавляются специфичные
обёртки самого сервера
– Так же плохо, что
Использование
аппликэйшн-серверов
• Изучение логики
платформы,
особенностей
администрирования
и наличие
подводных камней
при разработке и
эксплуатации
1. требует подготовки
кадров
Применяйте следующие
подходы:
• Вынос, кластеризация
и кэширование всех
ранее неразделяемых
ресурсов
» обращения к диску? –
создание сервиса и RPC к
нему
» обращение БД?
Кластеризация,
кэширование, общая точка
входа через интерфейс.
• Всё через интерфейсы!
» оборачивайте старые
блоки, которые не хочется
Применяйте следующие
подходы:
• В случае рефакторинга дизайна –
глубокое последовательное и
поэтапное разделение модели и
представления
– зачастую в PHP проектах
разделение идёт не совсем по
паттерну MVC
– другой случай – модель для
сборки страниц размазана по
сессиям, кукам и запросам
• Задача рефакторинга дизайна:
на первом этапе вынести всю
бизнес-логику если не
формирования модели, то, хотя
бы, записи её в БД в интерфейсы
• На втором этапе - имплементить
эти интерфейсы с помощью
балансера доступа к БД или RPC
Пишите техзадание
• учитывая достоинства
и недостатки
различных подходов, а
так же наличие
критических мест
устаканивайте
архитектуру и так же
слайдами рисуйте
• слайды
фотографируются и
Озвучте отличие между
версиями системы!
• нужно понять, являются ли изменения настолько
большими, что потребуется этап перевода
пользователей
» Такой этап может понадобиться в случае изменения формата
БД
» Или изменения платформы, на которой написана система
• Нужно оценить объём изменяемой бизнес-логики.
Оценивать нужно с точки зрения:
– количества изменяемых старых модулей (про которые
известно, что они работают и работают давно)
– количества изменяемых новых модулей (ещё не до конца
проверенных, оттого и ломать не жалко)
– какие модули новой системы можно внедрить без ломки
старой схемы
– количество нового кода, который придётся написать, а потом тестировать
Планируйте перенос!
При наличии
существенных отличий
новой системы от
старой необходимо
задуматься о
разработке утилит
переноса информации
пользователей в новый
формат!
Переделка
• Сама переделка
начинается сразу же после
проектирования,
» которое вместе с аудитом
системы редко когда занимает
более недели.
• Помощь эксперта во время
переделки уже не
требуется
• Рекомендую во время
переделки назначить
супервизора проекта,
следящего за
соответствием изменений
в спроектированной
архитектуре
» архитектор системы в
процессе переделки не нужен,
эта роль более подходит к
ситуации создания системы
более-менее с нуля, а вот
Изменение требований в
процессе разработки
• Нужно выделять итерации
разработки
• В процессе итерации
требования фиксируются:
они не могут изменяться
• Если необходимо
кардинально изменить
требования, то проще либо
отменить итерацию, либо
разбить её на несколько
частей, для каждой из
которой требования
должны фиксироваться
Тестирование в процессе
разработки
• Вопреки каноническим правилам тестировать каждую итерацию
не нужно
– итерации нужно группировать по общему признаку и выкатывать на
тесты сериями
– отлично, если совершенно другая команда разработчиков пишет
тесты, но, часто, - это недостижимый идеал
– поэтому очень хорошо взять вышеописанного супервайзера и
заставить его написать по фиксированным требованиям каждой
итерации тест-план
– после чего выпустить на модули альфа-тестеров.
• Выбор времени выкатки на альфа-тесты – та ещё задача:
– с одной стороны всё должно уже хотя бы иногда работать в
ограниченной функциональности, с другой – всякие «рюшечки» ещё
не должны быть написаны
– оптимально выкатывать код, когда делать больше нечего – т.е. во
время простоев из-за синхронизации работы программистов
– использовать кросс-тестирование (тестирует не тот, кто писал этот
модуль)
Тестирование
• Все модули новой
системы должны
тестироваться!
– оптимально
тестировать на
реальных
пользовательских
данных
» сняв дамп текущих
запросов
пользователей, скажем,
за день и прогнав их
через тестируемый
Выкатка.
• Новые модули системы,
которые можно применить
до окончания переделки
нужно выкатывать как
можно раньше
» чтобы отловить баги на
реальных пользовательских
данных
• Отличный вариант выкатки
– зеркало с последующим
переключением
– делается параллельный
сервер
– импортируется БД со старого
сервера
– на него отправляются копии
запросов пользователей на
Вопросы?
Константин Андрюнин
e-mail: ymi@ya.ru
ICQ: #102100349
http://ymi.ya.ru
Документ
Категория
Презентации
Просмотров
25
Размер файла
7 358 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа