В PHP, сколько звонков БД на страницу в порядке?

Ответ 1

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

Я стараюсь не использовать более 10 дБ вызовов на страницу, но это действительно зависит от вашей инфраструктуры и информации, которую вы хотите предоставить.

Ответ 2

Я бы сказал, что это зависит от нагрузки на сервер. Если у вас есть 1 посетитель в минуту, то 1-10 дБ вызовов на страницу будет просто отлично. Если загрузка вашего сервера выше, скажите 10 запросов страниц в секунду, тогда вам следует рассмотреть вопрос о кешировании, чтобы минимизировать нагрузку на ваш сервер db.

Ответ 3

Когда я работал над проектом www.boxman.com в буме .com, у них был один веб-сайт, который появился как 9 разных языковых/страновых сайтов в разных доменах. Каждый фрагмент текста был извлечен из БД, а также обычные вещи, такие как продукты и т.д. Каждая страница обычно включала 200 нечетных запросов БД, но главным образом возвращала один идентификатор, комбинацию строк. У нас было 100 пользователей в системе за раз.

БД выполняла DB2 SQL на 16-битном блоке unix RS6000. Это, вероятно, эквивалентно современному 3-ядерному ядерному процессору QUAD Core.

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

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

Ответ 4

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

Ответ 5

Как долго длится строка? Как долго должны быть ноги человека? Сколько запросов БД вы должны делать при загрузке страницы?

Нет единого ответа. Очевидно, что делать ненужные запросы - плохая идея. Запуск чрезмерных соединений с БД еще хуже. Кэширование неизменных значений является хорошим. Кроме того, вы не можете на самом деле произвольно сказать: "Вы должны использовать только $N запросов" на странице - это зависит от того, что вы пытаетесь сделать и каковы ваши цели производительности.

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

По словам Дональда Кнута "Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - корень всего зла". Все говорят о "масштабируемости", как будто они действительно станут следующим Твиттером, но на самом деле, если бы Twitter сосредоточился на том, чтобы быть таким же большим, как сейчас, они, вероятно, никогда бы не получили продукт в первый раз место.

Ответ 6

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

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

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

Ответ 7

Другим важным вопросом, кроме кэширования, является использование подготовленных операторов. Когда вы выполняете запрос, db должен: 1) анализировать запрос и 2) выполнять его. Если вы используете подготовленные операторы, db может кэшировать план запроса, который он использовал в прошлый раз, поэтому каждый запрос будет меньшим бременем для dbms. Не считайте нагрузку в том, сколько запросов вы выполняете, но сколько стресса вы накладываете на dbms. Выполнение 100 подготовленных запросов может быть быстрее, чем выполнение 50 запросов, сгенерированных ad-hoc в коде.

Ответ 8

Помните, что 100 000 запросов на страницы составляют чуть более 1 секунды в течение 24 часов. Пока все они не запрашивают сразу.

Ответ 9

Не забывайте

• использовать хранимые procs - они работают быстрее.
• запустить их в свежих - один раз в неделю. (база данных оптимизирует хранимые procs с использованием текущего состояния. Если это изменится, процесс хранения перестанет быть оптимизированным).
• используйте команды типа "показать план", чтобы действительно понять, что делают ваши SP.
• Сохраненные procs могут возвращать несколько наборов данных (datatables), которые сокращают сетевой трафик. Один сохраненный proc может выполнять несколько действий.

Тони

Ответ 10

Один или менее всегда лучше. Два, как правило, слишком много.

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

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