Оптимизация  LAMP- приложения на примере  OpenX:  разгоняемся до 1000 запросов в секунду   Александр Чистяков,  [email_add...
Кто я? <ul><li>alexander@chistyakov@dataart.com ,  [email_address] </li></ul><ul><li>http://alexclear.livejournal.com </li...
Почему я? <ul><li>Нагрузка 500-5000 пользователей в день есть у всех </li></ul><ul><li>Нагрузка 100500 запросов в секунду ...
Постановка задачи <ul><li>OpenX –  существующее  open source  веб- приложение для показа рекламы </li></ul><ul><li>Linux, ...
Предметная область <ul><li>OpenX:  баннеры, кампании, зоны, пользователи </li></ul><ul><li>Баннеры – собственно, баннеры <...
Начало <ul><li>Одна виртуальная машина в локальной сети </li></ul><ul><li>1000 баннеров, 1 зона, 1 кампания </li></ul><ul>...
Требования <ul><li>Заказчик – большая компания, требования расплывчаты </li></ul><ul><li>200000 баннеров, 400-700 запросов...
Особенности  OpenX <ul><li>Расчет весов баннеров непосредственно в  PHP  коде при каждом показе </li></ul><ul><li>Продукт ...
Расчет весов <ul><li>Несколько циклов в  PHP- коде </li></ul><ul><li>200000 баннеров – 200000 повторений в циклах </li></u...
Оптимизация <ul><li>Декомпозиция объектов до уровня отдельных полей, вынос полей в  memcached </li></ul><ul><li>Веса рассч...
Первые проблемы <ul><li>Много запросов к  memcached , он почему-то не работает – переход к хранению данных в  APC </li></u...
Тестирование: средства <ul><li>Siege, JMeter </li></ul><ul><li>JMeter:  создание разветвеленных сценариев,  GUI </li></ul>...
Тестирование: результаты <ul><li>От трех до семи нод, одна  DB </li></ul><ul><li>Проблемы: ноды перетирают данные в базе (...
Решение проблем <ul><li>Назад к  memcached (slab allocator) </li></ul><ul><li>php-memcached  работает , php-memcache -  не...
Новые вводные данные <ul><li>Заказчик – большая компания, нас тоже много </li></ul><ul><li>Требования конкретизируются пря...
Новые проблемы <ul><li>Если веса нельзя кэшировать, нужно их пересчитывать </li></ul><ul><li>Данные кэшируются для зоны, 1...
Варианты решения <ul><li>Поменять алгоритм выбора – варианты? </li></ul><ul><li>Non-uniform distribution -> uniform distri...
Компромисс <ul><li>Баннеров в зоне не более 200 </li></ul><ul><li>Зон по-прежнему может быть 100 </li></ul><ul><li>Всего т...
Изменения в коде <ul><li>Объекты баннеров до применения  limitations  хранятся в  DB </li></ul><ul><li>Limitations  трансл...
Пара слов о хостинге <ul><li>Первый этап –  Amazon EC2 </li></ul><ul><li>Миграция на  Rackspace Cloud </li></ul><ul><li>Пр...
Тестирование: средства <ul><li>Siege  не подходит: 100 зон, около 50 параметров для каждого из лимитов – нужно менять  URL...
Tsung <ul><li>Tsung:  написан на  Erlang –  распределенность на уровне  VM  языка </li></ul><ul><li>Создавался с учетом мн...
Архитектура <ul><li>Представлена </li></ul><ul><li>на картинке </li></ul><ul><li>Картинку </li></ul><ul><li>перерисовывали...
Распределение нагрузки <ul><li>nginx, HAProxy </li></ul><ul><li>nginx – HTTP/1.0,  генерирует кучу соединений, нет встроен...
Тестирование: проблемы 1 <ul><li>8  web-nod,  одна  DB, 100 rps </li></ul><ul><li>Одна нода  memcached  не выдерживает пот...
Тестирование: проблемы 2 <ul><li>12  web-nod,  одна  DB, ~250 rps </li></ul><ul><li>Большая нагрузка на  web- ноды </li></...
Тестирование: проблемы 3 <ul><li>Включили  maintenance  скрипт в  cron –  перестала справляться  DB </li></ul><ul><li>Суть...
Декомпозиция  DB,  тюнинг выделенной части <ul><li>Выделение  raw logs  в отдельную базу на отдельном узле </li></ul><ul><...
Варианты решения <ul><li>MariaDB vs Percona Server –  разницы в производительности нет </li></ul><ul><li>MySQL vs PostgreS...
Мониторинг <ul><li>Zabbix, Cacti </li></ul><ul><li>Cacti: mysql-cacti-templates  от коллег из  Percona </li></ul><ul><li>Z...
Тюнинг  FS <ul><li>По умолчанию  ext3  с  data=ordered </li></ul><ul><li>Перемонтировали с  data=writeback, iowait  вместо...
Тестирование: проблемы 4 <ul><li>Теперь не справляются кэш-таблицы </li></ul><ul><li>На  MySQL  скачки  I/O </li></ul><ul>...
Тестирование: проблемы 5 <ul><li>12  web- нод,  ~300 rps,  три ноды  DB </li></ul><ul><li>Проблема: скачки  I/O  на  cache...
Шардинг <ul><li>Мысли о шардинге были с самого начала, но по какому параметру разделять по шардам? И какие данные? </li></...
Тестирование <ul><li>12  web- нод, 300  rps,  три ноды  cache DB,  одна нода  raw logs DB  и одна  maintenance DB –  тест ...
Предел <ul><li>~700 rps –  начинаются ошибки на балансере </li></ul><ul><li>Мониторинг: нет корреляции с событиями в систе...
Отказоустойчивость <ul><li>SPOF –  распределенные узлы  memcached </li></ul><ul><li>При падении одного узла таймаут на обр...
Отказоустойчивость : Moxi <ul><li>Проксирование запросов к  memcached – Moxi </li></ul><ul><li>Составная часть проекта  Me...
Отказоустойчивость : Membase <ul><li>Работает на порту  memcached  по его протоколу </li></ul><ul><li>Два режима работы: с...
Отказоустойчивость : MySQL <ul><li>Master-slave  репликация – не средство обеспечения автоматической отказоустойчивости </...
Развертывание <ul><li>Chef, Puppet </li></ul><ul><li>Оба написаны на  Ruby </li></ul><ul><li>Про  Puppet  есть книга, про ...
Команда <ul><li>Участвовало от 5 до 8 человек </li></ul><ul><li>Разработка, интеграция, тестирование, документирование, ко...
Что дальше? <ul><li>Security assesment </li></ul><ul><li>Deployment </li></ul><ul><li>Релиз </li></ul><ul><li>Задача: расп...
Выводы <ul><li>Времени всегда очень мало, вариантов может быть очень много </li></ul><ul><li>Система не должна быть черным...
Вопросы?
Заказчик <ul><li>DataArt,  http://www.dataart.com </li></ul><ul><li>Enjoy IT! </li></ul><ul><li>СПб, Большой Сампсониевски...
Upcoming SlideShare
Loading in …5
×

Оптимизация LAMP-приложения на примере OpenX: разгоняемся до 1000 запросов в секунду

3,923 views

Published on

Типичная ситуация: имеется существующий веб-проект, написанный с применением Linux, Apache, MySQL и PHP, и заказчик хочет сделать проект быстрее с наиболее полным сохранением функциональности.
В данном случае в качестве существующего проекта выступает open source баннерная платформа OpenX, и существенное требование заказчика — разогнать OpenX до пиковой нагрузки в 1000 запросов в секунду и долговременной нагрузки в 600 запросов в секунду.
Постановка задачи: отдача JavaScript-баннеров с заданными параметрами производительности при заданном числе объектов системы.

Подробно:
Краткий обзор объектов предметной области OpenX: баннеры, кампании, зоны.
Особенности OpenX: подходы к оптимизации, предлагаемые производителем, несколько раундов оптимизации уже было.
Проблемы: алгоритм скрипта выбора баннеров плохо работает при требуемом количестве объектов, имеем CPU-bound систему (обычно IO-bound).
Решение: кэширование предрассчитанных данных в БД.
Новые вводные от заказчика, поиск компромисса.
Сбор информации о системе: точки профилирования в коде скрипта, мониторинг с помощью Cacti и Zabbix.
Архитектура системы: типы узлов и связи между узлами. Балансирование нагрузки: nginx vs. HAProxy.
Действия после перенесения нагрузки на уровень БД: кэширование в памяти, проблема: много записи на диск.
MySQL vs MySQL (выбор движка хранилища), MySQL vs MySQL (выбор сборки: stock, Percona Server, MariaDB), MySQL vs PostgreSQL, MySQL vs in-memory RDBMS, MySQL vs NoSQL.
Тюнинг MySQL: параметры конфигурации, параметры платформы (файловая система).
Нагрузочное тестирование: как получить 1000 rps от клиента? siege vs JMeter vs Tsung.
Эволюция архитектуры. Поиск возможностей шардирования данных.
Отказоустойчивость: memcached, moxi, Membase.
Управление конфигурацией: проблема развертывания нод и управления нодами.
Использование Puppet для управления конфигурацией.

1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total views
3,923
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
57
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

Оптимизация LAMP-приложения на примере OpenX: разгоняемся до 1000 запросов в секунду

  1. 1. Оптимизация LAMP- приложения на примере OpenX: разгоняемся до 1000 запросов в секунду Александр Чистяков, [email_address] , http://alexclear.livejournal.com Санкт-Петербург, компания « DataArt »
  2. 2. Кто я? <ul><li>alexander@chistyakov@dataart.com , [email_address] </li></ul><ul><li>http://alexclear.livejournal.com </li></ul><ul><li>Работаю разработчиком ПО с 1998 года </li></ul><ul><li>В настоящее время – разработка высоконагруженных веб-проектов, консультации по вопросам связанным с высокими нагрузками </li></ul>
  3. 3. Почему я? <ul><li>Нагрузка 500-5000 пользователей в день есть у всех </li></ul><ul><li>Нагрузка 100500 запросов в секунду – мало у кого есть, но все читают о ней доклады </li></ul><ul><li>Нагрузка 500-1000 запросов в секунду – должна быть интересна слушателям, но неинтересна докладчикам, «гонка за мегагерцы» </li></ul><ul><li>Переход от 1 rps к 1000rps порождает ряд однотипных классов проблем </li></ul>
  4. 4. Постановка задачи <ul><li>OpenX – существующее open source веб- приложение для показа рекламы </li></ul><ul><li>Linux, Apache, MySQL, PHP </li></ul><ul><li>Необходимо выдержать заданные параметры производительности при заданном количестве объектов предметной области </li></ul>
  5. 5. Предметная область <ul><li>OpenX: баннеры, кампании, зоны, пользователи </li></ul><ul><li>Баннеры – собственно, баннеры </li></ul><ul><li>Пользователи – управляют баннерами </li></ul><ul><li>Кампании – содержат баннеры, имеют приоритеты </li></ul><ul><li>Зоны – группируют баннеры и кампании для расчета весов </li></ul>
  6. 6. Начало <ul><li>Одна виртуальная машина в локальной сети </li></ul><ul><li>1000 баннеров, 1 зона, 1 кампания </li></ul><ul><li>~ 5 запросов в секунду </li></ul>
  7. 7. Требования <ul><li>Заказчик – большая компания, требования расплывчаты </li></ul><ul><li>200000 баннеров, 400-700 запросов в секунду </li></ul>
  8. 8. Особенности OpenX <ul><li>Расчет весов баннеров непосредственно в PHP коде при каждом показе </li></ul><ul><li>Продукт уже оптимизирован, есть рекомендации по настройке под высокую нагрузку </li></ul><ul><li>Рекомендации относятся к масштабированию DB уровня </li></ul><ul><li>DB уровень не участвует в расчете весов! </li></ul>
  9. 9. Расчет весов <ul><li>Несколько циклов в PHP- коде </li></ul><ul><li>200000 баннеров – 200000 повторений в циклах </li></ul><ul><li>Внутренние объекты PHP кэшируются в подключаемый кэш (memcached) </li></ul><ul><li>Максимальный размер объекта для memcached – 1 Мб </li></ul><ul><li>200000 баннеров – объекты размером несколько мегабайт </li></ul>
  10. 10. Оптимизация <ul><li>Декомпозиция объектов до уровня отдельных полей, вынос полей в memcached </li></ul><ul><li>Веса рассчитываются один раз в 10 минут и кэшируются в DB </li></ul><ul><li>Алгоритм сведения любого распределения к нормальному – веса объектов на отрезке [0,1], выбор случайного числа - > удобно построить индекс и сделать SQL- запрос </li></ul>
  11. 11. Первые проблемы <ul><li>Много запросов к memcached , он почему-то не работает – переход к хранению данных в APC </li></ul><ul><li>Доллго рассчитываются значения весов – необходимо версионирование </li></ul><ul><li>Несколько узлов, но APC локален – у каждого узла свой кэш объектов, взаимных блокировок нет </li></ul>
  12. 12. Тестирование: средства <ul><li>Siege, JMeter </li></ul><ul><li>JMeter: создание разветвеленных сценариев, GUI </li></ul><ul><li>Siege: URL не меняется, командная строка </li></ul><ul><li>Siege: до 700 rps на одной машине ( Core i7 ) </li></ul><ul><li>JMeter: до 240 rps на Core i7 </li></ul>
  13. 13. Тестирование: результаты <ul><li>От трех до семи нод, одна DB </li></ul><ul><li>Проблемы: ноды перетирают данные в базе (нет синхронизации) – сделали синхронизацию через memcached </li></ul><ul><li>Проблемы: APC через некоторое время перестает работать – стандартный glibc аллокатор сильно фрагментирует память (вспомните браузер FF 2.0) </li></ul>
  14. 14. Решение проблем <ul><li>Назад к memcached (slab allocator) </li></ul><ul><li>php-memcached работает , php-memcache - нет </li></ul><ul><li>Нет под Debian Lenny, пришлось сдлать бэкпорт пакета из Sid </li></ul><ul><li>Общий кэш, синхронизация через memcached на одной ноде </li></ul><ul><li>Один экземпляр memcached на всех </li></ul>
  15. 15. Новые вводные данные <ul><li>Заказчик – большая компания, нас тоже много </li></ul><ul><li>Требования конкретизируются прямо на ходу </li></ul><ul><li>Зон может быть до 100 </li></ul><ul><li>Limitations – работают при каждом запросе, кэширование всего ряда весов на 10 минут дает ошибочные результаты, так как limitations тоже кэшируются при этом </li></ul>
  16. 16. Новые проблемы <ul><li>Если веса нельзя кэшировать, нужно их пересчитывать </li></ul><ul><li>Данные кэшируются для зоны, 100 зон – 100 независимых пересчетов каждые 10 минут </li></ul><ul><li>200000 баннеров – 2000 баннеров в зоне – по 2000 повторений в циклах в коде PHP при каждом запросе ( limitations! ) </li></ul><ul><li>100 зон – 100 наборов таблиц в базе </li></ul><ul><li>Что делать? </li></ul>
  17. 17. Варианты решения <ul><li>Поменять алгоритм выбора – варианты? </li></ul><ul><li>Non-uniform distribution -> uniform distribution – только через отрезок, при этом 100 пересчетов </li></ul><ul><li>Хотим один пересчет </li></ul><ul><li>Вариант – наименьшее общее кратное весов, один отрезок с весами, выраженными через НОК </li></ul><ul><li>200000 баннеров - ~200000 записей в базе </li></ul><ul><li>Не выражать через uniform distribution, использовать веса по-другому </li></ul>
  18. 18. Компромисс <ul><li>Баннеров в зоне не более 200 </li></ul><ul><li>Зон по-прежнему может быть 100 </li></ul><ul><li>Всего три типа limitations </li></ul><ul><li>200 повторений в циклах PHP – приемлемо </li></ul><ul><li>Оставляем алгоритм расчета через uniform distribution </li></ul>
  19. 19. Изменения в коде <ul><li>Объекты баннеров до применения limitations хранятся в DB </li></ul><ul><li>Limitations транслируются из срокового представления в реляционное – три связи в структуре кэш-таблиц в DB </li></ul><ul><li>Применение limitations к баннерам это просто SQL- запрос </li></ul>
  20. 20. Пара слов о хостинге <ul><li>Первый этап – Amazon EC2 </li></ul><ul><li>Миграция на Rackspace Cloud </li></ul><ul><li>Проблемы: средняя нода облачного хостинга недостаточно производительна, а большая – недостаточно велика </li></ul><ul><li>Недостаточно производительности для создания тестовой нагрузки, недостаточно IOPS для эффективной работы DB </li></ul>
  21. 21. Тестирование: средства <ul><li>Siege не подходит: 100 зон, около 50 параметров для каждого из лимитов – нужно менять URL </li></ul><ul><li>JMeter: 240 rps на Core i7, в облаке – меньше </li></ul><ul><li>Tsung </li></ul>
  22. 22. Tsung <ul><li>Tsung: написан на Erlang – распределенность на уровне VM языка </li></ul><ul><li>Создавался с учетом многонодовых конфигураций </li></ul><ul><li>Может генерировать необходимую нам нагрузку </li></ul><ul><li>Строит отчеты в виде веб-страниц с графиками </li></ul>
  23. 23. Архитектура <ul><li>Представлена </li></ul><ul><li>на картинке </li></ul><ul><li>Картинку </li></ul><ul><li>перерисовывали 7 раз </li></ul>
  24. 24. Распределение нагрузки <ul><li>nginx, HAProxy </li></ul><ul><li>nginx – HTTP/1.0, генерирует кучу соединений, нет встроенного мониторинга состояния </li></ul><ul><li>HAProxy – HTTP/1.1, мониторинг состояния на web- странице, предназначен именно для балансировки, можно задавать политику балансировки </li></ul>
  25. 25. Тестирование: проблемы 1 <ul><li>8 web-nod, одна DB, 100 rps </li></ul><ul><li>Одна нода memcached не выдерживает поток запросов </li></ul><ul><li>Укрупнение объектов для кэширования в memcached </li></ul><ul><li>Распределенный memcached – на уровне библиотеки </li></ul><ul><li>Экземпляр memcached на каждой ноде </li></ul>
  26. 26. Тестирование: проблемы 2 <ul><li>12 web-nod, одна DB, ~250 rps </li></ul><ul><li>Большая нагрузка на web- ноды </li></ul><ul><li>Из 4-х циклов расчета весов после применения лимитов к множеству баннеров в зоне 2 цикла можно кэшировать </li></ul><ul><li>В коде осталось 2 цикла из 4-х </li></ul>
  27. 27. Тестирование: проблемы 3 <ul><li>Включили maintenance скрипт в cron – перестала справляться DB </li></ul><ul><li>Суть проблемы: раз в час таблица с raw logs очищается maintenance скриптом – блокировка таблиц на время удаления </li></ul><ul><li>Очевидные решения: InnoDB вместо MyISAM, разбиение операции удаления на несколько мелких запросов – не помогают </li></ul>
  28. 28. Декомпозиция DB, тюнинг выделенной части <ul><li>Выделение raw logs в отдельную базу на отдельном узле </li></ul><ul><li>Попытка поменять тип хранилища – MEMORY вместо InnoDB, ничего не дает, блокировки только хуже </li></ul><ul><li>Мониторинг, тюнинг MySQL – добавление памяти под InnoDB buffer pool, log buffer </li></ul>
  29. 29. Варианты решения <ul><li>MariaDB vs Percona Server – разницы в производительности нет </li></ul><ul><li>MySQL vs PostgreSQL </li></ul><ul><li>NoSQL vs MySQL </li></ul><ul><li>memcached – нет поддержки списков, Redis – есть поддержка списков, то, что нужно </li></ul><ul><li>Проблема: нужно переписывать код </li></ul><ul><li>Решение: никуда не мигрировать </li></ul>
  30. 30. Мониторинг <ul><li>Zabbix, Cacti </li></ul><ul><li>Cacti: mysql-cacti-templates от коллег из Percona </li></ul><ul><li>Zabbix: сильно нагружает сервер, data backend не в RRD, а в RDBMS, неоптимальные запросы (и неоптимизируемые) </li></ul><ul><li>Zabbix: выше частота опроса, легче смотреть моментальные состояния </li></ul>
  31. 31. Тюнинг FS <ul><li>По умолчанию ext3 с data=ordered </li></ul><ul><li>Перемонтировали с data=writeback, iowait вместо ~10% стал ~1.5% </li></ul><ul><li>Перемонтировали FS на всех DB нодах с data=writeback </li></ul>
  32. 32. Тестирование: проблемы 4 <ul><li>Теперь не справляются кэш-таблицы </li></ul><ul><li>На MySQL скачки I/O </li></ul><ul><li>Большое количество uncheckpointed bytes в мониторинге </li></ul><ul><li>Решение: вынести кэш-таблицы в отдельную DB </li></ul><ul><li>Решение: поменять тип хранилища на MEMORY </li></ul><ul><li>TRUNCATE TABLE работает очень быстро </li></ul>
  33. 33. Тестирование: проблемы 5 <ul><li>12 web- нод, ~300 rps, три ноды DB </li></ul><ul><li>Проблема: скачки I/O на cache DB </li></ul><ul><li>Проблема: тест в Tsung бежит 6 часов, после чего падает </li></ul><ul><li>Мониторинг: корреляция падений Tsung и скачков I/O на DB </li></ul>
  34. 34. Шардинг <ul><li>Мысли о шардинге были с самого начала, но по какому параметру разделять по шардам? И какие данные? </li></ul><ul><li>После декомпозиции на три базы ответ стал очевиден: нужно шардить по номеру зоны данные, хранящиеся в кэш-таблицах </li></ul><ul><li>Безграничные возможности для шардинга </li></ul><ul><li>Проблема: не все зоны получают одинаковую нагрузку </li></ul>
  35. 35. Тестирование <ul><li>12 web- нод, 300 rps, три ноды cache DB, одна нода raw logs DB и одна maintenance DB – тест бежит 42 часа, потом падает </li></ul><ul><li>~650 rps – тест бежит 6-7 часов </li></ul><ul><li>Мониторинг: нет корреляции падений Tsung и событий в системе </li></ul><ul><li>Вывод: проблемы Tsung </li></ul>
  36. 36. Предел <ul><li>~700 rps – начинаются ошибки на балансере </li></ul><ul><li>Мониторинг: нет корреляции с событиями в системе </li></ul><ul><li>Что падает - непонятно </li></ul><ul><li>Но задание уже выполнено – заказчик счастлив при 300 rps и пике в 600 rps в течение нескольких часов </li></ul>
  37. 37. Отказоустойчивость <ul><li>SPOF – распределенные узлы memcached </li></ul><ul><li>При падении одного узла таймаут на обращении к нему – все ложится </li></ul><ul><li>Варианты решения: репликация memcached, проксирование memcached </li></ul><ul><li>SPOF: узлы DB </li></ul>
  38. 38. Отказоустойчивость : Moxi <ul><li>Проксирование запросов к memcached – Moxi </li></ul><ul><li>Составная часть проекта Membase </li></ul><ul><li>Работает на 127.0.0.1:11211 </li></ul><ul><li>Знает топологию узлов memcached, скрывает ее от пользователя </li></ul><ul><li>Может мгновенно исключать упваший узел </li></ul><ul><li>Не может перенаправлять запросы к другим узлам в standalone конфигурации </li></ul>
  39. 39. Отказоустойчивость : Membase <ul><li>Работает на порту memcached по его протоколу </li></ul><ul><li>Два режима работы: с persistence и как кэш </li></ul><ul><li>Web- интерфейс (не конфигурируется через текстовые файлы) </li></ul><ul><li>При падении узла запросы автоматически перенаправляются на другие узлы </li></ul><ul><li>Данные, бывшие на узле, теряются – приложение должно инициировать пересчет </li></ul>
  40. 40. Отказоустойчивость : MySQL <ul><li>Master-slave репликация – не средство обеспечения автоматической отказоустойчивости </li></ul><ul><li>Master-master репликация – менее распространена, делается большим напряжением ума </li></ul><ul><li>SLA 99.95% - достаточно, чтобы время восстановления базы после сбоя было постоянным ( InnoDB, обойдемся без репликации) </li></ul><ul><li>DRBD + Heartbeat + Xen </li></ul>
  41. 41. Развертывание <ul><li>Chef, Puppet </li></ul><ul><li>Оба написаны на Ruby </li></ul><ul><li>Про Puppet есть книга, про Chef нет </li></ul><ul><li>Chef более ориентирован на развертывание Ruby- проектов </li></ul><ul><li>Puppet: вся конфигурация на сервереЮ, клиент получает инструкции и разворачивает ноду </li></ul><ul><li>Написаны Puppet- скрипты </li></ul>
  42. 42. Команда <ul><li>Участвовало от 5 до 8 человек </li></ul><ul><li>Разработка, интеграция, тестирование, документирование, координация </li></ul><ul><li>Производительностью занимались выделенные разработчики </li></ul><ul><li>Начало внедрения через полгода после старта проекта </li></ul>
  43. 43. Что дальше? <ul><li>Security assesment </li></ul><ul><li>Deployment </li></ul><ul><li>Релиз </li></ul><ul><li>Задача: распределить ввод-вывод по нескольким нодам параллельно </li></ul><ul><li>Задача: обсчитывать большие объемы для получения аналитических отчетов </li></ul><ul><li>Hadoop, MapReduce jobs вместо SQL </li></ul>
  44. 44. Выводы <ul><li>Времени всегда очень мало, вариантов может быть очень много </li></ul><ul><li>Система не должна быть черным ящиком </li></ul><ul><li>Не верьте в магию </li></ul><ul><li>Прежде, чем оптимизировать, нужно измерить </li></ul><ul><li>Знание высокоуровневых принципов оптимизации не спасает от огромного количества рутины – лучше иметь ответы на вопросы заранее </li></ul>
  45. 45. Вопросы?
  46. 46. Заказчик <ul><li>DataArt, http://www.dataart.com </li></ul><ul><li>Enjoy IT! </li></ul><ul><li>СПб, Большой Сампсониевский, 60А </li></ul>

×