HighLoad — повышение пропускной способности

Get Started. It's Free
or sign up with your email address
Rocket clouds
HighLoad — повышение пропускной способности by Mind Map: HighLoad —  повышение пропускной способности

1. P = C / t

1.1. Пропускная способность в единицу времени = кол-во одновременно обрабатываемых запросов / время обработки одного запроса

2. Уменьшение времени отклика

2.1. Железо (scale up)

2.1.1. Мощнее процессор

2.1.2. Быстрее storage

2.1.2.1. SAS

2.1.2.2. SSD

2.1.2.2.1. Intel X25-E

2.1.2.2.2. Ограничения SSD

2.1.2.3. PCIx cards

2.1.2.3.1. FusionIO

2.1.2.3.2. OCZ

2.1.2.4. RAID

2.1.2.4.1. RAID-0

2.1.2.4.2. RAID-1

2.1.2.4.3. RAID-10

2.1.2.5. SAN / NAS

2.1.2.5.1. fibrechannel

2.1.2.5.2. в основном в enterprise-секторе

2.1.3. Память

2.1.3.1. Больше кэшей

2.2. Оптимизация

2.2.1. premature optimization

2.2.1.1. 80% опт. алгоритма

2.2.1.2. 15% опт. кода

2.2.1.3. 5% отп. машинного кода

2.2.2. "10/90", десять процентов кода "съедают" девяносто процентов производительности системы

2.2.3. замеряйте прежде чем менять!

2.2.3.1. профайлинг!!!

2.2.3.1.1. полноценный профайлер

2.2.3.1.2. контрольные точки

2.2.3.1.3. мониторинг времени выполнения запросов (к СУБД, внешним API и т.п.)

2.2.4. Работа с СУБД

2.2.4.1. оптимизация запросов

2.2.4.1.1. мониторим медленные запросы

2.2.4.2. индексы

2.2.4.2.1. use EXPLAIN!

2.2.4.3. денормализация

2.2.4.3.1. осознанный отход от нормальных форм

2.2.4.3.2. – лишний join – сортировка – группировка – фильтрация – агрегация из разных источников – горизонтальное разбиение таблиц

2.2.4.4. хороший и правильный запрос к БД – тот, которого нет ;)

2.3. Кэширование

2.3.1. Что кэшировать?

2.3.1.1. Записи из СУБД

2.3.1.1.1. NO JOIN !

2.3.1.2. Результаты вычислений / значения фукнций

2.3.1.3. Сериализованные объекты

2.3.1.4. Информационные блоки страниц

2.3.1.5. HTTP-ответы целиком

2.3.1.5.1. Last-Modified / If-Modified-Since

2.3.1.5.2. nginx memcached_pass

2.3.2. Нюансы

2.3.2.1. Надо следить за актуальностью данных в кэше

2.3.2.1.1. при изменение данных удаляем ключ в кэше

2.3.2.1.2. при изменении данных синхронно изменяем и в кэше и в БД

2.3.2.1.3. писать только в кэш, асинхронно писать в базу

2.3.2.2. эффективность

2.3.2.2.1. соотношения hit / miss / set

2.3.2.3. "Разогрев" кэша

2.3.2.3.1. пока кэш не разогрет -- всё может тормозить

2.3.2.4. используйте сжатие больших значений

2.3.2.4.1. экономит память и сеть

2.3.3. Удаление старых значений

2.3.3.1. LRU

2.3.3.1.1. least recently used

2.3.3.1.2. last recently used

2.3.3.2. timeout expiration

2.3.4. как кэшировать?

2.3.4.1. memcached

2.3.4.1.1. LJ, slashdot, digg, facebook

2.3.4.1.2. multi-get, stats

2.3.4.1.3. время жизни, LRU и пролонгация

2.3.4.2. внутри процесса

2.3.4.3. в файлах, БД

2.3.4.4. многоуровневое кэширование

2.3.5. Выбор ключа кэширования

2.3.5.1. serialize($options)

2.3.5.2. Если получаются длинные ключи?

2.3.5.2.1. hash($key)

2.4. Тюнинг ОС / СУБД / инфраструктурного ПО

2.4.1. Тюнинг ОС

2.4.1.1. настройки сокетов

2.4.2. Тюнинг СУБД

2.4.2.1. mysql

2.4.2.1.1. query cache

2.4.2.1.2. буферы

2.4.2.1.3. my-huge.cnf

2.4.2.1.4. MySQLTuner

2.4.2.1.5. настройки storage engines

2.4.2.1.6. мониторим

2.4.2.2. Сложно

2.4.2.3. клоны MySQL

2.4.2.3.1. MariaDB

2.4.3. Тюнинг ФС

2.4.3.1. XFS

2.4.3.2. ZFS

2.4.4. мониторим нагрузку!

2.4.4.1. iostat

2.4.4.2. dstat

2.4.4.3. top, atop

2.4.4.4. грамотный сисадмин / администратор СУБД решает!

2.5. Хитрости

2.5.1. постепенная генерация / отдача контента

2.5.1.1. Яндекс SERP на Perl

2.5.2. тяжелые действия асинхронно -- уже после отдечи ответа клиенту

3. Увеличение количества одновременно обрабатываемых запросов

3.1. Масштабирование (кластеры)

3.1.1. График: затраты / профит

3.1.2. Почти никогда не бывает полностью линейным

3.1.2.1. Overhead

3.1.2.1.1. Блокировки

3.1.2.1.2. Разделяемые / общие ресурсы

3.1.2.1.3. Затраты на коммуникацию / синхронизацию

3.1.2.1.4. Алгоритмический overhead

3.1.3. web-серверов

3.1.4. баз-данных

3.1.5. кэширующих серверов

3.1.5.1. Распределение нагрузки

3.1.5.1.1. builtin

3.1.5.1.2. ручное

3.1.5.1.3. ketama

3.1.6. Способы масштабирования

3.1.6.1. scale up (вертикальное)

3.1.6.1.1. Больше ядер CPU / больше памяти

3.1.6.1.2. ограничения горизонтального масштабирования

3.1.6.2. scale out (горизонтальное)

3.1.7. Уменьшаем связность

3.1.7.1. компонентная архитектура (связность в пространстве / монолитность)

3.1.7.1.1. RPC

3.1.7.2. асинхронная обработка (связность во времени)

4. "Иерархия памяти"

4.1. с точки зрения скорости доступа

4.1.1. CPU < 1E-9 s

4.1.2. RAM < 1E-6 s

4.1.3. Net < 1E-5 s

4.1.4. Disk < 1E-4 s

4.1.4.1. "слабое звено"

4.1.4.2. читать лучше помногу и последовательно

4.1.4.3. запись асинхронная

4.1.4.4. будущее за SSD