Масштабирование и производительность - еще раз о главном |
Мы не раз обсуждали вопросы производительности и масштабирования систем (этому и посвящен этот блог). Тем не менее, иногда очень полезно возвращаться к истоку этих понятий. Это важно для понимания их сути, а следовательно и для того, чтобы принимать правильные решения в нужные моменты времени.
Зачастую эти два понятия тесно связаны, но представляют собой два абсолютно разных свойства системы:
|
|
Дельта индекс в Sphinx |
Spinx отлично зарекомендовал себя, как движок полнотекстового поиска. Он обладает отличными показателями производительности и вместе с этим является функционально мощным инструментом. Sphinx прекрасно справляется с большими объемами данных при поиске.
Но есть и другая, более медленная операция, с которой приходится сталкиваться - построение индекса. На малых объемах обычно используют перестройку всего индекса, которая занимает не много времени. В случае же большого количества данных индексирование может стать очень медленным процессом (время полной переиндексации в некторых системах достигает дней и недель). В этом случае результаты поиска будут обладать малой временной актуальностью.
Одним из решений подобной проблемы является использование дельта индекса, о чем мы поговорим в этой статье.
|
|
Оптимизация картинок для Web |
Во многих случаях общий размер картинок, которые грузятся на стринце составляет 50% (и более) от веса всех компонент страницы. Это следует учитывать при клиентской оптимизации, т.к. картинки могут стать бутылочным горлышком Вашей системы. Необходимо обдумывать использование каждого графического элемента на странице. Тем не менее, есть ряд практик и советов, которые позволяют ускорить загрузку изображений.
|
|
Нагрузочное тестирование сайтов с помощью Curl Loader |
Зачастую (скорее всегда) на этапе разработки невозможно предугадать узкие места системы. Это во многом связано с неточностью прогнозируемых нагрузок и их пиков в разрезе конкретных модулей системы. Даже если Вы следуете всем основным принципам разработки высоконагруженных систем, у Вас скорее всего будут проблемы со специфическими подсистемами при росте нагрузок. Заранее определить такие места и приготовить стратегию масштабирования поможет нагрузочное тестирование.
Для нагрузочного тестирования существует ряд инструментов и сегодня мы рассмотрим один из них - простой и мощный Curl Loader.
|
|
Pylot - утилита для нагрузочного тестирования |
Pylot - opensource инструмент для нагрузочного тестирования Web систем. Он имеет большой набор фукнциональных преимуществ, к тому же открытый исходный код позволяет доработать его под конкретные нужды.
Pylot генерирует параллельные запросы к серверу, проверяет ответы от сервера и генерирует отчеты (в том числе и графические) с рядом метрик. Для создания тестов используется язык XML, что позволяет добится большой гибкости учитывая всю простоту описания логики.
|
|
Оптимизация клиентской части с Google Page Speed |
В статье Оптимизация клиентской части был рассмотрен ряд практик по улучшению клиентской производительности Web приложений. На практике весьма сложно контролировать выполнение всех рекомендаций, но этого и не требуется, т.к. существуют специальные инструменты, которые сами проведут нужные тесты, покажут статистику и подберут советы.
Page Speed - инструмент от Google для анализа производительности клиентской части Web приложений. Это бесплатная утилита, которая представляет собой плагин к Firefox/Firebug. Помимо обширной аналитической информации, Google Page Speed предоставляет еще и уместные советы по оптимизации узких мест анализируемых страниц.
Как выглядит и что может дать этот инструмент на практике.
|
|
Масштабируемость и производительность… Первые вопросы |
Создано на wordle
Эта картинка обычно отражает мысли человека, перед которым стоят два факта:
Закапываясь в проблемы производительности и масштабирования, мы зачастую забываем и путаем что и зачем мы делаем. В этой статье мы вернемся к первым вопросам, на которые необходимо отвечать постоянно, что-бы не збиваться с курса.
|
|
Оптимизация производительности Apache |
Apache - популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать - перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов :).
Другой способ - просто увеличить производительность сервера - поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.
|
|
Оптимизация постраничного вывода в MySQL |
SELECT * FROM articles ORDER BY id LIMIT 20000, 20
Что приходит Вам на ум, когда Вы видите такой код? Да, это реализация постраничного вывода на уровне SQL. А еще это выбор результатов для отображения 1000-й страницы.
И Вы сталкиваетесь с тем, что этот запрос работает очень быстро для выборки первых страниц, и невероятно медленно для последних. Почему и как это исправить? Рассмотрим пример для MySQL, хотя описанные принципы применимы для любой СУБД.
|
|
Очередь сообщений на основе PHP и MemcacheQ |
В предыдущей статье мы рассмотрели принцип работы систем очередей сообщений.
В этой статье мы рассотрим пример реализации такого решения на основе PHP и системы MemcacheQ. В качестве приложения выберем распространенную задачу по отправке email сообщений.
|
|
Правила кеширования |
Кеширование - это один из способов оптимизации приложений (улучшение производительности, масштабирование и т.д.). Кешировать можно практически все - результаты выборок из СУБД, данные от внешних сервисов, статические данные (например, картинки), HTML (если страницы не интерактивные)&
В этой статье мы поговорим о кешировании на уровне приложения. Обычно, наиболее узким местом в приложении является СУБД (как правило, она еще и реляционная). Ранее мы писали о масштабировании и оптимизации СУБД. Теперь поговорим о кешировании и о том, когда и как его следует использовать.
|
|
Percona запускает скринкасты |
Компания Percona, занимающаяся консультированием по вопросам производительности и масштабирования объявила о запуске нового проекта - Percona.tv. Этот сайт будет наполняться полезными скринкастами, видео с коференций и просто полезными роликами на темы, касающиеся СУБД и не только.
|
|
Тюнинг FreeBSD 7 под высокие нагрузки |
В этой статье представлена презентация Игоря Сысоева на тему тюнинга ОС FreeBSD 7 под высоконагруженный Web сервер. Он подробно рассказывает о тонкой настройке Web сервера под управлением freebsd. Каждый системный параметр детально описывается и докладчик предлагает рекомендуемые его значения. Must see.
|
|
Как выбрать колонки для индексирования в MySQL |
Как мы выбираем, по каким колонкам в MySQL строить индексы? Иногда не все так очевидно, как кажется. Эффективность того или иного индекса зачастую зависит от распределения данных в таблице. Правильный, на первый взгляд, индекс может работать крайне не эффективно в зависимости от специфики и частоты данных.
Как это можно выяснить? Простой и очень интересный пример взят с блога mysqlPerformanceBlog. Этот способ анализа индексов применим не только к MySQL, а и к другим СУБД.
|
|
Gzip или deflate? |
В одной из предыдущих статей о клиентской оптимизации было упомянуто, что стоит сжимать контент при отдаче его браузеру. Это минимизирует трафик и ускоряет загрузку данных у клиента.
Существуют два стандартных метода сжатия контента Web серверами - Gzip и Deflate. В чем же разница и какой из них выбрать?
|
|
PHP - рецепты и настройка под большие нагрузки |
PHP, на сегодняшний день, это одна из самых популярных платформ для создания Web приложений. Нет смысла в очередной раз упоминать о многочисленных монстрах современного интернет, основой которых служит PHP.
PHP - достаточно производительная платформа (если сравнивать с альтернативными решениями, хотя все очень зависит от реализации), к тому же является масштабируемой (опять же, если реализация не хромает). Вопрос производительности и масштабируемости - это конечно дело приложения и его архитектуры, но тем не менее существуют некоторые советы, позволяющие сделать Ваше приложение более эффективным.
В этой статье мы рассмотрим общие практики и советы при построении нагруженных систем на основе PHP.
|
|
Оптимизация клиентской части |
Что такое скорость загрузки Web страницы? Это время, за которое пользователь получает полностью загруженную страницу.
От чего зависит это время? От того, насколько долго запрос пользователя обрабатывается на сервере. Но не только.
Сегодня типичная Web страница - это несколько десятков картинок, парочка CSS файлов, до десятка JavaScript файлов и HTML размером в 50&100 Кб. И для загрузки каждого из этих компонент браузер посылает на сервер отдельный запрос.
Ясно, что загрузка одной только странички, сгенерированной на серверной части (на Вашем PHP, Python, ASP и т.п.) займет малую часть времени. Большинство времени и ресурсов отнимет загрузка всех остальных компонент страницы.
Клиентская оптимизация призвана уменьшить время полной загрузки страницы.
|
|
PgFouine - профилирование в postgres |
С ситуацией, когда СУБД работает медленно , сталкиваются многие разработчики. И это относится не только к высоконагруженным системам. Как обычно себя ведут разработчики? Начинают оптимизировать запросы, вслепую. В итоге эта работа приносит вовсе не ощутимый результат, либо ускоряются только отдельные части приложения, но проблемы остаются в других местах.
Для того, что-бы провести оптимизацию запросов качественно, необходимо использовать системы профилирования, которые могут явно показать проблемные места. С профилирования и нужно начинать оптимизацию. В этой статье мы рассмотрим пример системы профилирования запросов для СУБД Postgres, которая называется PgFouine.
|
|
Построение отказоустойчивого балансировщика нагрузки на базе Perlbal/Heartbeat |
В этой статье описывается процесс настройки отказоустойчивого двухузлового балансировщика нагрузки с активной/пассивной конфигурацией, поддержкой сессий и механизма Failover на базе Perlbal/Heartbeat под управлением Debian. Балансировщик работает между конечным пользователем и двумя backend-серверами, которые отдают некий контент. (В нашем примере это два сервера с установленным Apache). Балансировщик не только проксирует запросы к бэкэнду, он еще и проверяет состояние бэкэнда и, в случае отказа, перенаправляет запросы к другому серверу (failover). Вдобавок, ведется постоянный мониторинг бэкэнд-серверов при помощи Heartbeat и, если master-сервер “лежит”, то slave автоматически становится мастером. Ваши пользователи не заметят сбоев в работе сервиса.
|
|
Шардинг, партиционирование, репликация - зачем и когда? |
Многие разработчики крупных (что весьма относительно) проектов приходят к выводу о том, что один единственный сервер базы данных никак не сможет справится с нагрузками. Это может быть как на этапе проектирования, так и на этапе роста - не важно. Вопрос в том, какую стратегию выбирать, если Вы уверены, что столкнетесь с такой ситуацией!
Если Ваш заказчик готов купить супер сервер за несколько миллионов долларов (а по мере роста - десятков миллионов и т.д.), что-бы сэкономить время, но сделать все быстро, можете дальше эту статью не читать :). Эта ситуация покажется Вам маловероятной, так и есть. Что выбирать, на основе чего основывать свой выбор и когда выбирать - это вопросы мы рассмотрим в рамках статьи.
|
|
