Кеширование страниц - ускоряем сайт в 100 раз (Varnish + ESI) |
В этой статье поговорим о кешировании страниц и их частей, а также о том, какие плюсы это дает.
Если на Вашем сайте практически нет динамики (например, новостной сайт или блог), то Вы легко можете складывать все его страницы в кеш и практически не делать запросов к бекенду. Но что делать если на сайте есть авторизация, и зависящая от этого логика?
В этой статье речь пойдет о том, как кешировать страницы с персональными данными используя Varnish и язык ESI.
|
|
система хостинга медиа |
После статьи об архитектуре connect.ua многие спрашивали о подсистеме обслуживания медиа файлов, поэтому в этой статье речь пойдет о масштабируемых и производительных системах обслуживания медиа.
Что такое подсистема хостинга медиа вообще? Это часть системы, которая отвечает за загрузку, сохранение, преобразование (транскодирование) и отдачу медиа файлов. Зачастую эта система является наиболее ресурсоемкой ввиду больших объемов данных и процессорных затрат.
|
|
Connect.ua - история роста |
Connect.ua - это первый украинский социальный сервис. За два года проект вырос в достаточно крупный, а следовательно имеет свою собственную историю масштабирования и роста.
Во время роста мы перепробовали большое количество технологий и подходов, которыми я и хочу поделиться в этой статье.
Технологий используется огромное множество, причем динамика использования новых технологий очень высокая. За год на проекте появилось множество улучшений, связанных с новыми техническими решениями.
Далее наш опыт, архитектура, решения, ошибки и выводы:
Как только появляются первые признаки тормозов или отказов на сайте, первым делом устанавливайте систему статистики. Мы поставили Munin и очень довольны. Множество плагинов, практически для любых технических решений. Очень просто писать свои плагины на любом интерпретируемом языке (мы пишем на PHP).
Для мониторинга используем Nagios.
Система статистики не только помагает обнаруживать проблемы, но и прогнозировать расширение.
Мы используем подход горизонтального расширения, а не вертикального. Поэтому мы делаем выбор в сторону недорого оборудования. Что это дает:
Для начала, мы отказались от использования классической схемы репликации запись на мастер + чтение с реплики . При асинхронной репликации время отставания реплики неконтролируемо, что очень усложняет логику приложения. На реплику идут только агрегатные запросы, которые не чувствительны к небольшим задержкам (лучшее видео и т.п.).
В качестве архитектурного решения мы используем федерацию (вертикальное разделение СУБД по таблицам). Часть таблиц работает на одном сервере, часть на другом. Необходимость федерации появилась, когда некоторые особо большие таблицы препятствовали эффективной работе буфера MySQL.
Движки таблиц - InnoDB для всех таблиц, кроме случаев с полностью статическими таблицами (города, страны и т.п.) - для них MyISAM.
Для полнотекстового поиска используем Sphinx. Работает по схеме дельта индексации. Самая тяжелая часть - полная переиндексация, поэтому запускаем ее раз в неделю. Планируем внедрить объединения индексов (index merging).
Наиболее тяжелые функциональные части для СУБД - это личные сообщения и лента новостей. Ленту новостей недавно перевели на MemcacheDB. Стратегию выбрали масштабируемую, у каждого пользователя есть свой личный список событий, который обновляется, когда генерируется новое событие. Это позволит очень легко масштабировать этот функционал.
Кеширование - первое, что мы начали делать для оптимизации приложения. Memcached выбрали по нескольким причинам: простой и эффективный, поддержка распределенного кеширования, встроенный алгоритм консистентного хеширования (необходимо при добавлении новых серверов), поддержка сессий PHP.
Сейчас хитрейт доходит до 95%, показатели вынужденного вытеснения из памяти стремятся к нулю.
Стратегию кеширования используем довольно простую. Для списков кешируем только первичные ключи. Для тяжелых запросов используем дубликаты с разным временем жизни. Ввиду большого количества персональных выборок, пришлось реализовать собственный механизм пространств имен для того, чтобы иметь возможность обновлять несколько объектов одновременно.
Система кеширования носит двухслойных характер: кеш приложения => memcached.
Клиентская оптимизация - это второе, что мы начали делать для оптимизации производительности. Клиентская оптимизация позволила увеличить скорость загрузки страниц в несколько раз. После базовой оптимизации клиентской части, удалось повысить показатель просмотров страниц в полтора раза. Кроме всего прочего клиентская оптимизация позволяет сэкономить канал.
Что мы делали:
Сейчас наиболее медленное место в клиентской части - это система управления банерными показами.
Наиболее ресурсоемкой частью проекта является то, что относится к медиа. Поэтому все медиа ресурсы изолированы от основной части системы. В качестве стратегии роста используем разделение по серверам. Каждый сервер работает независимо от других, что делает всю систему устойчивой к сбоям.
С PHP было меньше всего проблем. Единственным шагом, который привел к ощутимому росту скорости работы, стала установка eAcceleratora. Большинство изменений в коде были связаны с архитектурными изменениями.
Для профилирования используем XhProf - хорошо подходит для работы в продуктивных условиях.
После проделанной работы мы пришли к нескольким простым правилами, которыми пользуемся и сейчас:
Надеюсь будет полезно!
|
|
Google analytics - отслеживание скорости загрузки страниц |
Google analytics имеет расширенные возможности, которые далеко не ограничиваются подсчетом количества просмотров страниц Web сайтов. В GA есть возможность собирать статистику пользовательских событий. На основе этой статистики можно собирать практически любую информацию о пользователях и их действиях.
Рассмотрим, как использовать Google Analytics, чтобы отслеживать скорость загрузки страниц Вашего Web сайта у пользователей.
|
|
Асинхронность с помощью fastcgi_finish_request() |
При оптимизации приложения важно не забывать о том, что оптимизируем мы прежде всего для клиента. Сайт, который работает медленно, это всегда неудобно и плохо.
Главный критерий оптимизации для клиента - это скорость ответа (т.е. время, за которое Web сервер отвечает на запрос). Если не брать во внимание клиентскую оптимизацию, есть ряд практик, позволяющих быстрее генерировать ответ клиенту (по сути без оптимизации внутренностей).
|
|
Twitter.com - архитектура и масштабирование |
В этой статье поговорим об одном из самых шумных и растущих проектов - Twitter.com (далее - Твиттер).
Разработка и развитие этого проекта совпадает с классической схемой удачного стартапа. Стартовал проект с простенького прототипа, написаного на скоркую руку на платформе Ruby-on-Rails. После этого в проекте было сделано огромное количество изменений в архитектурном и техническом плане. Твиттер не раз сталкивался и преодолевал проблемы быстрого роста нагрузки.
Разработчики Твиттера делятся своим опытом.
|
|
Кеширование тяжелых запросов (на примере memcache) |
В этой статье рассмотрим проблемы, которые могут возникать при кеширования тяжелых запросов. Под тяжелыми запросами следует понимать не только медленные, но и ресурсоемкие запросы (например, обращение к внешним XML источникам с последующей обработкой). Наиболее стандартные ситуации - это тяжелые SQL выборки на страницах с агрегационной информацией (популярные видео ролики, лучше фотки, самые активные пользователи и т.п.). На первый взгляд все просто - кешируем на час..два и забываем о этих запросах на долгое время. Какие проблемы могут возникнуть в ходе увеличения нагрузок?
|
|
Sphinxsearch - объединение индексов (index merging) |
В сфинксе (sphinx-search) существует очень хорошее решение для оптимизации процесса индексации.
Суть решения рассмотрена в статье Дельта индекс в Sphinx . Дельта индексы существенно снижают ресурсоемкость постоянной переиндексации, позволяя делать ее чаще и иметь более актуальные данные в результатах поиска.
Использование дельта индексов тем не менее требует периодичного обновления основного индекса, чтобы обновить изменившиеся и выбросить удаленные сущности. Да и сам по себе дельта индекс растет со временем, требуя все больше ресурсов для переиндексации (что делает его неэффективным).
Самое простое решение этой задачи - полная переиндексация в непиковые часы (или дни). Это не самый оптимальный подход, т.к. полная переиндексация может занимать часы, а иногда и дни. Существует другое решение для обновления основного индекса, которое может сэкономить множество ресурсов - объединение индексов (index merging).
|
|
check-unused-keys - проверка неиспользуемых индексов в MySQL |
check-unused-keys - это PERL утилита, которая выводит статистику о неиспользуемых индексах (и таблиц) в MySQL. Утилита собирает информацию, основываясь на патче user_stats (от Google + Percona). Патч пользовательской статистики добавляет несколько таблиц в БД INFORMATION_SCHEMA, в том числе таблицу INDEX_STATISTICS. Она содержит данные по использованию того или иного индекса.
|
|
Масштабирование Web - опыт Ebay |
Ebay - один из самых больших интернет проектов сегодня во всех смыслах, в том числе и по техническим показателям. Рэнди Шуп, архитектор проекта, делится опытом в вопросах масштабирования. Он подготовил отличную презентацию, в которой касается не только практических вопросов, но и общих принципов того, как нужно думать при построении крупных масштабируемых систем .
|
|
Memcached - настройка под малые объекты |
Чаще всего Memcache используется для хранения малых объектов (в больших количествах). По умолчанию, memcache не оптимально настроен именно на такое его использование. Поэтому, поговорим о том, как можно его подстроить для получения большей эффективности работы.
|
|
PgQ - система очередей |
PgQ - это система очередей, разработанная на базе PostgreSQL. Разработчики - компания Skype, известная своим вкладом в развитие технологий на базе PostgreSQL.
|
|
XHprof - профилирование PHP от Facebook |
PHP был и остается одной из самых популярных платформ для разработки Web приложений любого уровня сложности и размера. О преимуществах этой технологии мы поговорим отдельно, а сегодня исследуем вопрос профилирования PHP.
Не забывая о главных правилах масштабируемых приложений следует еще раз подчеркнуть важность инструментов по сбору статистики различных технологичных аспектов Вашей системы.
Рассмотрим решение от создателей Facebook - XHProf.
|
|
XtraBackup - резервное копирование для innoDB |
В системах с высокими нагрузками особое внимание следует уделять резервному копированию (бекапам) данных. Зачастую самая важная часть данных находиться в СУБД. Проблема заключается в том, что копирование данных нужно проводить незаметным для работающей системы образом. Блокировка данных на момент создания бекапа тут не работает, т.к. время блокирования будет неприемлемым.
Одним из популярных решений является репликация, которая обеспечивает высокую степень надежности и почти нулевую потерю данных при сбое основного сервера. Но репликация требует аппаратных затрат, к тому же резервный сервер должен не уступать по характеристикам основному серверу, иначе от репликации не будет толку.
Другой подход резервного копирования - это использование специальных утилит, которые позволяют делать снимки состояния СУБД на жесткий диск, и восстанавливать состояние обратно по такому снимку. На этом остановимся подробнее.
Поскольку MySQL является одним из самых популярных решений в Webе сегодня, рассмотрим инструменты для бекапов для этой СУБД.
XtraBackup - это утилита от Percona Labs, предназначенная для горячих бекапов таблиц InnoDB и XtraDB.
|
|
PHP + Redis платформа “Ключ=Значение” |
Что такое и зачем нужны базы данных Ключ=Значение мы рассматривали ранее. Преимущества перед РСУБД в своем классе задач очевидные. Технических решений сегодня множество, и сегодня мы поговорим об одном из них - Redis.
Отличительной особенностью этого продукта в том, что он поддерживает атомарные операции работы со списками и наборами объектов. Сегодня опробуем это решение на практике.
|
|
Настройка nginx для отдачи файлов |
Системы хранения и отдачи файлов - это отдельная часть в практике построения масштабируемых систем. Сегодня рассмотрим вопросы отдачи медиа (и не только) файлов с помощью Web сервера Nginx. У Вас уже есть система хранения файлов, установлен сервер отдачи.
На что следует обратить внимание для оптимальной настройки Nginx?
|
|
Maatkit - расширенные возможности MySQL |
Maatkit - это набор инструментов, который предоставляет собой расширенные средства по управлению MySQL, сбору аналитической информации и ее обработке, проведению рутинных операций, восстановлению данных и прочего. В пакет входит множество полезных инструментов, которых к сожалению нет в стандартной поставке с БД, но обязательно нужны для максимально эффективной работы. Этот пакет разработан и поддерживается компанией Percona - известных экспертов в области консультирования вопросов производительности.
Пакет Maatkit входит во все распространенные дистрибутивы Linux систем, поэтому не придется терять время на установке. Хотя, если Вы хотите получить наиболее последнюю версию, следует качать версию с сайта (обновления выходят очень часто).
После установки Вам станет доступно почти 20 различных инструментов, входящих в поставку. Некоторые из них мы и рассмотрим.
|
|
Siege — утилита для нагрузочного тестирования веб-серверов |
Siege – это утилита для нагрузочного тестирования веб-серверов.
Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже.
Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.
|
|
Memcached Multi-Get, зачем? |
Memcached сегодня является самым популярным решением кеширования данных в мире (в Web приложениях). Масштабирование и оптимизация - в двух этих задачах зачастую фигурирует memcached. В этой статье мы не будем в очередной раз хвалить этот продукт, а рассмотрим его дополнительные возможности (точнее всего одну).
Мы рассмотрим очень полезную функциональную особенность про которую многие забывают (а некоторые даже и не знают). Это операция множественного чтения или multi-get. В чем ее суть и действительно ли ее использование оправдано?
|
|
Curl Loader |
Curl Loader - это бесплатный инструмент, который позволяет симулировать нагрузку на приложение по протоколам HTTP(s) и FTP(s). Эта утилита позволяет проводить нагрузочное тестирование сайтов с десятками и сотнями тысяч виртуальных клиентов.
|
|
