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 (рос.).