В PHP, сколько вызовов БД на страницу нормально?

Question

У меня есть общий хостинг на ЛАМПЕ. Очевидно, что чем меньше вызовов Db на страницу, тем лучше. Но сколько это слишком много? Два? Десять? Сотня? Любопытно, что думают люди.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

Не забудьте

1. используйте сохраненные процедуры - они работают быстрее.
2. запускайте их по-новому - раз в неделю. (база данных оптимизирует хранимые процессы, используя свое текущее состояние. Если это изменится, процесс хранения перестанет быть оптимальным).
3. используйте такие команды, как "show plan", чтобы по-настоящему понять, что делают ваши SP.
4. Хранимые процедуры могут возвращать несколько наборов данных (datatables), что сокращает сетевой трафик. Один сохраненный процесс может делать несколько вещей.

Tony

Answer 9

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

Answer 10

Один или меньше всегда лучше. Два обычно один слишком много.

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

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