Документ описывает высоконагруженную систему управления контентом сайта 'Комсомольская правда', включая детали об архитектуре, использовании MySQL и Memcached, а также о проблемах с производительностью и попытках оптимизации. Указаны статистические данные о трафике и взаимодействии пользователей, а также структура внутренних отделов и их взаимодействие. Также рассматриваются проблемы, связанные с ростом объемов контента, и предложенные решения для повышения эффективности системы.

1. “ Комсомольская правда” в интернете: совмещение высокой нагрузки, высокой доступности и оперативной разработки Ромашин А., Малютин В. Октябрь, 2011 г.

2. Немного статистики 8000 обновлений контента 6000 комментариев в среднем 40 одновременно работающих пользователей 3 000 000 и 900 000 в обычные дни 4 500 000 и 1 200 000 при появлении важных событий 54 региональные версии сайта

3. Особенности движка отсутствие FK, представлений, хранимых процедур N:M-связи через спец. таблицу регионализация на низком уровне простые SQL запросы = эффективность кеша MySQL минимум описания полей для CMS

4. Редакторский интерфейс ~ 100 объектов Доступ на уровне объектов Кастомизация статусов

5. Редакторский интерфейс Кастомизация фильтра, столбцов Изменение приоритета Групповые операции

6. Редакторский интерфейс CKEditor с расширениями copy/paste, коррекции ввода Динамическая подгрузка Загрузка мультимедиа Активные пользователи История изменений

7. Конфигурация Объектная часть + описание сброса кеша Интерфейсная часть Это один файл (не считая структуры БД и пары мелких сервисных конфигов ) Автоматическое обновление структуры БД

8. Иерархия классов Enum и Set — перечисляемые типы Загрузка по обращению (Ref) Маскирование полей ( Parent, Image ) Системное поле History

9. Элементы интерфейса Цепочка типов Ref->FParent (N:M) Семейство списков Popup и расширения Text и расширения с корректировкой данных Grid — элемент ввода табличных данных

10. С чего все начиналось

11. Проблемы Рост объемов контента Добавление новых страниц, проектов — рост числа запросов Блокировки таблиц MyISAM Весь CGI на фронтенде

12. переписана главная страница ( ~ 50% заходов на тот момент ) настроена репликация

13. Данные объекта в memcached

14. Неэффективно. MySQL query cache!

15. Переход на RedHat Убран memcached Добавлен балансировщик и второй slave

16. MySQL проблемы с индексами MyISAM: 600К записей — обрушение индексных файлов. обвалы репликации перевод мастера на InnoDB разный max_heap_table_size на мастере и слейвах попытка перехода на MySQL Cluster

17. Балансировка нагрузки фронтов DNS прописан на виртуальный сетевой интерфейс Фронты «следят» за доступностью основного IP-адреса Filesync — дублирование статики по фронтам

18. Добавлен второй фронт Добавлен третий бекенд Переход на InnoDB

19. Блочный кеш memcached:2x(Core2 1.86ГГц,8Гб) repcached 2048 макс, 100 будни, 700 пик соединений Cache::Memcached::Fast в основе — cache_self Mason одно соединение на request

20. Блочный кеш. Алгоритм cache_self_ex()

21. Блочный кеш. «Магия» call_self()

22. Блочный кеш. Mason создает соединение на каждый вызов оригинального cache_self()!

23. Кеш nginx некешируемые зоны не используйте memcached с nginx увеличение времени кеширования при высоких нагрузках

24. Переход на fast cgi легкость, скорость, отсутствие кучи модулей рост памяти процесса управляемость

25. Если нет вопросов...

26. Структура отдела Аналитики. Взаимодействие с внутренними заказчиками и аналитиками подрчдчиков, постановка ТЗ, приемка, контроль исполнения работ.

27. Структура отдела Внешние подрядчики. Крупные долгосрочные проекты, которые имеют слабую интеграцию с платформой.

28. Структура отдела Разработчики. Развитие платформы и ключевых модулей, срочные задачи. Разработчики-стажеры. Выполнение срочных задач, обучение в долгосрочных проектах.

29. Структура отдела Администрирование. Сторонняя организация. Система тикетов. Оповещения о проводимых работах. Регламент обновления ПО Zabbix, рассылка slow logs | Maatkit

30. Проблемы Выход из строя оборудования Скачок посещаемости, DDoS Вирусы Проблемы на канале интернет-провайдера Рост количества проектов и их сложности

31. Решения Дублирование узлов, балансировка Увеличение времени кеша на фронте Регулярная смена паролей пользователей BGP Подпроекты, аналитики, подрядчики

32. Перспективы Создание региональных площадок, CDN Перенос подсистем на отдельные сервера Повышение качества кода, организация нагрузочного тестирования, приемка Архитектура диспетчер — шина данных !new

33. Спасибо за внимание! Вопросы?