Основы построения масштабируемых высоконагруженных веб-проектов Семинар (8 часов) Алексей Рыбак Badoo Development (badoo.com) Задачка на разминку Пусть в нашем распоряжении имеется некоторый веб-сервер. Выполняя запросы, часть времени он проводит в ожидании ответов от удаленного сервера базы данных, остальное время занимает работа процессора. Считая, что ресурсы базы данных и пропускная способность сети – неограниченны: при каких условиях сервер может отдавать 1000 запросов в секунду? Наш план • Введение • Базовые компоненты и архитектуры • Управление и поддержка больших проектов • Избранное по заявкам, обсуждение проблем, любые ваши вопросы 0. Введение Кто зачем пришёл (1/2) • • • Не очень хорошо знаком с архитектурой и принципами масштабирования много-серверных систем, хочу узнать основы В нашем проекте уже несколько серверов, хочу узнать, как расти дальше Мне всё более-менее понятно, хочу систематизировать знания и получить консультации по ряду вопросов Кто зачем пришел (2/2) • • • • • программист администратор руководитель группы/отдела всё вышеперечисленное ничего из выше перечисленного Ещё пару вводных слов • Стек технологий – LNMP • Многие проблемы носят фундаментальный характер • Постараемся «перезагрузить» мозг • Будет много живого общения • Не стесняйтесь прерывать и задавать вопросы • Будет много флипчарт-сессий Почему “перезагрузить” мозг? Как программирует «продвинутый новичок»? 1. Осознаёт предметную область (бизнесанализ, пользовательские сценарии) 2. Создаёт «модель» и «над-язык» (данные, сущности, операции над ними) 3. Пишет код, внося изменения в над-язык (реже – пересматривая модель) • • • В п.2 мы кое-что забыли Модель не имеет системного каркаса Нужна верификация модели с системной точки зрения – системное проектирование Проектирование (1/2) • Многоуровневый анализ • Логический уровень: модель данных • Software-уровень: ОС, ФС, вебсервера, базы данных и другие базовые компоненты • Hardware-уровень: диски, память, сеть, CPU … • У всех компонент – и программных, и железных - есть свои важные особенности, которые играют колоссальную роль Проектирование (2/2) • Любой архитектор обязан иметь навыки системного администрирования • Правильное «объединение» всех компонент • О масштабировании нужно заботиться заранее • Всё это - не преждевременная оптимизация Сети массового обслуживания • Массовый поток требований случайного характера • Телефонные станции, супермаркеты, автомагистрали, call-центры, ремонтные предприятия…и конечно интернет-проекты! • Первая работа - А.К.Эрланг, «The Theory of Probabilities and Telephone conversations», 1909 • Не пугайтесь, не будем углубляться в математику, главное – «чувствовать» модели Базовая модель очередь канал обслуживания обслуженные заявки требования переполнение: отказы Характеристики: • число требований в ед. t • пропускная способность (число обслуженных требований) • среднее время обслуживания, распределение (моменты) • число отказов в ед. t Важное свойство: нелинейная (стремительная) «деградация» N-канальная СМО с ожиданием каналы (N) очередь требования Ищите подобные модели в своих проектах. Это - архитектура вашего бизнеса. Остальное – в-общем, вторично. обслуженные заявки Цели изучения СМО Повышение эффективности: • Пропускная способность • Время ожидания • Совокупная стоимость Попробуем рассчитать на «пальцах» проект • • • • • • • • • • • Суточная аудитория - 10 млн человек Оператор – процесс веб-сервера Требование – запрос от браузера Расчёт крайне грубый Время на один запрос – 0.1 сек 75% загрузка: 24 час X 45 мин X 60 сек = 64800 сек Всего запросов на оператора 64800*10 = 0.648 млн Каждый пользователь делает 30 кликов Всего запросов 30*10млн = 300 млн На один сервер – 10 процессов Число серверов 300 / (10*0.648) = 46.2 Этот расчёт – неверный • Не учитываем «случайность» распределения • Не учитываем структуру запросов (1 хит != 1 запрос) • Не учитываем суточное распределение • Для UGC 10 млн на практике – это сотни, а то и тысячи серверов • В жизни системы куда сложнее, поэтому иной раз проще не считать, а сразу проводить измерения Базовые софтверные компоненты проекта • Веб-сервер • Сервер приложений (может быть интегрирован в веб-сервер) • СУБД • Кеш-сервер • Цель: «прокачать» как можно больше хитов за как можно меньшие деньги заработали Масштабирование линейное нелинейное линейное, но с плохой производительностью потратили Говорят, что scaling и performance – разные вещи. Это не совсем так. Это всё про деньги. Scaling – класс кривой, Performance – её характер (например, угол наклона) 1. Базовые компоненты и архитектуры Скорость доступа к данным типичные цифры Memory #00 #01 cache cache CPU <1e-9 s “HARD” DISK >1e-4 s < 1e-6 s FS cache Network >1e-5 s Диск – слабое звено • Если что-то лежит на диске, не меняется и часто читается – оно мгновенно в FS cache и доступ к нему такой же быстрый как к памяти • Считать по сети из памяти удаленной машины чаще быстрее, чем с локального диска • Читать/писать последовательно и много – значительно выгоднее • Пакетная запись на диск: накопили в памяти и сбросили. Можно вовсе асинхронно (возможны потери). • Будущее – за SSD Linux: параллелизм • Процессы (processes) • Трэды (threads) • Для осуществления «параллельной» работы необходимы переключения между режимами ядра и задачи переключение контекста (context switch) • Ключевой момент для большинства классов серверов – модель обработки сетевых соединений Модели обработки сетевых соединений • Process per connection – CGI: fork per connection – Pooling: Apache (v.1, mpm_prefork – min, max, spare), PostgreSQL+pgpool, PHP-FPM … • Thread per connection – Pooling: Apache (mpm_worker – min, max, spare), MySQL(thread_cache) • FSM (finite state machine) – – – – «современные» ядра: kqueue, epoll общий интерфейс libevent, libev FSM + process pooling: nginx FSM + thread pooling: memcached v>1.4 Обработка сетевых соединений веб-сервером • process-per-connection (apache 1, 2 mpm_prefork) • медленные клиенты = куча процессов • thread-per-connection (apache 2 mpm_worker) • медленные клиенты = куча потоков • Keep-Alive – 90% неактивных клиентов • накладные расходы – context switches, RAM • “lightweight“ (nginx, lighttpd, …) • nginx (не нгинкс, не нжинекс и даже не нгинекс, а эн-жин-ыкс (engine-x)!) flipchart case #1 • Отдача статики веб-сервером Почему nginx? • 1 master + N workers (10**3 – 10**4 conn) • N: CPU, вероятность блокирующих операций • FSM + поддержка эффективных методов работы с соединениями • большое внимание к скорости и качеству кода • минимум копирования данных • Keep-Alive: 100Kbytes active / 250 bytes inactive • очень удобная конфигурация • даже есть встроенный кастрированный perl • sysoev.ru, apache-talk@lexa.ru Типичная конфигурация веб-сервера • Что делает сервер? • Выполняет код • Обслуживает клиента • Разве повар принимает заказ? • Разные задачи, разделить • Двухуровневая схема (frontend/backend) • nginx + Apache + mod_php, mod_perl, mod_python • nginx + FCGI (например, php-fpm) [front/back]end: концепт «тяжеловесный» сервер (HWS) «легковесный» сервер (LWS) nginx «быстрые» и «медленные» клиенты «статика», SSI, perl Apache mod_php, mod_perl, mod_python FastCGI «динамикa» [front/back]end:масштабирование N/Nb N/Nf B F B SLB F F B B • F и В – «логический» уровень • F и B гомогенны (обслуживание, замена) • F и B могут быть разными «физическими» серверами или одним сервером (единый однородный «слой» серверов, на каждом LWS и HWS) заработали Масштабирование линейное потратили Масштабирование веб-кластера • Гомогенность: при большом числе серверов можно не разделять front- и back-endы • Независимость компонент • Минимум общих ресурсов (share-nothing => share accurately) • Некоторые распространённые ловушки: – общие данные на nfs (сессии, код) => локальные копии кода, сессии в memcached – локальный кеш => общий кеш – что-то пишем в базу realtime => сделать тяжелые операции асинхронными nginx: load balancing upstream server server server } backend { backend1.example.com weight=5; backend2.example.com:8080; unix:/tmp/backend3; server { location / { proxy_pass http://backend; } } nginx: fastcgi upstream backend { server www1.lan:8080 weight=2; server www2.lan:8080; } server { location / { fastcgi_index index.phtml; fastcgi_param [param] [value] ... fastcgi_pass backend; } } Отдача защищенной статики • через скрипт – плохо («тяжелый» процесс на каждого клиента) • X-Accel-Redirect («тяжелый» процесс быстро проверяет, можно ли отдавать, и даёт «указание» веб-серверу) • модули (URL-сертификаты) • http://sysoev.ru/nginx/docs/http/ngx_http_secure_link_ module.html • http://wiki.nginx.org/NginxHttpAccessKeyModule Кеширование • «память»-10-9-10-6,«сеть»-10-4,«диск»-10-3 и выше • страницы(+картинки и т.д.), HTML-блоки, «объекты» • эффективность: соотношения hit/miss/set, «кешпамять на одного юзера» • HTML-блоки: не всегда эффективно • А был ли мальчик? (if-modified-since) • Кеширование веб-сервером (прокси-кэш) • Объектный кеш: сериализованные данные • «Некогерентный»(несогласованный) кеш Несогласованность локального кеша LC frontend backend LC data data backend Global Cache Global Cache Global Cache memcached • danga.com/memcached/ (LiveJournal) • «глобальный» кеш-сервер • оптимизированная работа с памятью (slab alloc, object versions) и сетевыми соединениями (libevent) • Крупнейшие мировые проекты: LJ, slashdot, digg, facebook (десятки терабайт) • идеален для сессий, объектного кеша • multi-get, stats (get, set, hit, miss + slab info) • легко масштабировать • i = crc32(key)%N и вариации • время жизни, LRU и пролонгация • неидеально написан, особенно после facebook Кластеризация сессий • http-conn: кидаем клиента на один сервер в рамках сессии (производительность, неравномерная нагрузка) • NFS: никакая масштабируемость, SPOF, “nfs stale handle”, скорость • Database: SPOF, скорость (лучше: heap, cluster) • Memory: высокая скорость, почти линейная маcштабируемость. Memcached, Zend Session clustering flipchart session • Есть ли вопросы? • Case#2: база знаний (википедия) • Case#3: медиа-хранилище (фото-видеохостинг, файлопомойка) Компоненты (cont.) Что ещё входит в базовые компоненты: • Application servers: обычно интергированы в веб-сервер (исключение - FCGI). Пару слов про PHP-FPM и особенности PHP • СУБД (MySQL) Приложения • • • • Приложения на скриптовых языках «Собирают» динамические страницы Много блокирующего IO Часто создают существенную нагрузку на CPU • В качестве примера рассмотрим PHP Особенности PHP • Acceleration (APC, xcache, ZPS, eAccelerator) • memory & CPU usage (zval: C(1M), Perl(10M), PHP(20M)) • modules rock! • FCGI (fpm) FPM • PHP-FPM: PHP FastCGI process manager • Менеджер FastCGI-процессов для PHP • Архитектура сервера напоминает nginx (master + N workers) PHP-FPM: эксплуатация • Плавно обновляться, не теряя соединения • Видеть все ошибки • Автоматически реагировать на подозрительное поведение воркеров (выход, тормоза, массовые падения) • New: динамическое количество воркеров (apache-like) PHP-PFM: основные возможности • Плавный перезапуск/обновление кода • Мастер ловит stderr воркеров • Автоматический трейсинг и завершение работы медленных воркеров • Аварийный перезапуск при массовом падении воркеров PHP-PFM: доп. возможности • Error header снимает проклятие пустой белой страницы (200 OK на ошибку) • fastcgi_finish_request() – отдать output клиенту, но продолжить работу (сессии, статистика и т.д.) • Accelerated upload (поддержка request_body_file - nginx 0.5.9+) FPM на пути к PHP • Mamba, Badoo (2004-2006): набор разрозненных патчей • Андрей Нигматулин. 2007: один патч поверх PHP (5.3.0-0.5.12, http://php-fpm.org) • 2009: проект отнимает массу времени, «берёт руководство» Michael Shadle, коммитит dreamcat4 http://launchpad.net/phpfpm • Конец 2009 … Антон Довгаль, Jerome Loyet FPM наконец в PHP! Отдельный SAPI, 5.3.*. • Groups: highload-php(en|ru)@googlegroups.com Базы данных • Самый «капризный» компонент • Пофантазируем о том, как бы мы разрабатывали СУБД • Поймем «модель» обслуживания • Поговорим о масштабировании Вы - БД и выполняете SELECT в первом приближении: • установить соединение, выделить ресурсы • скорость, память на стороне сервера… • получить запрос • проверить кэш запросов • разобрать SQL-выражение • bind vars, stored proc… • получить данные • index lookup, buffer cache, disk read • отсортировать данные • in-memory, filesort, key buffer • отдать результат • очистить ресурсы, закрыть соединение MySQL: кратко о самом важном • • • • • • • • • • • • • Движки - MyISAM, InnoDB, Memory(Heap); Pluggable Блокировка: MyISAM на уровне таблиц, InnoDB на уровне строк «Ручные» блокировки: select lock, select for update Индексы: B-TREE, HASH (no BITMAP) point->rangescan->fullscan; fully matching prefix; innoDB PK: clustering, data(“using index”), myisam key cache, innodb buffer pool dirty buffers, transaction logs: innodb_flush_trx_log_at_commit many indexes – heavy updates sorting: in-memory (sort buffers), filesort USE EXPLAIN! Using temporary, using filesort innodb_flush_method = O_DIRECT лучше использовать маленькие таблицы вместо одной большой Проектирование • • • • • • типы приложений: OLAP/OLTP обычно OLAP – MyISAM, OLTP - InnoDB представьте, что вы – БД какие операции следует выполнить? нельзя ли заменить одни операции другими? нельзя ли вовсе отказаться от каких-либо операций? • хороший и правильный запрос к БД – тот, которого нет ;) • не бойтесь денормализации • позаботьтесь о масштабировании заранее Денормализация • шашечки или ехать? • денормализация – лишний join – сортировка – группировка – фильтрация – агрегация из разных источников – горизонтальное разбиение таблиц • Кейсы – Case#4: Счётчики – Case#5: Деревья в БД – Case#6: Поисковый индекс Некоторые «приёмчики» • • • • multi-операции On duplicate update table switching (rename) memory tables как результаты промежуточных вычислений • updated = updated СУБД: масштабирование • • • • • • • • пользовательский контент ОЧЕНЬ много IUD-операций линейное масштабирование репликация или кластеризация (sharding) эксплуатация, стоимость владения отказоустойчивость, мин. SPOF балансировка нагрузки удобство обслуживания Масштабирование • Scale up vs Scale out • Репликация (очень нелинейное) • Вертикальное: по задачам (по таблицам) • Горизонтальное: по «основным» сущностям – пользователям, документам и т.д. – sharding Репликация «на пальцах» • Был один сервер w/r << 1 • Добавили ещё один, 100% рост • Но w/r на мастере растёт – w не масштабируются • Чем больше серверов – тем хуже • Социальные сервисы – много операций записи Проблемы репликации • Линейна только при очень малом числе серверов (writes не масштабируются) • Очень много данных • Неэффективная утилизация ресурсов (копии данных на диске и в кеше) • Особенности реализации (MySQL: раздача лога, один тред и т.д. – и порождённые извращения) G: 1) больше, если «тяжелее» writes 2) больше для приложений с интенсивной записью MySQL: replication filtering • Master: binlog-[do|ignore]-db • фильтр «ручками»: SET SQL_BIN_LOG=0 • Slave: replicate[|-wild]-[do|ignore]-[db|table] • BLACKHOLE engine: «черная дыра», no data Master Server#1 Black hole «dummy» slave Server#1 filtered binlog для slaves Server#2 Relay slaves • --log-slave-updates • топология master slave – 1 relay, M slaves – M (relay + slave) – и вариации на тему relay slave slave slave slave Масштабирование заработали линейное потратили Sharding: разделение данных • Статическое (детерминированное), num_key%n_serv, crc32(md5(str_key))%n_serv, «первая буква логина» и т.д. • Это практически неуправляемо • Математические трюки: магические 12, 24 и прочие – всё равно плохо • «Динамическое»: добавление новых машин, замена, перенос, балансировка – без изменения кода • Минус динамического: часть приложения, которая отвечает за адресацию – SPOF, м.б. высокая нагрузка Sharding: прозрачность • Минимум головной боли при поддержке • Управление разделением данных без вмешательства в код • «Проксирование» • Координирующий сервис (отвечает на вопрос “где?”) • Динамическая координация менее прозрачна, но архитектурно более правильна • «Виртуализация» физических координат {server, db_suffix, table_suffix} => storage_id где? Координатор WebApp Node # 1234 data Storage nodes Case#7: Sharding • flipchart! • самый сложный для понимания материал • не стесняйтесь задавать вопросы! MySQL в Badoo (1/2) • минимизировать совокупную стоимость владения • максимально гибко контролировать все подсистемы • минус в теории - плюс на практике • MySQL не даёт "нагородить" сложные зависимости между данными • MySQL не диктует неэффективную или сложно управляемую архитектуру • многие проблемы больших проектов схожи и не зависят от выбора СУБД • cost-oriented development MySQL в Badoo (2/2) • InnoDB • никаких сложных запросов, FK, триггеров и процедур • "продвинутая" репликация • "продвинутый" апгрейд схем данных • шардинг - виртуализация "физических" координат {serverX, dbY, tableZ} => shard_id • никаких "прозрачных" прокси • динамическая координация клиентов • очереди событий на базе MySQL • архитектура не меняется пятый год (рост с 0 до 80 млн пользователей, несколько ДЦ) Очереди • Если шардинг – это разделение в пространстве, то очередь – разделение во времени • Если что-то можно сделать потом – пусть клиент не ждёт • Легко сделать «универсальный» фреймворк для работы с очередями RPC • • • • RPC = Remote procedure calls Синхронно: удаленные сервисы Асинхронно: очереди Вариации: логически синхронно, физически асинхронно • Проблема транзакционной целостности RPC/MQ: концепт request “client” result “server” синхронное, “point-to-point” асинхронное, “publisher-subscriber” “client” “server” message Message Queue Consumers MQ на БД “publisher” “subscriber” database 1) enqueue/dequeue 2) publish 1) enqueue/dequeue 2) subscribe/receive Универсальная очередь • • • • • {event_class, event_data} Внутри базы – нет проблем с транзакциями Publisher/Subscriber Диспетчеризация событий Топология: (де)централизованная доставка и обработка Case#8: очередь • flipchart! • модель данных • сбор данных • failover • децентрализованная очередь Особенности архитектур • flipchart! • Case#9: Сетевое СМИ • Case#10: Социальная сеть Кризисы роста • • • • Один сервер Несколько серверов (скажем, десять) Много серверов (сотни, тысячи… много ДЦ) И ещё чтобы не очень падало и удобно поддерживалось • Переход между уровнями обычно сопровождается «кризисом» • Ключевое значение играет масштабируемая архитектура Масштабируемая архитектура • Независимые или слабо-связанные веб-сервера • Горизонтальное разделение данных • RPC (сервисы, очереди) • Обслуживание без вмешательства в код Некоторые ловушки • Высокая степень связанности (данных, процедур, компонент) – плохое масштабирование • Полу-решения (накапливание рисков) • Плохо управляемые инструменты • Горе от ума (решения с позиций «теоретиков», вредные с инженерной точки зрения). Классический пример - ORM Что читать? • RTFM ;) • Слайды с конференций – mysql, velocity, osconn. tutorials, архитектура wikipedia, fotolog, youtube … highscalability.com • Блоги - особенно тех, кто занимается консалтингом http://jcole.us/blog/, http://www.mysqlperformanceblog.com/ фид http://www.planetmysql.com – сборная солянка • Books - немного High Performance MySQL (2nd ed. Shwartz, Zaitsev & co), Building Scalable Web Sites (Henderson), Scalable Internet Architectures (Schlossnagle), Настройка производительности UNIXсистем (Мусумеси, Лукидес) – вообще о производительности, книги издательства MySQL AB Press (руководство администратора и тд); Managing gigabytes, Architecture of a Database System 2. Управление и поддержка больших проектов Большие проекты • Миллионы пользователей • 24x7 • «Много» серверов • Многозвенная архитектура • Мегабайты кода • Зоопарк! • Быстрый или мертвый «Технологические» риски • тормозим (или лежим) • медленно реагируем на ошибки (не реагируем или совсем не видим). • плохо масштабируемся (или вообще не масштабируемся) • медленно меняемся (или не способны меняться) • высокая стоимости владения, низкий возврат инвестиций и т.д. development+support=100% 100% • маленькие проекты • начало проекта Development (time) «динамичные» проекты «загнанные», неразвивающиеся проекты, «динозавтры» Support (time) 100% Кривой «технологический» менеджмент приводит к тяжелым болезням роста Разработка с учётом дальнейшей поддержки • бизнес-идея • модель • варианты реализаций • верификация • планирование • производственные работы наиболее распространенная ошибка: не видим, что происходит на «физическом» уровне например, какие операции происходят в процессе обработки запроса René Magritte Les amants Что нужно видеть? • вспомните о моделях СМО • запросы к СУБД и внешним сервисам, прочие «блокирующие» или «тяжелые» операции • простые измерения «ручками» таймеры • ошибки (любые!) Поддержка • время между возникновением внештатной ситуации и её исправлением должно быть минимальным • жизненный цикл проблемы визуализация WTF? неопределённость интеллект команды ! ;) предсказуемость Инструменты Development: визуализация потенциально узких мест (debug toolbar, логи), тесты Production: мониторинг (расширенный), измерение производительности в реальном времени, сбор и анализ логов Error_log! плохо «пожалуйста, сообщите нам об этом» и «не забудьте указать адрес страницы» хорошо «Все ходы записаны. Мы уже изучаем, почему такое могло произойти. Приходите ещё, мы обязательно исправим все косяки» Мониторинг • измеряй и властвуй • «тупой» мониторинг серверов не даёт нужной информации • нужен мониторинг приложения и компонент • измерение качества архитектуры • открытость: общее видение системы у всех членов команды • снижение стоимости владения, повышение качества поддержки PINBA: мониторинг в режиме реального времени req/sec average time • Scripts • Virtual hosts • Physical servers Краткая история одной аварии с иллюстрациями время обработки запроса WTF? Теперь нам известны скрипты, периодичность, и более-менее ясно, где копать дальше Анализ данных • • • • найти, где копать включить детальную отладку анализ графиков пики, периоды, характерные масштабы • распределения, достаточное качество Идеальный для саппорта софт меряет сам себя Эксплуатация веб-кластера • Число запросов (полное, на сервер …) • Время ответа (среднее, распределение, по скриптам, по серверам …) • Использование ресурсов (rusage) • Непрерывный мониторинг в реальном времени • Качество приложений - что меняется при релизах? PINBA: архитектура • Клиентский модуль для PHP • Для любого запроса собираем script_name, host, time, rusage … • При завершении отправляем UDP • И так со всех машин веб-кластера • Серверный тред внутри MySQL (v. 5.1.0+) • SQL-интерфейс ко всем данным PINBA: данные • request: script_name, host, domain, time, rusage, mempeak, output size, timers • timers: время + пары “ключ (тэг) – значение” • пример: 0.001 sec; {group => db::update, server => dbs42} PINBA: Отчёты • SQL: “сырые” данные или отчеты • Отчеты – это отдельные таблицы, обновляются «на лету» • Базовые отчёты (~10): по системе, по скриптам, по хост+скрипт… • Отчеты по произвольным тегам (ENGINE=PINBA COMMENT='report:foo,bar‘) => {script_name, foo_value, bar_value, count, time} • http://pinba.org – много примеров Например, так «протухает» код Наимедлейшие из медленных Memcached: статистика • • • • • • • Stats Stats slabs Stats items Stats cachedump Req/sec Hit/miss Bytes read/written Memcached: stats Cachedump (1/4) 17й слаб = 128 K stats cachedump 17 ITEM uin_search_ZHJhZ29uXzIwMDM0QGhvdG1haWwuY29t [65470 b; 1272983719 s] ITEM uin_search_YW5nZWw1dHJpYW5hZEBob3RtYWlsLmNvbQ== [65529 b; 1272974774 s] ITEM unreaded_contacts_count_55857620 [83253 b; 1272498369 s] ITEM antispam_gui_1676698422010-04-17 [83835 b; 1271677328 s] ITEM antispam_gui_1708317782010-04-15 [123400 b; 1271523593 s] ITEM psl_24139020 [65501 b; 1271335111 s] END Cachedump (2/4) • • • • • • Выдираем из cachedump имя группы Распределение по размеру (аномалии) Просто ошибки Или пора включать архивацию Или разбивать объекты Для memcached большой объект это очень плохо: все ждут Cachedump (3/4) • Выдираем из cachedump имя группы • Распределение по времени доступа • Можно тоньше играть со временами хранения • t жизни >> t времени доступа • Уменьшить время хранения для данной группы Cachedump (4/4) • довольно медленно • не всё (по крайней мере, в старых версиях) • трактуйте результаты как статистические "сэмплы" • или увеличивайте статический буфер в исходниках auto debug & profiling (1/1) • Callgrind и т.п. – хорошо, но много • Снижаем размерность: мерить только то, что потенциально «тормозит» (disc, запросы к «сервисам» – db, memcached, с/c++,…) • И ещё average time, CPU, число запросов по группам • Автоматически добавим в конец любой страницы • Devel: всегда включен • Production: можем писать в лог auto debug & profiling (2/2) • • • • что происходит на «физическом» уровне визуализация СМО визуализирован «cost» любого ответа с бэкенда легко ловить нетривиальные «косяки» – при рефреше нет dbq->memq – много «get’ов» вместо «multiget’a» (или insert’a) – межсерверные транзакции – несколько разных соединений с одной и той же базой – cache-set при "лежащей" базе/ошибке – чтение со slave данных, только что записанных на master – и так далее… Что измерять • • • • Меряйте больше! сonn/req, cpu/mem usage для всех сервисов Статистику с баз, apache/nginx… Memcached: get/miss по группам ключей, расширенная статистика (slabs + items) • la, cpu/mem usage с серверов • Характерные времена загрузки на клиенте (DOM_READY, ON_LOAD) – МЕГА ВАЖНО • network… Вопросы на выбор • • • • • • • • • • • задавайте любые нагрузочное тестирование программа пост-анализа мониторинга сбор и обработка логов выкладка в бой среда (devel, stage, production) откаты/накаты схем SQL vs NoSQL профилирование скриптов найм, собеседование минусы “Agile” Спасибо! • alexey.rybak@gmail.com • Если Вы хотите получить презентацию – заполните, пожалуйста анкету • Буду крайне признателен за любые отзывы и пожелания, особенно критические