Создано на wordle
Эта картинка обычно отражает мысли человека, перед которым стоят два факта:
Закапываясь в проблемы производительности и масштабирования, мы зачастую забываем и путаем что и зачем мы делаем. В этой статье мы вернемся к первым вопросам, на которые необходимо отвечать постоянно, что-бы не збиваться с курса.
Apache - популярный веб-сервер в интернет, он обслуживает множество серверов и сайтов. Часто возникает необходимость увеличить производительность веб-сервера. Наверное лучший способ это сделать - перейти к схеме frontend+backend, но это может потребовать достаточно серьезных изменений в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов :).
Другой способ - просто увеличить производительность сервера - поставить более быстрый процессор и больше памяти.
Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить apache путем оптимизации его конфигурации. Существуют оптимизации, которые можно применить только при пересборке apache, другие же можно применять без перекомпиляции сервера.
SELECT * FROM articles ORDER BY id LIMIT 20000, 20
Что приходит Вам на ум, когда Вы видите такой код? Да, это реализация постраничного вывода на уровне SQL. А еще это выбор результатов для отображения 1000-й страницы.
И Вы сталкиваетесь с тем, что этот запрос работает очень быстро для выборки первых страниц, и невероятно медленно для последних. Почему и как это исправить? Рассмотрим пример для MySQL, хотя описанные принципы применимы для любой СУБД.
В предыдущей статье мы рассмотрели принцип работы систем очередей сообщений.
В этой статье мы рассотрим пример реализации такого решения на основе PHP и системы MemcacheQ. В качестве приложения выберем распространенную задачу по отправке email сообщений.
Организация очереди сообщений помогает разбалансировать нагрузку между различными узлами сети, избавиться от единой точки отказа (SPOF), выполнять бизнес-логику приложения асинхронно, повысить скорость ответа системы и многое другое.
Что же такое очередь сообщений? Как именно она позволяет решать все перечисленные задачи? Как организовать очередь сообщений? Какие достоинства, недостатки и сложности такого решения? О всем этом далее:
Все мы слышали о Facebook.com и все можем только представляеть себе те объемы данных, с которыми вынуждены работать бекенды этой системы.
При их объемах они упираются в ограничения стандартных решений - будь то цена либо производительность. Как же они решают задачу управления данными и их хранения?
С ситуацией, когда СУБД “работает медленно”, сталкиваются многие разработчики. И это относится не только к высоконагруженным системам. Как обычно себя ведут разработчики? Начинают оптимизировать запросы, вслепую. В итоге эта работа приносит вовсе не ощутимый результат, либо ускоряются только отдельные части приложения, но проблемы остаются в других местах.
Для того, что-бы провести оптимизацию запросов качественно, необходимо использовать системы профилирования, которые могут явно показать проблемные места. С профилирования и нужно начинать оптимизацию. В этой статье мы рассмотрим пример системы профилирования запросов для СУБД Postgres, которая называется PgFouine.
Зачастую на мультимедийных сайтах существует задача выдавать картинки (часто пользовательское фото) в различных размерах (thumbnails). Причем, в большинстве случаев приходится поддерживать несколько размерных версий картинок (например, пользовательское фото vkontakte.ru имеет 3 различные размерные версии).
Один из примеров построения системы отдачи изображений описан в статье “Отдача и ресайзинг фотографий“. Тем не менее, существует несколько альтернативных вариантов. Подробнее об одном из них в этой статье.
Многие разработчики крупных (что весьма относительно) проектов приходят к выводу о том, что один единственный сервер базы данных никак не сможет справится с нагрузками. Это может быть как на этапе проектирования, так и на этапе роста - не важно. Вопрос в том, какую стратегию выбирать, если Вы уверены, что столкнетесь с такой ситуацией!
Если Ваш заказчик готов купить супер сервер за несколько миллионов долларов (а по мере роста - десятков миллионов и т.д.), что-бы сэкономить время, но сделать все быстро, можете дальше эту статью не читать :). Эта ситуация покажется Вам маловероятной, так и есть. Что выбирать, на основе чего основывать свой выбор и когда выбирать - это вопросы мы рассмотрим в рамках статьи.
Базы данных, как Вы возможно заметили, не ограничиваются на MySQL. Есть и другие! Кто-то выбирает для своих продуктов Postgres, и я этот выбор, в большинстве случаев, поддерживаю и считаю разумным. Для высоконагруженных систем Postgres имеет ряд преимуществ перед конкурентами, но об этом в другой раз.
И так, Вы поставили postgres, у Вас есть приложение (возможно в планах) с определенными требованиями к количеству/размеру таблиц, отношению записи/чтения и т.д. Стандартные настройки, как всегда подходят только для стандартных проектов, а стандартных проектов нет. Поэтому сервер придется настраивать под Ваши требования для обеспечения его оптимальной работы.
Этот блог посвящен вопросам производительности и масштабирования Web систем. Тут мы делимся собственным опытом и соображениями, пишем о технологиях и их применении. Все, кому есть, что добавить - регистрируйтесь и присоединяйтесь!
Комментарии