Ответ 1

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

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

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

Базы данных

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

Кэширование

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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).

Ответ 5

Общие

• Не пытайтесь оптимизировать, прежде чем вы начнете видеть реальную нагрузку. Вы можете догадаться, но если вы этого не сделаете, вы потратили свое время.
• Используйте 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" и "масштабирования" к этому вопросу

Ответ 6

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

Ответ 12

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

Улучшенное расширение MySQL - mysqli - является флагманом. Он поддерживает все функции MySQL Server, включая Коды, подготовленные заявления и Хранимые процедуры. Водитель предлагает гибридный 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 активно вносят свой вклад в это. Преимущество ПДО в унифицированный API поставляется по цене, которая Специфические функции MySQL, например несколько заявлений, не полностью поддерживается через унифицированный API.

Пожалуйста, прекратите использовать первый MySQL драйвер для PHP, когда-либо опубликованный: внутр /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. Это прямо мне. API намного ближе к другим языкам, которые я запрограммировал. Интерфейсы OO Database работают лучше.

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

Ответ 13

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

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

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

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

Использовать кеш op-code.

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

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

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

С.

Ответ 17

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

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

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

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

Ответ 18

@Гари

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

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

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

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

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

Ответ 19

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

Ответ 20

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

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

Ответ 21

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

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

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

Ответ 22

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

Ответ 23

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

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