Введение

В своей предыдущей статье я дал краткий обзор основных моделей хранения иерархических структур в реляционных БД. Как и положено тому быть, у многих читателей стал вопрос ребром о производительности представленных алгоритмов.

В данной статье я постараюсь приоткрыть завесу над этим животрепещущим вопросом, а в следующей обещаю коснуться вопросов оптимизации и поисков нестандартных решений.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2 и 3.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached.

Сегодня мы рассмотрим проблему одновременного перестроения кэша, которая возникает при большом количестве одновременных обращений к кэшу, который был только что сброшен или потерян, что может привести к перегрузке БД.

Следующий пост будет посвящен тэгированию кэшей.

Бытует мнение, что связка LAMP (Linux+Apache+Mysql+PHP) не требует особой настройки и работает «из коробки». Это далеко не так. После того, как я долго убеждал товарища установить кеширующий акселератор PHP xcache, я решил провести небольшой эксперимент и попробовать выключить xcache на своём виртуальном сервере, находящемся под небольшой нагрузкой (около хита в секунду). В реальной жизни нагрузка на процессор мала, а вот память загружена сильно, т.к. её немного (256МБайт).

Результаты эксперимента превзошли все ожидания.

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

Приехав домой очень захотелось это всё попробовать в живую. О чём я сейчас и расскажу. Сразу оговорюсь — структура базы данных для теста, взята из примера на сайте самих разработчиков и естественно не имеет ничего общего с реальной загрузкой.
В статье будет описано что распределением нагрузки надо заниматься после того как уже припекло и база падает, но это не совсем так. С помощью данной статьи я как раз хочу подготовить начинающих и не опытных разработчиков и заодно заставить их задуматься о том, что предусматривать возможность распределения нагрузки между серверами надо ещё при проектировании системы. И это не будет считаться той самой «преждевременной оптимизацией» о которой так много пишут и которой так боятся.

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

Или об особенностях управления отдаваемым контентом в PHP.

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

Начну с того, что если бы мне такое сказали вчера, то я покрутил бы сам у этого человека пальцем у виска, однако серия проведенных тестов неумолимо свидетельствует об этом.

Примечание: ниже расположен перевод заметки Image Optimization, Part 3: Four Steps to File Size Reduction от Stoyan Stefanov. В ней рассматриваются наиболее популярные консольные утилиты для минимизации изображений. Мои комментарии далее курсивом.
Об авторе: Stoyan Stefanov работает веб-разработчиком в команде Yahoo! по исключительной производительности и руководит разработкой инструмента для анализа производительности — YSlow. Он также внес значительный вклад в программы, разрабатываемые с открытым исходным кодом, выступает на конференциях и является техническим писателем: его последняя книга озаглавлена Объектно-ориентированный JavaScript.

Эта третья часть серии статей, посвященных оптимизации изображений (в первых двух была сплошная вода, но на досуге почитать интересно). С предыдущими частями можно ознакомиться по ссылкам:

• Оптимизация изображений, часть 1: важность картинок
• Оптимизация изображений, часть 2: выбираем нужный формат файлов

Текущая заметка посвящена некоторым наиболее часто используемым инструментам, которые можно применить для уменьшения размера изображений. Идея заключается в следующем: мы можем получать все изображения от дизайнера, но не оставлять их в исходном виде, а немного уменьшать в размере, используя указанные ниже инструменты. Это позволит автоматизировать процесс без необходимости глубокого анализа структуры изображения.
Читать дальше на webo.in →

Параллельно к основной работе, я в «фоне» обдумываю и прикидываю реализации архитектуры для игровых проектов (напомню, что основная область моих интересов и работ — создание онлайновых браузерных игр). Последнее время я все чаще и чаще возвращаюсь к мысли, что интересно было бы реализовать основной игровой сервер на основе очередей сообщений (MQ или Messages queue). То есть, движок такой игры будет представлять собой набор компонентов, которые будут общаться между собой посредством асинхронных сообщений, а каждый компонент может быть как генератором сообщений, так и подписчиком, то есть исполнять другие сообщения.

Такой подход, насколько я понимаю, широко применяется в мире Java, там для этого есть стандарт Java Message Service (JMS) и применяются брокеры сообщений и на этом базируется архитектура Enterprise service bus (ESB), например, Apache ServiceMix. Но для нас это пока высокая сфера крупных проектов, а в специфике веба и веб-ориентированных приложений я бы хотел рассмотреть, можно ли что-то сделать подобное, но с меньшими затратами и обеспечить приложению отказоустойчивость, распределение нагрузки и асинхронную обработку. И конечно, очень желательно, чтобы это было реализовано на РНР как основном языке реализации всех компонентов сервера.

Решил продолжить цикл заметок по данной тематике. В данной статье особое место хотел уделить профайлингу MySQL запросов. Описать средства, которые предоставляются MySQL для профайлинга, и что нужно делать для определения узких мест запроса.

Также, после опубликования первых двух статей я получил пару отзывов и вопросов, связанных с проектированием БД / расстановкой индексов / составлением запросов. На многие вопросы старался отвечать. С некоторыми из них поделюсь и в этой статье.

Пообещал вчера написать статью о реальных случаях оптимизации БД MySQL.
Пришлось сегодня вставать утром пораньше чтобы воплотить обещанное в жизнь.
Централизованное управление мыслями поддерживать еще сложно, поэтому не судите строго за казусы и ляпсусы в моей статье.

В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.

В данной статье опишу несколько приемов, которые были использованы для приложения с 4млн+ пользователей и которое имея порядка 100млн+ хитов в сутки, а в конце опишу задачу, которая решалась недавно и может быть многоуважаемое сообщество предложит мне решения этой задачи более эффективное нежели то, к которому пришел я.

Поводом для написания данной статьи послужили некоторые дебаты в одной из групп linkedin, связанной с MySQL, а также общение с коллегами и хабролюдьми :-)

В данной статье хотел написать что такое вообще JOINы в MySQL и как можно оптимизировать запросы с ними.

Итак… Приступим.
В последнее время я встретил сразу 2 реализации многопоточности на Хабре. Немного подумав я решил написать и свой вариант.
Но так как у меня нет возможности использовать PCNTL библиотеку, то мне пришлось извратиться…

Задача: реализация многопоточности на PHP (threads)

Издержки: нет модуля PCNTL ( build w/o PCNTL )

Решение: чистый PHP + Unix ( pure PHP + Unix )

Суть многопоточности (для приложения) состоит в том, что процесс может состоять из нескольких (однотипных) потоков, выполняющихся «параллельно», то есть без упорядочивания по времени — выполнился один, пошел следующий. Использование многопоточности позволяет ускорить выполнение задачи и/или снизить нагрузку, таким образом, улучшая быстродействие самого приложения.

PHP относится к языкам, в которых поддержка многопоточности отсутствует. Но, есть немало задач, в которых она была бы очень полезна. Как правило, это задачи, в которых одно действие нужно выполнить много раз, но с различными параметрами, причем само действие настолько ресурсоемко, а количество итераций настолько велико, что обычный цикл использовать невозможно.

Я рассмотрю простой пример, как можно достичь эмуляции многопоточности в PHP.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).