Документ описывает основные принципы оптимизации производительности при разработке программного обеспечения, включая проблемы с кэшированием, нагрузочным тестированием и управления базами данных. Он подчеркивает важность мониторинга метрик и избегания ошибок на продакшне, а также указывает на необходимость соблюдения четких стандартов разработки. В конце даются рекомендации по применению транзакций и выбору корректного уровня изоляции данных.

1. Приключения проекта от
компьютера
разработчика до
серьезных нагрузок
Минкин Андрей maddevs.io

2. Кто я
• Тимлид в Mad Devs
• Nambataxi.kg
• Nambafood.kg

3. Начало
• Кодим
• Тестируем
• Запускаем в продакшн

4. Глаза на продакшне
• Мониторинг
• Сбор метрик
• Сбор ошибок
• Трейсинг

5. Какая нагрузка бывает
• Disk IO
• Net
• RAM
• CPU

6. Проблемы воспроизведения ситуации
• Нагрузочное тестирование может не работать
• Пользователь думает по-другому
• Окружение разное
• Продакшн
• Стейджинг
• Компьютер разработчика

7. У меня на компе работает
• Нет
• Нельзя так думать
•Вы не в детском саду
•Вы ответственны за ваш проект в продакшне
•Вам с этим жить

9. Как быть?
• Оптимизировать код
• Внедрять кэширование
• Масштабировать

10. Как правильно оптимизировать
• Собрать метрики
• Проанализировать
• Оптимизировать
• Задеплоить
• Повторить

11. 20 % методов -> 80% нагрузки

12. Принципы оптимизаций
• БД
• Убиваем N+1 запросы(+join)
• Расставляем индексы
• Убиваем бесконечные циклы
• Адаптируем алгоритмы
• Кэшируем данные
• Масштабируем

13. Внедрение кэширования

14. Проблема №1

15. Кэширование есть, а пользователи жалуются
• Один пользователь доволен
• Страницы быстро грузятся
• Другой нет
• Все медленно работает

16. Как проверить работает ли кэш?
• %hit rate
• %miss rate

17. Анализ показателей
• current > 95% – отлично
• 85 < current < 95 – хорошо
• current < 80 – плохо

18. Почему это плохо
• Мы сходили в кэш
• Там нет ключа
• Пошли генерить данные по-новой
• Отдали клиенту

19. Почему это плохо
• Мы сходили в кэш
• Там нет ключа
• Пошли генерить данные по новой
• Отдали клиенту

20. Проблема №2
• Холодный старт кэша
• Все серверы выключились
• Нужно запустить проект
• Проверить, что все работает

21. Как поднять проект после блэкаута
• Запускаем сервера
• Запускаем виртуалки
• Запускаем сервисы
• БД
• Кэши
• Хранилища

22. Как поднять проект после блэкаута
• Закрываем проект от пользователей
• Прогреваем кэш
• Автоматически
• Вручную
• Проверяем работу
• Открываем проект

23. Как закрыть проект для всех (nginx)
set $m "";
set $i "";
if ( -f /tmp/offline ) {set $m T;}
if ($remote_addr = 'your ip') {set $i "${m}";}
if ($i) { break; }
if ($m) {return 503;}

24. Проблема №3

25. Нагрузка маленькая, но все тормозит
• Смотрим память – все ОК
• Смотрим проц – все ОК
• Смотрим базу – все ОК
• Смотрим диски – все ОК
• Ничего не тормозит
• НО ГЛАВНАЯ НЕ РАБОТАЕТ

26. Что говорят графики
• Диски – ОК
• Процы – ОК
• Память – ОК
• Сеть?

27. Сеть?
• Сеть – либо работает, либо нет
• Все работает
• Пинги ходят
• Пропускная способность?

28. График загрузки здорового человека
0
10
20
30
40
50
60
70
80
90
100

29. График загрузки курильщика
0
10
20
30
40
50
60
70
80
90
100

30. Сеть перегружена

31. Кто гоняет трафик?
• Tcpdump+wireshark в поисках виновного
• Кто генерит трафик? – мемкэш
• Почему?

32. 1 ключ весит 10мб
• На главной
• Нагруженного проекта
• С 2500 подключенными пользователями
• 2500x10 ~ 2.5Gb/s

33. Не кладите в кэш большие данные

34. Масштабирование

35. Когда масштабироваться?
• Плоский профиль нагрузки
• Вы лежите
• Все оптимизировано
• Нет лишних запросов к ФС и БД
• Админы все потюнили

36. Первые шаги

37. Меня вылогинивает
• Сессии в базу
• Или в кэш

38. Где картинки?
• Riak
• Minio
• nginx-cache

39. Нет состояния – нет проблем

40. Проблема №4
• Деплой завис, а вместе с ним и сайт

41. Легла база
• Нагрузка на диск
• Нагрузка на проц

42. Что говорит show processlist
• Висит альтер
• На большую таблицу
• Которую заблокировал альтер

43. Как не класть базу?
• Закрыть проект и деплоить без нагрузки
• Pt-online-schema-change
• Рекомендации по no downtime alter вашей БД

44. История одного файлообменника
• Храним файлы
• Файлы терять нельзя
• Давай сделаем все на рейдах

47. Что дали опыты
• При множественном запросе разных файлов IO падает
• Не масштабируется. Добавлением второго рейда.
• Какой бы ни был массив, скорость не прибавится

48. И тут мы прилегли
• 10 человек работают с файлами, и скорость 10кбс у
каждого

49. Рейды в топку
• Храним на дисках
• >2 копии одного файла
• >2 дисках
• =хранение денег и места

50. Разница скорости
• 1 диск = 100 iops
• Raid5 (5 hdd) = 100 iops
• 5hdd = 500iops

51. Плюсы
• Своя скорость у каждого диска
• Если один тормозит – тормозит только он
• Сервис более живучий
• Каждый диск увеличивает IO

52. Минусы
• Свои велосипеды для репликации
• Надежность софта, который занимается репликацией

53. Как реплицировать
• Дисками?
• Серверами?
• Серверами и дисками
• При replication factor=2 не страшно терять ни сервер, ни диски
• Прощайте, raid-массивы и их гемор
• Простота в обслуживании стораджей

54. Проблема №5
• Как купить две акции по цене одной

55. Не надо так
def update_balance(self, balance):
self.balance += balance
self.save()

56. И так тоже не надо
def update_balance(self, balance):
Profile.objects.filter(
pk=self.pk
).update(balance=F(‘balance’) + balance)

57. Транзакции – наш выбор
def update_balance(self, balance):
with transaction.atomic():
Profile.objects.filter(
pk=self.pk
).select_for_update()
.update(balance=F(‘balance’) + balance)

58. Talk sql to me
BEGIN;
SELECT … from profile_profile where
id=some_id FOR UPDATE;
UPDATE `profile_profile` set `balance` =
(`balance` + ‘-10’) WHERE `id`=7551;
COMMIT;

59. Read-committed
+Кидает transaction management error
-Бывают дедлоки

60. Repeatable-read
+ Без дедлоков
-? Не кидает transaction management error

61. Выводы
• Забудьте «у меня работает»
• Окружение – важно
• Не делайте ничего без данных на руках
• Не кладите большие данные в кэш
• Используйте внешние хранилища
• Нет состояния - нет проблем

62. Выводы
• Изучите no-downtime альтеры вашей БД
• Используйте транзакции в БД для целостности данных
• Используйте рабочий для вас уровень изоляции данных в
БД

63. Вопросы?
• @gen1us2k
• http://gen1us2k.com
• @maddevsio
• http://maddevs.io
• http://blog.maddevs.io