После статьи об архитектуре connect.ua многие спрашивали о подсистеме обслуживания медиа файлов, поэтому в этой статье речь пойдет о масштабируемых и производительных системах обслуживания медиа.

Что такое подсистема хостинга медиа вообще? Это часть системы, которая отвечает за загрузку, сохранение, преобразование (транскодирование) и отдачу медиа файлов. Зачастую эта система является наиболее ресурсоемкой ввиду больших объемов данных и процессорных затрат.

Читать о том, как построить масштабируемую систему хостинга медиа.

Connect.ua — це перший український соціальний сервіс. За два роки проект виріс у досить великий, а отже має свою власну історію масштабування і зростання.

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

Connect.ua — история роста

Google analytics має розширені можливості, які не обмежуються підрахунком кількості переглядів сторінок Web сайту. У GA є можливість збирати статистику кастомних подій. На основі цієї статистики можна збирати практично будь-яку інформацію про користувачів і їх дії.

Розглянемо, як використовувати Google Analytics, щоб відслідковувати швидкість завантаження сторінок Вашого Web сайту у користувачів.

Google analytics — відстеження швидкості завантаження сторінок (рос.)

Twitter.com — архітектура і масштабування

У цій статті поговоримо про один із найбільш гучних і зростаючих проектів — Twitter.com (далі — Твіттер).

Розробка і розвиток цього проекту збігається із класичною схемою вдалого стартапу. Стартував проект з простенького прототипу, написаного нашвидкоруч на платформі Ruby-on-Rails. Після цього в проекті була зроблено величезна кількість змін в архітектурному і технічному плані. Твіттер не раз стикався і долав проблеми швидкого зростання навантаження.

Розробники Твіттер діляться своїм досвідом.

Читати про архітектуру і масштабування Твіттера (рос.)

У цій статті розглянемо проблеми, які можуть виникати при кешуванні важких запитів. Під важкими запитами слід розуміти не тільки повільні, але і ресурсомісткі запити (наприклад, звернення до зовнішніх XML джерел з наступною обробкою). Найбільш стандартні ситуації — це важкі SQL вибірки на сторінках з агрегационною інформацією (популярні відео клiпи, кращі фотки, найактивніші користувачі тощо). На перший погляд все просто — кешуємо на годину… дві і забуваємо про ці запити на довгий час. Які проблеми можуть виникнути в ході збільшення навантажень?

Читати про кешування важких запитів далі (рос.)

В сфінкса (sphinx-search) існує дуже хороше рішення для оптимізації процесу індексації.

Суть рішення розглянута в статті "Дельта індекс у Sphinx". Дельта індекси істотно знижують ресурсомісткість постійної переіндексації, дозволяючи робити її частіше і мати більш актуальні дані в результатах пошуку.

Використання дельта індексів проте вимагає періодичного оновлення основного індексу, щоб оновити змінені та викинути видалені документи. Та й сам по собі дельта індекс зростає з часом, вимагаючи все більше ресурсів для переіндексації (що робить його неефективним).

Найпростіше рішення — повна переіндексація в непікові години (або дні). Не найоптимальніший підхід, бо повна переіндексація може займати години, а іноді і дні. Існує інше рішення для оновлення основного індексу, що може заощадити безліч ресурсів — об'єднання індексів (index merging).

Використання index merging (рос.).

Для начала, некоторые поразительные показатели проекта Ebay.com:

— Более 89 миллионов активных пользователей
— 190 миллионов товаров в 50 тыс. категорий
— Более 8 миллиардов URL запросов в день
— Большая динамика развития — сотни новых функциональных улучшений каждые 3 месяца
— 39 стран, 9 языков, 24 часа в сутки, 7 дней в неделю, круглый год
— 70 миллиардов операций чтения/записи в день
— Обработка 50 Тб данных в день
— Анализ 50 Пб данных каждый день

Дальше — 10 основных правил масштабирования от Ebay + презентация

Если Вам приходилось сталкиваться с проблемой медленной работы сайта, эта статья для Вас.

Причину малой скорости сайта мы обычно ищем в PHP и MySQL, но зачастую забываем о том, что из себя представляет страница, которая попадает в браузер пользователя. Помимо HTML есть еще и Javascript, CSS, множество картинок, флеш объекты и т.п.

Время загрузки страницы чаще всего занимает лишь несколько процентов от времени загрузки всех ее компонент. Существует ряд подходов, которые помогут оптимизировать загрузку страницы в разы.

Несколько подробных статей на эту тему:
* Оптимизация клиентской части
* Как ускорить работу сайта для посетителя
* Скорость имеет значение

Стоит добавить еще несколько вещей

1. Стоит помещать Javascript файлы в конец HTML и использовать только внешние методы для регистрации событий (не использовать атрибутов, типа «onclick» и т.п.). Это поможет избежать ошибок в тех случаях, когда Javascript еще не загружен, а пользователь уже пытается выполнить какое-то действие

2. Стоит заранее сжимать статику gzip-ом, а в отдающем сервере просто отдавать необходимые заголовки. В этом может помочь этот модуль nginx'a

3. Изолируйте отдачу на разные сервера (например, динамику и статику отдавайте с разных серверов) — поможет изолировать проблемы с нагрузками