2010-07-29 4 views
9

Этот вопрос, вероятно, не имеет определенного ответа, так что если он считается субъективным и, скажем, bad, пожалуйста, не стесняйтесь его закрывать.Максимальное число запросов SQL закачки

В основном я разрабатываю довольно большое веб-приложение (PHP), и оно использует CakePHP. Сейчас он находится в стадии разработки, и некоторые вещи в базе данных действительно сложны, поэтому необходимо много запросов, чтобы отображать страницы (около 7-25 запросов).

Поскольку это, вероятно, будет крупномасштабным, я хотел бы знать, что такое максимум, то есть сортировка точки, которая указывает, что «вы, вероятно, делаете что-то неправильно и должны оптимизировать », количество SQL-запросов, которые должны выполняться на странице. У меня есть очень простая система кеширования, настроенная прямо сейчас, которая уменьшает количество запросов, которыми управляет один пользователь, до 5 в течение 15 секунд.

Запрашивается 25 запросов? Должен ли я остановить разработку (у меня много времени) на некоторое время и реорганизовать код, удалить SQL-запросы, которые не используются, и посвятить время для повышения производительности в этой части?

Это, вероятно, звучит немного запутанно, поэтому возобновлено: есть ли de facto максимум для количества запросов, запущенных на странице, которая не забивает сервер (то есть, совместно используемая среда хостинга)?

Спасибо.

ответ

7

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

+0

Что вы подразумеваете под «способностью вашей базы данных», как вы определяете эту информацию? – Ash

+0

@Ashley: Я имею в виду способность вашей базы данных выполнять запросы. База данных способна выполнять некоторое среднее количество запросов в минуту. Если вы попытаетесь выйти выше этого предела, скорее всего, все начнет отсчет времени. Я не знаю, есть ли определенный способ определить его, но вы можете проверить его сами, развязывая трафик в своей базе данных, чтобы узнать, как много он может справиться. – recursive

4

В качестве рекурсивного упоминания, нет волшебного числа. Слишком много переменных. Такие, как спецификации сервера баз данных. Ясно, что чем лучше сервер, тем больше запросов вы можете запустить.

0

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

7

Самое главное не количество, но за счет этого запроса ...

Запуск 100 SELECT name FROM foo WHERE id = 1 LIMIT 1 будет намного лучше, чем бег 1 из следующих действий:

SELECT * 
    FROM foo AS a 
    JOIN bar AS b 
    JOIN car AS c 
    WHERE a.col LIKE '%f%' OR b.col LIKE '%b%' OR c.col LIKE '%b%' 

Так не беспокойтесь по номеру, если это не абсурдно (более 100 - это много. Несколько тысяч - абсурд) ... Не забывайте, что вы можете включить Query Cache Cache ... Так что даже если вы нажимаете много запросов в секунду, до тех пор, пока не будет тонны обновлений, большинство из них будут напрямую получать результаты кэша.

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