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

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

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

Базы данных

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

Кэширование

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

Я ведущий разработчик на сайте с более чем 15M пользователями. У нас было очень мало проблем с масштабированием, потому что мы планировали это РАНЬШЕ и задумчиво масштабировались. Вот некоторые из стратегий, которые я могу предложить из своего опыта.

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

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

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

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

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

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

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

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

УМЕНЬШЕНИЕ ДАННЫХ Репликация доставляет вам до сих пор. Скорее, чем вы ожидаете, ваши записи станут узким местом. Чтобы компенсировать это, убедитесь, что вы ранены как можно раньше. Скорее всего, вы захотите застрелить себя позже, если вы этого не сделаете.

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

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

ОБРАБОТКА ВНУТРЕННЕГО ОБРАБОТКИ Не заставляйте пользователя ждать вашего бэкэнд, если им этого не нужно. Создайте очередь заданий и переместите любую обработку, которую вы можете отключить, делая ее отдельно от запроса пользователя.

Я работал на нескольких сайтах, которые получают миллионы / хиты / месяц, поддерживаемые PHP и MySQL. Вот несколько основ:

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

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

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

Re: PDO / MySQLi / MySQLND

@ gary

Вы не можете просто сказать «не использовать 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, и именно там происходит mysqlnd, то есть он является родным драйвером, который использует основные внутренние элементы PHP, чтобы максимизировать эффективность, особенно в том, что касается использования памяти.

MySQLnd разрабатывается самими MySQL и недавно приземлился на ветку PHP 5.3, которая находится в RC-тестировании, готовом к выпуску в конце этого года. Затем вы сможете использовать MySQLnd с MySQLi … но не с PDO. Это даст MySQLi повышение производительности во многих областях (не для всех) и сделает его лучшим выбором для взаимодействия с 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, чтобы увидеть, где ваши запросы замедляются.
• После того, как запросы будут оптимизированы и база данных будет кэширована каким-либо образом, вы можете использовать несколько баз данных. Либо копирование на несколько серверов, либо чередование (разделение данных по нескольким базам данных / серверам) может быть целесообразным, в зависимости от данных, запросов и типа поведения чтения / записи.

Кэширование

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

Разное

• Рассмотрим альтернативные веб-серверы для высокой нагрузки. Серверы, такие как lighthttp и nginx, могут обрабатывать большие объемы трафика в гораздо меньшей памяти, чем Apache , если вы можете пожертвовать силой и гибкостью Apache (или если вам просто не нужны те вещи, которые часто у вас нет).
• Помните, что в наши дни аппаратное обеспечение на удивление дешево, поэтому не забудьте потратить усилия на оптимизацию большого блока кода и «давайте покупать сервер монстров».
• Подумайте о добавлении тегов «MySQL» и «масштабирование» к этому вопросу

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

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

Во-первых, как я думаю, Кнут сказал: «Преждевременная оптимизация – это корень всего зла». Если вам не нужно решать эти проблемы прямо сейчас, тогда не делайте этого, сосредоточьтесь на том, чтобы сначала выполнить что-то, что работает правильно. При этом, если оптимизация не может ждать.

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

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

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

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

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

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

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

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

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

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

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

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

Фактически, многие используют APC и memcached вместе …

Для чего это необходимо, кеширование DIRT SIMPLE в PHP даже без пакета расширения / помощника, такого как memcached.

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

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

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

Добавьте в некоторые выдержки / сбор мусора.

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

Похоже, я был неправ . 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 в унифицированном API зависит от того, что специфические функции MySQL, например несколько операторов, не полностью поддерживаются через унифицированный API.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте кеш op-code.

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

Нажимайте как можно больше кеширования на клиента.

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

C.

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

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

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

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

@ Гэри

Не используйте MySQLi – PDO – это «современный» уровень доступа к базе данных OO. Наиболее важная функция для использования – заполнители в ваших запросах. Он достаточно умен, чтобы использовать серверную подготовку и другие оптимизации для вас.

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

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

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

Я определенно буду разбирать некоторые профилирующие тестеры – большое спасибо за ваши рекомендации по этим вопросам.

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

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

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

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

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

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

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

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

В столбце «Производительность сопоставления кеша» в блоге производительности MySQL есть некоторые интересные ориентиры по этому вопросу – http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/ .