У меня есть общий хостинг на LAMP. Очевидно, чем меньше обращений к Db на странице, тем лучше. Но сколько их слишком много? Два? 10? Сотня? Любопытно, что думают люди.
Это действительно зависит от настройки серверов (db). Попытайтесь кэшировать большую часть информации, насколько это возможно, и уменьшите количество звонков до минимума. База данных (почти в каждом случае) станет узким местом вашей службы – тем выше будет использование вашего сайта. Поэтому, что бы вы ни старались, избегайте подачи запроса, как будто это действительно не нужно.
Я стараюсь не использовать более 10 дБ вызовов на страницу, но это действительно зависит от вашей инфраструктуры и информации, которую вы хотите предоставить.
Я бы сказал, что это зависит от нагрузки на сервер. Если у вас есть 1 посетитель в минуту, то 1-10 дБ вызовов на страницу будет просто отлично. Если загрузка вашего сервера выше, скажем, 10 запросов страниц в секунду, тогда вы должны рассмотреть вопрос о кешировании, чтобы минимизировать нагрузку на ваш сервер db.
Когда я работал над проектом http://www.boxman.com в буме .com, у них был один веб-сайт, который появился как 9 разных языков / сайтов в разных доменах. Каждый фрагмент текста был извлечен из БД, а также обычные вещи, такие как продукты и т. Д. Каждая страница обычно включала 200 нечетных запросов БД, но главным образом возвращала один идентификатор, комбинацию строк. У нас было 100 пользователей в системе за раз.
БД выполняла DB2 SQL на 16-разрядном блоке unix RS6000. Это, вероятно, эквивалентно современному 3-ядерному ядру с процессором QUAD Core.
Система работала … по мере того, как объемы собирались, я реализовал кеш, который включал в себя процесс синхронизации, который перемещал данные, которые были статичными на ежедневной основе на диск веб-сервера, чтобы он больше не попадал в БД.
В основном я бы сказал, если производительность в порядке, тогда все в порядке! но вы должны позволить расширить спрос и быть готовы к этому, когда это произойдет.
Я думаю, что ваше текущее количество запросов в порядке, пока серверы (веб-и база данных) могут обрабатывать все ваши запросы и возвращать страницу в приемлемое время. Это зависит от серверов в больших масштабах. Тем не менее использование как можно большего количества запросов является хорошим правилом.
Как долго длится струна? Как долго должны быть ноги человека? Сколько запросов БД вы должны делать при загрузке страницы?
Нет единого ответа. Очевидно, что делать ненужные запросы – плохая идея. Запуск чрезмерных соединений с БД еще хуже. Кэширование неизменных значений является хорошим. Помимо этого, вы не можете на самом деле произвольно сказать: «Вы должны использовать только $ N запросов» на странице – это зависит от того, что вы пытаетесь сделать и каковы ваши цели эффективности.
Теоретически, любое приложение может быть написано для использования одного запроса БД – даже если этот запрос представляет собой массивное 20-way-соединение, включающее необъявленные полные сканированные таблицы и возвращающие тысячи строк, которые в основном являются нулями, которые могут привести к смешному объему памяти и времени до как только он попадет в ваше приложение. Понятно, что это было бы очень плохо. В общем, избегайте делать вещи, которые явно расточительны (например, делают кучу однострочных запросов в цикле) и беспокоятся о производительности позже.
По словам Дональда Кнута «Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация – корень всего зла». Все говорят о «масштабируемости», как будто они действительно станут следующим Твиттером, но на самом деле, если бы Twitter сосредоточился на том, чтобы быть таким же большим, как сейчас, они, вероятно, никогда бы не получили продукт в первый раз место.
В конечном итоге это закончится тем, что ожидает ваш пользователь. Если они ожидают, что на странице появятся исчерпывающие данные, должно быть некоторое ожидание: 1.) сайт сможет функционировать под нагрузкой, учитывая, какой объем данных извлекается из db, и 2.) временная стоимость загрузки страницы будет зависеть от загрузки данных для этой конкретной страницы, а не от общей загрузки сервера.
Огромным сторонником того, что приемлемое количество вызовов db также должно быть базовым дизайном db, также. Существуют сайты электронной коммерции для корпоративного уровня, которые регулярно составляют 100% запросов на одну (без загрузки) страницы, просто из-за сложностей базовой структуры db.
В целом, хороший способ взглянуть на вызовы db – определить, загружается ли конкретная страница в течение приемлемого времени, а оттуда искать стратегии для оптимизации времени загрузки и использования процессора и памяти.
Другим важным вопросом, кроме кэширования, является использование подготовленных операторов. Когда вы выполняете запрос, db должен: 1) анализировать запрос и 2) выполнять его. Если вы используете подготовленные операторы, db может кэшировать план запроса, который он использовал в прошлый раз, поэтому каждый запрос будет меньшим бременем для dbms. Не считайте нагрузку в том, сколько запросов вы выполняете, но сколько стресса вы накладываете на dbms. Выполнение 100 подготовленных запросов может быть быстрее, чем выполнение 50 запросов, сгенерированных ad-hoc в коде.
помните, что 100 000 запросов на страницы составляют чуть более 1 секунды в течение 24 часов. Пока все они не запрашивают сразу.
Не забывайте
Тони
Один или менее всегда лучше. Два, как правило, слишком много.
Если вы можете вернуть несколько наборов результатов в одном запросе, сделайте это. Если информация довольно статична, то кешируйте ее и вытаскивайте из кеша.
10 отдельных запросов к базе данных нехорошо, но не собирается убивать сайт с низким уровнем использования.