Нет двух одинаковых сайтов. Вам действительно нужно получить такой инструмент, как jmeter и benchmark, чтобы увидеть, где будут ваши проблемные точки. Вы можете потратить много времени на угадывание и улучшение, но вы не увидите реальных результатов, пока не измерите и не сравните свои изменения.

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

И не забывайте,что вы никогда не закончите масштабирование. Сайт, который обрабатывает 10req/s, будет нуждаться в изменениях для поддержки 1000req/s., и если вам достаточно повезло, чтобы поддерживать 10,000req/s,, ваша архитектура, вероятно, также будет выглядеть совершенно иначе.

База данных

• Не используйте MySQLi -- PDO -это уровень доступа к базе данных 'modern' OO. Самая важная функция для использования-это заполнители в запросах. Он достаточно умен, чтобы использовать серверные настройки и другие оптимизации для вас.
• Вы, вероятно, не хотите разбивать свою базу данных на этом этапе. Если вы обнаружите, что одна база данных не сокращается, есть несколько способов масштабирования, в зависимости от вашего приложения. Репликация на дополнительные серверы обычно хорошо работает, если у вас больше операций чтения, чем записи. Сегментация-это метод разделения данных на множество машин.

Кэширование

• Вы, вероятно, не хотите кэшировать в своей базе данных. База данных, как правило, является вашим узким местом, поэтому добавление в нее дополнительных IO-х обычно плохо. Есть несколько тайников PHP, которые выполняют аналогичные вещи, такие как APC и Zend.
• Измерьте свою систему с включенным и выключенным кэшированием. Держу пари, что ваш кэш тяжелее, чем прямая подача страниц.
• Если создание комментариев и данных статей из БД занимает много времени, интегрируйте memcache в свою систему. Вы можете кэшировать результаты запроса и хранить их в экземпляре memcached. Важно помнить, что извлечение данных из memcache должно быть быстрее, чем сборка их из базы данных, чтобы увидеть какую-либо выгоду.
• Если ваши статьи не являются динамическими или у вас есть простые динамические изменения после их создания, рассмотрите возможность записи html или php на диск. У вас может быть страница index.php, которая ищет статью на диске, если она есть, она передает ее клиенту. Если это не так, он генерирует статью, записывает ее на диск и отправляет клиенту. Удаление файлов с диска приведет к перезаписи страниц. Если к статье добавляется комментарий, удалите кэшированную копию - она будет восстановлена.

Я ведущий разработчик на сайте с более чем 15 млн пользователей. У нас было очень мало проблем с масштабированием, потому что мы планировали для него EARLY и масштабировали вдумчиво. Вот некоторые из стратегий, которые я могу предложить из своего опыта.

Схемы во-первых, денормализация схемы. Это означает, что вместо того, чтобы иметь несколько реляционных таблиц, вы должны вместо этого выбрать одну большую таблицу. В общем, объединения-это пустая трата драгоценных ресурсов DB, потому что выполнение нескольких операций подготовки и сортировки сжигает диск I/O's., избегая их, когда это возможно.

Компромисс здесь заключается в том, что вы будете хранить/извлекать избыточные данные, но это приемлемо, потому что данные и пропускная способность внутри клетки очень дешевы (большие диски), в то время как многократная подготовка I/O's на порядок дороже (больше серверов).

Индексирование убедитесь, что ваши запросы используют хотя бы один индекс. Однако будьте осторожны, что индексы будут стоить вам, если вы часто пишете или обновляете. Есть несколько экспериментальных трюков, чтобы избежать этого.

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

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

Кэширование я очень рекомендую Memcached. Это было доказано крупнейшими игроками на стеке PHP (Facebook) и очень гибко. Для этого есть два метода: один-кэширование в слое DB, другой-кэширование в слое бизнес-логики.

Опция слоя DB потребует кэширования результатов запросов, полученных из слоя DB. Вы можете hash свой запрос SQL с помощью md5() и использовать его в качестве ключа поиска перед переходом в базу данных. Плюс к этому заключается в том, что его довольно легко реализовать. Недостатком (в зависимости от реализации) является то, что вы теряете гибкость, потому что вы рассматриваете все кэширование одинаково в отношении срока действия кэша.

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

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

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

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

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

Я работал на нескольких сайтах, где millions/hits/month поддерживается PHP & MySQL. Вот некоторые основы:

1. Кеш, кеш, кеш. Кэширование-это один из самых простых и эффективных способов уменьшить нагрузку на webserver и базу данных. Содержимое страницы кэша, запросы, дорогостоящие вычисления, все, что связано с вводом-выводом. Memcache очень прост и эффективен.
2. Используйте несколько серверов, как только вы исчерпали свои возможности. Вы можете иметь несколько веб-серверов и несколько серверов баз данных (с репликацией).
3. Уменьшите общее число запросов к вашим веб-серверам. Это влечет за собой кэширование JS, CSS и изображений с использованием заголовков expires. Вы также можете переместить статическое содержимое в CDN, что ускорит работу вашего пользователя.
4. Измерить & эталоном. Запустить Nagios на производство машин и проверить нагрузку на разработчиков/тестировщиков сервер. Вам нужно знать, когда ваш сервер загорится, чтобы вы могли предотвратить это.

Я бы рекомендовал читать создание масштабируемых веб-сайтов, он был написан одним из инженеров Flickr и является отличным справочником.

Проверьте мой пост в блоге о масштабируемости тоже, в нем есть много ссылок на презентации о масштабировании с несколькими языками и платформами: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

Ре: PDO / MySQLi / MySQLND

@ Гэри

Вы не можете просто сказать "don't use MySQLi", так как у них разные цели. PDO-это почти как слой абстракции (хотя на самом деле это не так) и предназначен для упрощения использования нескольких продуктов баз данных, в то время как MySQLi является специфичным для MySQL соединений. Неправильно говорить, что PDO-это современный уровень доступа в контексте сравнения его с MySQLi, потому что ваше утверждение подразумевает, что прогрессия была mysql - > mysqli - > PDO, что не так.

Выбор между MySQLi и PDO прост - если вам нужно поддерживать несколько продуктов баз данных, то вы используете PDO. Если вы просто используете MySQL, то вы можете выбрать между PDO и MySQLi.

Так почему же вы выбрали MySQLi вместо PDO? Увидеть ниже...

@ross

Вы правы насчет MySQLnd, который является новейшей библиотекой уровня основного языка MySQL, однако он не является заменой для MySQLi. MySQLi (как и с PDO) остается тем же способом, которым вы взаимодействовали бы с MySQL через ваш код PHP. Оба они используют libmysql в качестве клиента C за кодом PHP. Проблема заключается в том, что libmysql находится вне ядра PHP engine, и именно там включается mysqlnd, т. е. это родной драйвер, который использует внутренние компоненты ядра PHP для максимизации эффективности, особенно когда речь идет об использовании памяти.

MySQLnd разрабатывается самими MySQL и недавно приземлился на ветку PHP 5.3, которая находится в тестировании RC, готовом к выпуску позже в этом году. Тогда вы сможете использовать MySQLnd с MySQLi...but, а не с PDO. Это даст MySQLi производительность boost во многих областях (не во всех) и сделает его лучшим выбором для взаимодействия с MySQL, если вам не нужны абстракции, подобные возможностям PDO.

Тем не менее, MySQLnd теперь доступен в PHP 5.3 для PDO, и поэтому вы можете получить преимущества улучшений производительности от ND до PDO, однако PDO по-прежнему является общим уровнем базы данных и поэтому вряд ли сможет извлечь такую же выгоду из улучшений в ND, как и MySQLi .

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

Есть много соображений, которые необходимо учитывать при выборе между MySQLi и PDO. Это действительно не будет иметь значения, пока вы не доберетесь до редикуально высоких номеров запросов, и в этом случае имеет больше смысла использовать расширение, которое было специально разработано для MySQL, а не тот, который абстрагирует вещи и случайно предоставляет драйвер MySQL.

Это не просто вопрос о том, что лучше, потому что у каждого есть свои преимущества и недостатки. Вам нужно прочитать ссылки, которые я предоставил, и прийти к своему собственному решению, а затем проверить его и выяснить. Я использовал PDO в прошлых проектах, и это хорошее расширение, но мой выбор для чистой производительности был бы MySQLi с новым параметром MySQLND, скомпилированным (когда будет выпущен PHP 5.3).

Общие

• Не пытайтесь оптимизировать работу до того, как вы начнете видеть реальную нагрузку. Возможно, вы и правы, но если нет, то зря теряете время.
• Используйте jmeter, xdebug или другой инструмент для тестирования сайта.
• Если загрузка начинает быть проблемой, скорее всего, будет задействовано кэширование объектов или данных, поэтому обычно читайте о параметрах кэширования (memcached, MySQL параметры кэширования)

Код

• Составьте профиль своего кода таким образом, чтобы вы знали, где находится узкое место и находится ли оно в коде или в базе данных

База данных

• Используйте MYSQLi , если переносимость в другие базы данных не является жизненно важной, PDO в противном случае
• Если тесты показывают, что проблема заключается в базе данных, проверьте запросы перед началом кэширования. Используйте EXPLAIN , чтобы увидеть, где ваши запросы замедляются.
• После оптимизации запросов и некоторого кэширования базы данных можно использовать несколько баз данных. В зависимости от данных, запросов и типа поведения чтения/записи может быть целесообразным либо репликация на несколько серверов, либо сегментирование (разделение данных на несколько databases/servers)).

Кэширование

• Было сделано много записей о кэшировании кода, объектов и данных. Посмотрите статьи на APC, Zend Optimizer, memcached , QuickCache, JPCache . Сделайте это раньше, чем вам действительно нужно, и вы будете меньше беспокоиться о том, чтобы начать работу неоптимизированной.
• APC и Zend Optimizer являются кэшами опкодов, они ускоряют код PHP, избегая повторной обработки и перекомпиляции кода. Как правило, простой в установке, стоит сделать рано.
• Memcached-это универсальный кэш, который можно использовать для кэширования запросов, PHP функций или объектов, а также целых страниц. Код должен быть специально написан для его использования, что может быть вовлеченным процессом, если нет центральных точек для обработки создания, обновления и удаления кэшированных объектов.
• QuickCache и JPCache - это файловые кэши, в остальном похожие на Memcached. Основная концепция проста, но также требует кода и проще с центральными точками создания, обновления и удаления.

Разнообразный

• Рассмотрим альтернативные веб-серверы для высокой нагрузки. Такие серверы , как lighthttp и nginx , могут обрабатывать большие объемы трафика в гораздо меньшем объеме памяти, чем Apache, если вы можете пожертвовать мощностью и гибкостью Apache (или если вам просто не нужны эти вещи, которые часто вам не нужны).
• Помните, что аппаратное обеспечение в наши дни на удивление дешево, поэтому не забудьте потратить усилия на оптимизацию большого блока кода по сравнению с "let's buy a monster server."
• Рассмотрите возможность добавления тегов "MySQL" и "scaling" к этому вопросу

APC -это абсолютная необходимость. Мало того, что это делает для большой системы кэширования, но и выигрыш от автоматического кэширования файлов PHP является находкой. Что касается идеи множественных баз данных, я не думаю, что вы получите много от наличия разных баз данных на одном сервере. Это может дать вам некоторое увеличение скорости во время выполнения запроса, но я сомневаюсь, что усилия, которые потребовались бы для развертывания и поддержки кода для всех трех, пока они синхронизируются, будут стоить того.

Я также настоятельно рекомендую запустить Xdebug , чтобы найти узкие места в вашей программе. Это сделало оптимизацию легким ветерком для меня.

Во-первых, как мне кажется, сказал кнут, "Premature optimization is the root of all evil". Если вам не нужно заниматься этими вопросами прямо сейчас, то не делайте этого, сосредоточьтесь на том, чтобы сначала доставить что-то, что работает правильно. Тем не менее, если оптимизация не может ждать.

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

Я бы исследовал Memcached , поскольку это то, что многие сайты с более высокой загрузкой используют для эффективного кэширования контента всех типов, и интерфейс объекта PHP к нему довольно хорош.

Разделение баз данных между серверами и использование какого - либо метода балансировки нагрузки (например, создание случайного числа между 1 и # избыточными базами данных с необходимыми данными-и использование этого числа для определения, к какому серверу базы данных подключиться) также может быть отличным способом повышения эффективности.

Все это довольно хорошо работало в прошлом для некоторых сайтов с довольно высокой нагрузкой. Надеюсь, это поможет вам начать работу :-)

Профилирование вашего приложения с помощью чего-то вроде Xdebug (например, рекомендуется tj9991), безусловно, будет обязательным. Это не имеет большого смысла, чтобы просто идти вокруг оптимизации вещей вслепую. Xdebug поможет вам найти реальные узкие места в вашем коде, так что вы можете потратить свое время на оптимизацию с умом и исправить куски кода, которые на самом деле вызывают замедление.

Если вы используете Apache, еще одна утилита, которая может помочь в тестировании, - это Siege . Это поможет вам предвидеть, как ваш сервер и приложение будут реагировать на высокие нагрузки, действительно проводя его через свои шаги.

Любой вид кэша кодов операций для PHP (например, APC или один из многих других) также очень поможет.

Я управляю сайтом с 7-8 миллионами просмотров страниц в месяц. Не очень много, но достаточно, чтобы наш сервер почувствовал нагрузку. Решение, которое мы выбрали, было простым: Memcache на уровне базы данных. Это решение хорошо работает, если основной проблемой является загрузка базы данных.

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

Поэтому мы изменили наш подход. Мы построили оболочку базы данных (с теми же методами, что и наша старая база данных, поэтому ее было легко переключить), а затем мы разделили ее на подклассы, чтобы обеспечить memcached методов доступа к базе данных.

Теперь все, что вам нужно сделать, это решить, может ли запрос использовать кэшированные (и, возможно, устаревшие) результаты или нет. Большинство запросов, выполняемых пользователями, теперь извлекаются непосредственно из Memcache. Исключение составляют обновления и вставки, которые для основного сайта происходят только из-за ведения журнала. Эта довольно простая мера снизила нагрузку на наш сервер примерно на 80%.

Как бы то ни было, кэширование в PHP очень просто, даже без расширения/вспомогательного пакета, такого как memcached.

Все, что вам нужно сделать, это создать выходной буфер с помощью ob_start() .

Создайте глобальную функцию кэша. Вызов ob_start , передать функции обратного вызова. В этой функции найдите кэшированную версию страницы. Если существует, служите ему и заканчивайте.

Если он не существует, скрипт продолжит обработку. Когда он достигнет соответствующего ob_end(), он вызовет указанную Вами функцию. В это время вы просто получаете содержимое выходного буфера, помещаете его в файл, сохраняете файл и заканчиваете работу.

Добавьте в некоторую коллекцию expiration/garbage.

И многие люди не понимают,что вы можете вложить ob_start() / ob_end() звонков. Поэтому, если вы уже используете выходной буфер, скажем, для разбора рекламных объявлений или выделения синтаксиса или чего-то еще, вы можете просто вложить еще один вызов ob_start/ob_end .

Спасибо за совет по расширению кэширования PHP - не могли бы вы объяснить причины использования одного над другим? Я слышал много хорошего о memcached по IRC, но никогда не слышал о APC - каково Ваше мнение о них? Я предполагаю, что использование нескольких систем кэширования довольно контрэффективно.

На самом деле, многие действительно используют APC и memcached вместе ...

Похоже, я был неправ . MySQLi все еще разрабатывается. Но, судя по статье, PDO_MySQL теперь поддерживается командой MySQL. Из статьи:

Улучшенное Расширение MySQL - mysqli - это флагманский корабль. Он поддерживает все функции сервера MySQL, включая Наборы символов, подготовленные заявления и сохраняемые процедуры. Водитель предлагает: гибрид API: вы можете использовать процедурный метод или объектно-ориентированный стиль программирования в зависимости от ваших предпочтений. mysqli приходит с PHP 5 и выше. Обратите внимание, что конец из жизни для PHP 4 - это 2008-08-08.

Объекты данных PHP (PDO) являются уровень абстракции доступа к базе данных. PDO позволяет использовать одни и те же вызовы API для различных баз данных. PDO не делает предложите любую степень абстракции SQL. PDO_MYSQL-это драйвер MySQL для PDO. PDO_MYSQL поставляется с PHP 5. По состоянию на PHP 5.3 MySQL разработчики активно способствуют этому. Благо PDO из unified API поставляется по цене, которая MySQL специфические особенности, например несколько утверждений, не являются полностью поддерживается через унифицированный API.

Пожалуйста, прекратите использовать первый MySQL драйвер для PHP когда-либо публиковался: ext/mysql. с момента введения улучшенное расширение MySQL - mysqli - в 2004 году с PHP 5 нет никаких причин все еще использовать самый старый драйвер вокруг. ext/mysql не поддерживает Наборы символов, подготовленные заявления и сохраняемые процедуры. Она ограничена набор функций MySQL 4.0. Примечание что расширенная поддержка для MySQL 4.0 заканчивается на 2008-12-31. Не ограничивайте себя набором функций такого рода старое программное обеспечение! Обновление до mysqli, см. также Converting_to_MySQLi. mysql находится в режим обслуживания только с нашей точки зрения конечно, вид.

Мне кажется, что статья пристрастна к MySQLi. Я полагаю, что склоняюсь к PDO. Мне очень нравится PDO вместо MySQLi. Это прямо передо мной. The API намного ближе к другим языкам, на которых я программировал. Интерфейсы баз данных OO, кажется, работают лучше.

Я не сталкивался ни с какими конкретными функциями MySQL, которые не были доступны через PDO. Я бы очень удивился, если бы это вообще произошло.

PDO также очень медленный, а его API-довольно сложный. Никто в здравом уме не должен использовать его, если переносимость не является проблемой. И давайте посмотрим правде в глаза, в 99% из всех веб-приложений это не так. Вы просто придерживаетесь MySQL или PostrgreSQL, или того, с чем вы работаете.

Что касается PHP вопроса и что нужно учитывать. Я думаю, что преждевременная оптимизация - это корень всех зол. ;) Сначала сделайте свое приложение, постарайтесь сохранить его чистым, когда речь заходит о программировании, сделайте небольшую документацию и напишите модульные тесты. Со всем вышеперечисленным у вас не будет проблем с рефакторингом кода, когда придет время. Но сначала вы хотите сделать это и вытолкнуть его наружу, чтобы увидеть, как люди реагируют на это.

Первый вопрос заключается в том, насколько большой вы действительно ожидаете его получить? И сколько вы планируете инвестировать в свою инфраструктуру? Поскольку вы чувствуете необходимость задать этот вопрос здесь, я предполагаю, что вы рассчитываете начать с малого при ограниченном бюджете.

Производительность не имеет значения, если сайт недоступен. А для доступности вам нужно горизонтальное масштабирование. Самое меньшее, что вы можете разумно сделать, - это 2 сервера, на которых работают apache, php и mysql. Установите один DBMS в качестве раба другого. Выполняйте все операции записи на ведущем устройстве и все операции чтения в локальной базе данных (что бы это ни было) - если только по какой-то причине вам не потребуется считывать только что прочитанные данные (используйте master). Убедитесь, что у вас есть оборудование на месте, чтобы автоматически продвигать раба и ограждать хозяина. Используйте циклический перебор DNS для адресов webserver, чтобы придать больше сходства подчиненному узлу.

Разбиение данных на разные узлы базы данных на этом этапе - очень плохая идея, однако вы можете рассмотреть возможность разбиения данных на разные базы данных на одном сервере (что облегчит разбиение на узлы, когда вы обгоните facebook).

Убедитесь, что у вас есть инструменты мониторинга и анализа данных для измерения производительности ваших сайтов и выявления узких мест. Большинство проблем с производительностью можно устранить, написав лучше SQL / исправив схему базы данных.

Сохранение кэша шаблонов в базе данных-это глупая идея : база данных должна быть центральным общим хранилищем структурированных данных. Храните свой кэш шаблонов в локальной файловой системе вашего веб-сервера - он будет доступен быстрее и не будет замедлять ваш доступ к базе данных.

Используйте кэш ОП-кода.

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

Передвиньте на клиент как можно больше кэширования.

Используйте mod_gzip, чтобы сжать все, что вы можете.

C.

Мой первый совет-подумайте об этом вопросе и имейте его в виду при проектировании сайта, но не перегибайте палку . Часто трудно предсказать успех нового сайта, и я думаю, что ваше время будет лучше потратить на то, чтобы закончить работу раньше и оптимизировать ее позже.

В общем, просто-это быстро . Шаблоны замедляют вас. Базы данных замедляют вас. Сложные библиотеки замедляют вас. Наслоение шаблонов друг на друга извлечение их из баз данных и разбор в сложной библиотеке --> временные задержки умножаются друг с другом.

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

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

Конечно, pdo-это хорошо, но есть некоторые разногласия по поводу его производительности по сравнению с mysql и mysqli, хотя сейчас он кажется исправленным.

Вы должны использовать pdo, если вы предполагаете переносимость,но если нет, то mysqli должно быть так. Он имеет интерфейс OO, подготовленные инструкции и большую часть того, что предлагает pdo (за исключением, ну, переносимости).

Кроме того, если производительность действительно необходима, подготовьтесь к драйверу (native mysql) MysqLnd в PHP 5.3, который будет гораздо более тесно интегрирован с php, с лучшей производительностью и улучшенным использованием памяти (и статистикой для настройки производительности).

Memcache хорош, если у вас есть кластеризованные серверы (и YouTube-подобная нагрузка), но я бы сначала попробовал APC.

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

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

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

Замечания, сделанные в отношении кэша, являются точными; это наименее сложная и наиболее важная часть построения эффективного приложения. Я хотел бы добавить, что, хотя memcached отлично, APC примерно в пять раз быстрее, если ваше приложение живет на одном сервере.

В посте "Cache Performance Comparison" в блоге MySQL performance есть несколько интересных тестов на эту тему- http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/ .

@ Гэри

Не используйте MySQLi -- PDO-это уровень доступа к базе данных 'modern' OO. Самая важная функция для использования-это заполнители в запросах. Он достаточно умен, чтобы использовать серверные настройки и другие оптимизации для вас.

В данный момент я работаю над PDO, и похоже, что вы правы - однако я знаю, что MySQL разрабатывают расширение MySQLd для PHP - я думаю, что преуспею либо в MySQL, либо в MySQLi - что вы об этом думаете?

---

@ Райан , Эрик , tj9991

Спасибо за совет по расширению кэширования PHP - не могли бы вы объяснить причины использования одного над другим? Я слышал много хорошего о memcached-33 годах, но никогда не слышал о APC - каково Ваше мнение о них? Я предполагаю, что использование нескольких систем кэширования довольно контрэффективно.

Я обязательно разберусь с некоторыми тестерами профилирования-спасибо Вам большое за ваши рекомендации по ним.

Я не вижу себя переключающимся с MySQL в ближайшее время - поэтому я думаю, что мне не нужны возможности абстракции PDO. Спасибо за эти статьи DavidM, они мне очень помогли.

Посмотрите в mod_cache, выходной кэш для веб-сервера Apache, аналогичный выходному кэшированию в ASP.NET.

Да, я вижу, что это все еще эксперимент, но когда-нибудь это будет окончательно.

Если вы работаете с большими объемами данных, и кэширование не сокращает их, загляните в Sphinx. У нас были отличные результаты с использованием SphinxSearch не только для лучшего поиска текста, но и в качестве замены поиска данных для MySQL при работе с большими таблицами. Если вы используете SphinxSE (плагин MySQL), это в несколько раз превзошло наш прирост производительности, который мы получили от кэширования, и реализация приложения-это грех.

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

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

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