Как ускорить любую CMS? Нужна помощь

К примеру дебаг моего скрипта "exec time: 0.032s, MySQL: connected in 0.00312s, running 0.002s in 8 queries. Memory usage: 2286, max 2344 Kb" . 0.02 секунды, самую тяжелую часть, делает twig шаблонизатор. VPS на XEN за 20 евро. InnoDB таблицы с порядка 10к записями.

Это что за зверь такой, "файлохранилище с составными индексами" ?

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

Так что не надо путать обработку/поиск данных и получение уже готовых данных.

Я конечно не силен, но позвольте свои 5 копеек...

Все верно, пихают все подряд. О распределении по частям в базу, и файлохранилища никто и не думает из разработчиков коробочных версий,

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

Тут самое шустрое железо ложится, хоть обкешируйся.

Следя за дискуссией, что то не пойму, при чем здесь индексирование?

Да ладно?! http://habrahabr.ru/post/64325/ - простой пример, когда отказ от БД дает только плюс.

А про кеширования я разве не то же самое говорил? Процитирую СВОИ слова:

---------- Добавлено 05.10.2012 в 10:36 ----------

P.S.: вообще, я не говорил, что БД - плохо )). Использование базы данных дает огромные плюсы, но и несет свои минусы. И когда человек говорит, что БД никогда не будет самым слабым местом в веб-проекте - это повод усомниться в его квалификации.

Опросил всех знакомых, кто так или иначе работал с более-менее нагруженными проектами (от 50к уников в сутки). Во всех, без исключений, случаях проблемы были только с базой.

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

@Root77 - индексы были приведены в пример, как фича баз данных. Хотя их можно использовать почти везде, включая файловые хранилища.

ууу как всё запущено... Опять мешаешь тёплое с мягким..

Что не может быть один точный запрос на доли мс при времени генерации страницы до 1 сек? Очень даже может. Это вообще никак не связано (ну почти ;)).

А вообще можно считать генерация начинается ДО запроса в БД, а заканчивается много позже. Так что подобные заявления - бред

А скорость чтения винтов на серверах. Это воще самый тяжелый момент

Именно. Но есть куча нюансов... Таже генерация (создание) кеша - это доп. нагрузка на хостинг. И опять про скорость чтения винтов...

+1

Ключевой момент - выделен бодом. Но задай себе (и им вопрос) - можно ли избавиться от БД и перевести хранение данных на ФС? Ответ, думаю, очевиден.

Поэтому прямые заявления типа

являются бредом диагональночитающих..

Может. При кривых ручках ;)

Не, нельзя так считать. Иначе придется считать, что запрос данных из базы начинается до того, как пришел юзер (при использовании pconnect). Да и вообще, данные из базы могут запрашиваться отдельно от генерации страниц (например, демон заранее генерирует страницы) ;). Так что "запущено" и "бред" надо употреблять аккуратнее ;)

Стоп-стоп-стоп... Мы про какие винты говорим? Сата? Скази? Ссд? Это во первых. Во-вторых, кто говорит, что надо использовать именно диски? Что, религия запрещает создавать виртуальные диски в памяти? )

Ну а считать генерацию кеша дополнительной нагрузкой - это нечто, т.к. задача кеши именно избавить сервак от основной нагрузки ;)

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

Мдя... Вы работали с нагруженными проектами? Например, 200-300к уников при 3-5М просмотров? Я вот работал. И все, что я говорил выше - это практический опыт, а не теория.

Вообще, всегда удивляли люди, которые начитавшись "умных" книг строят теории. Вот вам еще один холивар - нормализация БД в крупных проектах вредна. А по учебникам - наоборот ;). Ну а я удаляюсь из темы - доказывать, что земля круглая, дело не благодарное в принципе ;)

Чушь же! Или передёргивание, как будет угодно. В "грязном" виде процесс выглядит так:

1. запрос страницы юзером

2. начало генерации

while (..)

{

3. запросы в БД\к файлам

4. генерация по результатам

5. (опционально) запросы (ы) к запрашивающему ЮА

}

endwhile;

5. конечный результат генерации

6. Обработка сервером для выдачи (gzip например)

понеслись фантазии... :)

Т.е. были проведены сравнивания работы высоконагруженных проектов вначале на БД а потом, после их переноса, на ФС? Сравнивали при максимально одинаковых условиях? Нет? Тогда это не более чем "у меня, в конкретном случае тормозит БД". И потому подобные прямые заявления (без конкретной точки приложения) я считаю полным бредом, чушью и тп.

Как и по всему остальному утомительно (и бессмысленно) дискутировать.. Особенно без конкретных задач\условий. (читаем стартпост ТСа).

Все-же на это отвечу и буду считать диалог закрытым )))

А если так:

1. начало генерации

while (..)

{

2. запросы в БД\к файлам

3. генерация по результатам

4. (опционально) запросы (ы) к запрашивающему ЮА

}

endwhile;

5. запрос страницы юзером

6. конечный результат генерации

7. Обработка сервером для выдачи (gzip например)

Да, только не всю систему, а некоторую ее часть (процентов 40 системы). На одном сервере, на одних пользователях и пр. ФС победила. Но ведь это не важно, верно? ))))

Да и у вас ФС победит, если захотеть. Другое дело - поклонение одному направлению, с этим трудно бороться.

БД

Одно дело когда на странице с десяток простеньких запросов. Запросы пролетают за тысячные доли секунды.

И совсем другое когда на странице сотня другая сложных запросов с многочисленными join'ами. (любой более-менее сложный проект на Битрикс или на том же Drupal). В данном случае спасает только кэширование.

Файлы.

Чтобы построить более-менее сложную структуру проекта потребуется возможно с десяток файлов с довольно сложной структурой (XML или JSON), а для организации сложной выборки придется написать собственные велосипеды.

Но возможно да, работать оно будет быстрее. Зато рулить большими объемами данных будет намного сложнее.

ИМХО спор ни о чем.

Для мелких сайтов можно и CMS на файлах, для средних SQL-базы и кэширование, для огромных проектов распределенные NOSQL-базы, разделение данных проекта на более мелкие сущности и работа с ними индивидуально (к примеру как сделано на авито где поисковый индекс собирается sphinx'ом с магическими костылями).

50к весьма относительная цифра. Для вордпресса это много, для заточенного под проект движка - мало. В адалте 50к вообще так себе, середнячок. У меня на работе сайт 100 юников в сутки и пара десятков миллионов записей данных для логистик компании, где база грузится почище любого вордпресса. Вот и думай, что значит "большая нагрузка".

а меня вот смущает требования наличия mysql библиотек для инсталяции сфинкса. Отказ от БД говорите ?

Текущая моя работа: 400-500 уников онлайн круглосуточно. При этом 20Мб канала занимают постоянно. И схема выше, когда данные готовятся еще до появления пользователя, именно с него. Да, "большая нагрузка" - понятие относительное, полностью согласен.

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