Тактика использования PHP на сайтах с высокой нагрузкой

Question

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

---

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

Базы данных

В настоящее время я планирую использовать функции MySQLi в PHP5. Однако как мне настроить базы данных по отношению к пользователям и контенту? Нужно ли мне несколько баз данных? На данный момент все перемешано в одной базе данных - хотя я рассматривал возможность распространения пользовательских данных в одну, фактического контента в другую и, наконец, основного контента сайта (мастеров шаблонов и т. Д.) В другую. Я считаю, что отправка запросов в разные базы данных облегчит их загрузку, поскольку одна база данных = 3 источника загрузки. Также будет ли это эффективно, если они все будут на одном сервере?

Кэширование

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

Мой вопрос по этому вопросу:

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

Наконец

У кого-нибудь есть какие-либо советы / указатели для запуска сайта с высокой нагрузкой на PHP. Я почти уверен, что это работоспособный язык - Facebook и Yahoo! дать ему большое преимущество - но есть ли какие-то события, которые я должен остерегаться?

Answer 1

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

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

Answer 2

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

Улучшенное расширение MySQL - mysqli - это флагман. Он поддерживает все функции MySQL Server, включая Charsets, подготовленные заявления и Хранимые процедуры. Водитель предлагает гибридный API: вы можете использовать процедурный или объектно-ориентированный стиль программирования основываясь на ваших предпочтениях. MySQL приходит с 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, когда-либо опубликованный: внутр / MySQL. С момента введения улучшенное расширение MySQL - mysqli - в 2004 году с PHP 5 не было причин использовать самый старый драйвер вокруг. ext / mysql не поддерживает Charsets, подготовленные заявления и Хранимые процедуры. Ограничено набор функций MySQL 4.0. Заметка что расширенная поддержка MySQL 4.0 заканчивается в 2008-12-31. Не ограничивайте себя набором функций таких старое программное обеспечение! Обновление до mysqli, см. также Converting_to_MySQLi. MySQL находится в режим обслуживания только с нашей точки зрения зрения.

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Использовать кэш кода операции.

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

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

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

С

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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

Answer 10

@ Gary

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

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

---

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

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

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