2010-08-11 2 views
2

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

и как насчет ....

$sql1 = mysql_query("SELECT * FROM a", $db1); 
while($row = mysql_fetch_assoc($sql1)){ 
    $sql2 = mysql_query("SELECT * FROM b WHERE aid='a'", $db2); 
    $a = mysql_fetch_assoc($sql2); 
} 

это хорошо? Фактически я могу комбинировать $ sql1 и $ sql2 вместе INNER JOIN, но проблема в том, что $ sql1 - это данные запроса из базы данных 1, а $ sql2 - данные запроса из базы данных 2. И я использую Parallels Plesk Panel, которая не позволяет мне добавлять такие же пользователя базы данных в несколько баз данных.

Если я использую этот код на своем веб-сайте, это хорошо? или в любом случае сделать это?

...

+1

Это зависит от производительности, в которой вы нуждаетесь, и от систем, которые вы должны запустить. Например, одна страница из Google или Amazon может выполнять сотни запросов, распространяемых на сотни разных машин. – Ken

+2

Возможный дубликат [MySQL: Сколько запросов на странице слишком много?] (Http://stackoverflow.com/questions/2308747/mysql-how-many-queries-per-page-is-too-many) – thomasrutter

+0

Другой dupe: http://stackoverflow.com/questions/371126/in-php-how-many-db-calls-per-page-is-okay – thomasrutter

ответ

4

Измерьте это.

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

В целом, несколько запросов в запросе довольно нормальные.

Многие сайты имеют десятки запросов в запросе, и они довольно производительным.

С помощью тестера нагрузки, как Apache лавку. (Если у вас установлен Apache, введите ab, чтобы увидеть параметры)

+0

Думаю, что да. Но я не могу объединить 2 запроса из разных баз данных вместе. – Giffary

7

На самом деле у вас есть 2 вопроса в 1.
Общий и конкретный.
У меня есть очевидные ответы, на мой взгляд.

Сколько запросов на одной веб-странице является хорошей производительностью?

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

это хорошо?

Имеет значение, если у вас нет выбора?

И еще, невысказанный вопрос:

Должен ли я быть обеспокоен этим код производительностью сниппета?

Если вы?
У вас есть проблемы с производительностью на данный момент?
Если нет - зачем вообще волноваться? Зачем беспокоиться об этом конкретном фрагменте, а не о другом?
Если да - у вас есть в профиль ваш код первым.
А затем создайте стратегию оптимизации на основе результатов профилирования. Это может быть количество запросов, это может быть правильная индексация, кластеризация, обновление сервера.
Не слепой стрелять.Сделайте разумные шаги.

4

Я люблю держать мину под 8.

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

Медленные запросы значат больше

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

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

У меня есть одна страница (которая на самом деле является образцом/диагностическим инструментом, предназначенным для запуска только администратором), который имеет более 800 запросов, но работает в считанные секунды. Я думаю, они все очень простые запросы.

кэширование Try

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

Если запросы действительно не нужны, а производительность действительно делает разницу, а затем удалить/объединить их

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

1

У меня была такая же проблема.

Проблема в том, что вы используете запрос в цикле. Если ваша запись a имеет 10 строк, она делает 10 запросов. Если ваша запись «a» имеет 100 строк, она будет делать 100 запросов. Таким образом, чем больше строк имеет ваша запись «a», тем хуже она становится.

Решение состоит в том, чтобы помещать запросы в массив и использовать правильные петли foreach для отображения одной и той же вещи только с двумя запросами. Я нашел This site, что действительно понятно по этой теме.

Смежные вопросы