Сколько запросов к базе за 1 страницу?

Да кэширование результатов запросов надо делать в файлы. А там уже пофиг сколько их 20 или 100. Класс для кэширования запросов есть, могу поделиться :). Хотя наверное для CMS кэширование не актуально.

Согласен, что надо использовать MySQL+Files(cashe)

Понятно, что элементарный include на порядок быстрее чем вывод из базы.

Не знаю как другие, но я обычно с высокозагруженными проектами веду себя следующим образом. Информация хранится в MySQL. Это удобно, для администрирования сайта. Та же информация, которая выводится из MySQL пользователям предварительно кэшируется в файлы. Любое обновление администратора тут же отражается на кэше, но на сайт инфа выводится через кэш. Меню, формы опросов, какие-то информационные блоки, которые не часто обновляются, тексты новостей и статей. Да много что. Тут главное палку не перегнуть, чтобы не замусорить кучей файлов. Да даже список последних статей можно закешировать. Затем когда уже ясно, что именно кэшируется, ввожу время существования кэша. Скажем юзер прочитал статью. Время продлилось. Еще один прочитал и т.д. ... В итоге я точно знаю, какие части активно юзеры используют, а какие нет.

Во! давно хотел спросить а какой примерный предел количества файлов, при котором начинается деградация производительности файловой системы? У меня уже примерно 25К файлов, пока при включении/отключении кэша приоритет производительности за кэшем? А что будет потом? Да и пару раз уже приколы с именами файлов были (используется MD5(запрос)) приходилось умышленно запросы изменять :( ?

А насчёт автоматической перестройки кэша при изменении данных в таблице вот кусок кода с класса кэша:

                if (file_exists($this->cacheFilename)){

                    //we have cache

                    $this->cachetime = filemtime($this->cacheFilename);

                    if ((time()-$this->cachetime) < $this->cacheDuration || $this->cacheDuration==-1){

                        //cache didn`t expired

                        if($sqlcash['smartupdate']===true && $this->cacheDuration==-1){

                           preg_match_all("/(?:[\t \r\n]{1,100}(?:FROM|JOIN)[\t \r\n]{1,100})(.*(?:JOIN|WHERE)?)/i",$this->query,$matches);

                           while(list($key,$tablepack)=each($matches[1])){//для всех наборов таблиц в запросе

                              $val = preg_split("/,|([\t\r\n ]{1,100}ON[\t\r\n ]{1,100}.*)|([\t\r\n ]{1,100}AS[\t\r\n ]{1,100}[^,]*)|([\t\r\n ]{1,100}WHERE[\t\r\n ]{1,100}[^,]*)/i",$tablepack,-1,PREG_SPLIT_NO_EMPTY);

                              while(list($key,$table)=each($val)){//для каждой таблицы

                                    $tmptbname=strtolower(trim($table,"\`\\\'\" \r\n"));

                                    if(isset($this->_dbstate[$tmptbname]) && $this->cachetime < $this->_dbstate[$tmptbname]){

                                       $this->smartupdated = true;

                                       return true;

                                    }

                              }

                           }

                           $this->smartupdated = false;

                        }

                        return false;

                    }else return true;

                }else return true;

_dbstate заполняется при подключении к БД

                    $tmpa = $this->query("SHOW TABLE STATUS FROM `{$config['dbname']}`");

                    $this->_cash->_dbstate="";

                    while($table = $tmpa->fetch())

                          $this->_cash->_dbstate[strtolower($table['Name'])]=strtotime($table['Update_time']);

Уважаемый 3dn! Заставил себя "асилить" Ваш сумбурный бред, а теперь по порядку.

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

Ну если в среднем 30-40 тысяч уников в сутки для Вас это мало, то жму руку. Быстро для меня - это не более 0.2-0.3 секунды на общее время выполнения запросов к БД.

Индексы применяются для ускорения сортировки, выборки из базы по ключу и создания связанных запросов (join). Ещё раз повторюсь, что для ускорения работы и уменьшения нагрузки на сервер СУБД часть таблиц денормализуется, что позволяет не использовать связанные запросы и существенно сокращает количество обращений к БД. Плюс поверьте мне на слово, а если не доверяете - поставьте эксперимент и проверьте, что очень часто в системах с большим количеством пользователей и большими массивами информации гораздо эффективнее сделать пять запросов подряд, чем один запрос с тремя джойнами. И ещё, так для пополнения начальных данных о СУБД, - при конфигуроровании СУБД часть памяти мы выделяем под различные кэши, так вот один из них служит для кеширования индексов, другой последних запросов и т.п. Эта система гораздо сложнее и умнее, чем Вы думаете. Приведу протой пример: в таблицу СУБД MySQL нужно добавить 10К записей. Казалось-бы - простая задача. Ан нет, - опытный программист перед этим выключит индексы, сделает добавление, а потом их включит. А знаете почему? Потому что после каждой операции insert кэш индекса заново перестраивается и сбрасывается на диск. А при правильном подходе это будет сделано только один раз. Представляете, какой выигрыш в производительности получается, когда эта таблица содержит сотни тысяч записей? Как минимум- 2-3 порядка. Естественно, программист должен быть уверен в том, что на вход он подаёт правильные данные и индекс потом будет создан. Но это уже другая тема...

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

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

Кто бы спорил. Только позвольте сделать одно замечание, когда Вы используете файлы, то по сути создаёте свою миниСУБД, т.к. пишите небольшую надстройку для управления записью-чтением данных из файлов. Чем не СУБД. Иногда, Вы не поверите, для таких файлов делают даже индексные файлы, что ещё больше приближает эту минисистему к стандартам СУБД.

Любой НОРМАЛЬНЫЙ проект, который приносит владельцу стабильный доход (под доходом я понимаю суммы от 1К$ и выше), не будет хоститься на одном компьютере с другими проектами, т.к. не будет ставить свой бизнес в зависимость от того, что какой-то программист на своём хомяке зациклил какую-нибудь процедуру. Такие проекты располагаются на выделенных серверах, а зачастую даже не на одном.

Что касается кеширования, - при правильном написании проекта оно выполняется частично сервером хостера, частично браузером клиента, а частично процедурами, предусмотренными создателем проекта. Огромная роль в это отводится также операционной системе, СУБД и железу сервера. И, по-моему, Вы не совсем представляете, что такое динамическое изменение информации, когда 2/3 выводимой информации изменяется не реже, чем раз в 3-5 минут.

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

И ещё тип таблицы сменит :), когда речь пойдет не о 10К а об 100К.

Больше добавить нечего.

medaest, вы, наверно, лбом двери открываете. СКОРПИОН дело говорит. Параноя минимализации запросов ведет к тому, что они становятся слишком перегруженными и работают медленнее, чем сделанные по-одиночке. Кроме того, есть такие сайты, у которых, скажем, на морде, очень много разнородной информации. выводятся разные объекты, соответственно, разные таблицы. Какой идиотской должна быть причина выбирать новости и покупательскую корзину одним запросом?

Я нигде не говорил что необходима минимизация количества запросов. А про мой лоб не беспокойтесь, он мой :).

medaest, я к тому, что человек высказал очень здравую мысль по поводу сокращения машинного времени обработки. А вы съязвить изволили.

Я согласился с человеком, давайте флудить не будем.

Прочитав все вышесказанное понял 2 вещи:

1. Иду в правильном направлении;

2. Еще учиться и учиться...

А насчет объединения - я им не пользуюсь почти, считаю, что малоэффективно будет потом РНР сортировать вывод из базы. Стараюсь уменьшать количество запросов не их объединением, а более тщательной разработкой структуры базы. А вот меню решил в файл переложить, -2 запроса, все-таки.

Большой фанкс всем ответившим.