Является ли 20 запросов SQL запросов на страницу действительно много?

Ответ 1

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

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

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

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

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

Ответ 2

Это больше о кешировании.

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

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

Также возникает проблема оптимизации запросов. Особенно избегая страшной ситуации N + 1, где вы делаете один запрос для родительской записи, а затем дополнительный запрос для каждого из своих детей. Задержка между поездкой туда и обратно в базу данных только убьет вашу производительность рендеринга страницы, не говоря уже о том, чтобы вызвать горе в самой БД.

Ответ 3

Ответ действительно зависит от нескольких ключевых моментов: - Объем трафика вашего сайта - Бюджет ИТ для вашей поддержки - сложность сайта и ресурсов, необходимых для оптимизации

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

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

Единственное, что я скажу, это кеширование - ваш друг.

Ответ 4

Я всегда опаздываю на вечеринку, это уже 5 лет...

Но точка-точка ответа на этот вопрос будет заключаться в том, что ЧИСЛО ВОПРОСОВ ВОПРОСОВ МЕНЬШЕ, ЧЕМ ОБЩЕЕ ВРЕМЯ, ПРИНИМАЕМЫЕ ПОСЛЕДСТВИЯМ QUERIES.

Если большой запрос с несколькими объединениями и подзапросами занимает 20 секунд для выполнения, то (я думаю) гораздо важнее 20 небольших запросов, которые занимают всего 20 секунд.

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

Ответ 5

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

Объединение запросов, где это возможно, может помочь, но думать о кешировании - самая важная часть.

В настоящее время я обновляю сайт, где данные, которые меняются 5 или 6 раз в год, запрашиваются тысячи раз в день, используя какой-то очень неприятный SQL, чтобы превратить его в дерево, но можно сохранить в виде древовидной структуры примерно в 200 тыс. ОЗУ. (700k viewstate на первой странице тоже, но эта другая история...) Это те вещи, которые калечат веб-сайты без уважительной причины.

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

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

Ответ 6

Учитывая, что, не используя Ajax, каждая страница является атомарной, я не обнаружил, что сложно создавать довольно сложные страницы в 3 или менее запросах. Концептуально типичный набор страниц включает в себя:

• Контекстная информация (связанная с сеансом и другим глобальным состоянием);
• Заголовок (и связанные 1: 0-1 соединения);
• Подробный (1: M от 2).

Для этого требуется некоторое планирование; но, с другой стороны, это простое рефакторинг в большинстве случаев.

Ответ 7

Мое эмпирическое правило позволяет, если это возможно, видеть передние страницы до 5-7, в зависимости от типа сайта.

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

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

Ответ 8

Количество запросов не так важно все время. Это действительно то, как вы обрабатываете связи. Если у вас есть пул соединений, то это действительно не имеет значения и имеет значение физическое расположение серверов. Если ваши серверы находятся рядом с eachother в центре обработки данных, настройка соединения, вероятно, очень быстро. В большинстве случаев ваш сайт тратит нагрузку, если сайт, управляемый базой данных, будет потрачен, ожидая открытия соединений и для получения данных. Рисунок для открытия соединения занимает 100 - 300 мс. Поэтому, если вам нужно открыть 20 подключений для каждого доступа к базе данных, через 4-6 секунд просто откроете и закрываем соединения.

Поскольку Джефф Этвуд использует LINQ, я предполагаю, что он только открывает одно соединение, выполняя 20 запросов и закрывая соединение. Все это, вероятно, происходит довольно быстро.

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

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

Ответ 9

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

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

Если у вас есть привилегии, и ваша СУБД способна (например, Oracle и более старые версии MySql), более 20 запросов требуют, чтобы вы начали создавать хранимые процедуры, функции и триггеры для тяжелых задач. Во многих случаях вы не можете, поэтому количество запросов естественно растет, и вы начинаете использовать кеш, чтобы облегчить давление на сервер.

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

Пример из Vinko может быть правдой для небольших, 1 недели проектов разработки, но если вы спросите об Amazon, они не используют ваш общий пакет разработки PHP/MySQL; за передней дверью лежит сложная система распределенных вычислений и алгоритмов интеллектуального анализа данных. Если вы новичок, вы не должны брать таких больших братьев для справки...