Joomla сильно перегружает сервер? :( - страница 3 - Joomla 1.0: Установка, обновление и настройка

Подскажите JRE Cache работает когда пользователь залогинился?

boston - до 20? 

2leko: полностью согласен.
А JRE Cache — это вообще довольно мощная штука, которая позволяет кешировать так, что запросов к БД не будет вовсе. Вот только за нее деньги платить нужно (хотя и не много — $15).

А у меня вообще полный завал:

Вчера прикрыли аккаунт - нужно срочно оптимизировать:

483 queries executed
1
SET sql_mode = 'MYSQL40'

http://we.crimea.be/debug-catalog.html

boston - до 20? 

канешна.
посмотри внизу футера этого форума - сколько запросов делает SMF
диапазон прим. от 6 до 20

bzzik, да, более чем уверен. При правильном подходе и логическом переосмыслении самой структуры форума - можно и до 20 - это на главную, при этом ни количество тем ни число сообщений или пользователей не должно сильно колебать число запросов. Интересно что будет в новой версии fb, а там уже посомтрим
userxp, в smf более грамотный подход реализован, в нём и таблиц побольше. В VB - еще "интеллектуальнее", но таболиц вообще тьма.

Да я себе поставил smf и оочень доволен!

Меня вообще настораживает следущее:
получается, что таблица jos_session подвергается постоянному "разрушению",
может стоит через cron её переодически оптимизировать?

Стоит. Если не по крону, так через бот OptimizeTables.
А еще рекомендуют изменить ее тип с MyISAM на Heap:

Physicist, расскажи пожалуйста почему рекомендуешь именно этот тип?

вроде он всё-таки MEMORY называется...
вся таблица хранится в памяти поэтому работает поиск по ней очень быстро, но её размер ограничен параметром max_heap_table_size.

При остановке сервера данные в этой таблице не сохраняются
соответственно придётся перелогиниться.

В старых версиях MySQL он назывался именно Heap, в новых можно использовать и Heap, и Memory (в документации действительно рекомендуют использовать именно Memory). Суть работы этого типа era объяснил, а ускорение происходит из-за того, что даже если вы в Joomla сведете число запросов к минимуму (а без хаков это 10, кажется), то 3 из них будут именно к jos_session, к тому же это самая частомодифицируемая таблица.

era, Physicist, спасибо!

era, Physicist, спасибо!

может быть стоит опционально в Joostina вставить конвертацию типа этой таблицы? Поставил галочку - Memory, убрал - снова MyISAM...

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

Вы меня заинтриговали...

Добавлено:
Гы-ы-ы.. и модули и мамботы то-же можно запихнуть.

Добавлено ещё позже:
Да и секции и категории можно туда запихать...

На чём-бы потестить...

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

Просто смотреть, если INSERT или UPDATE идёт в таблицу, то инсертим/апдейтим реальную таблицу, а потом данные синхронизируем между реальной и виртуальной таблицей.

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

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

давай посмотрим на примере например этого запроса:

MySQL закэширует его результат?
а ведь тут кроме jos_content ещё три таблички подвязываются...

smart, как раз про Joostina И думал когда просил уточнения

NORDmen еще предлагал для увеличения быстродействия изменить типа числовых полей - типа id и int(11) на smalint. Что скажите по этому поводу? Может создать сборку с экспериментальным типом таблиц, и протестировать его по скорости к стандартной

MySQL закэширует его результат?

Должен. Я перелистал The MySQL Query Cache и не вижу причин, по которым он не должен попасть в кэш.

Должен. Я перелистал The MySQL Query Cache и не вижу причин, по которым он не должен попасть в кэш.

> MySQL 6.0 Reference Manual
для младших версиях думаешь тоже кэширование такое хорошее?

NORDmen еще предлагал для увеличения быстродействия изменить типа числовых полей - типа id и int(11) на smalint.

Ну тогда лучше на smallint unsigned — так диапазон в два раза больше будет.
А вдруг сайт выйдет за пределы 65535 записей (и то 65535 — это именно для smallint unsigned)? Если публиковать по 10 статей в день, то через 18 лет — кранты сайтику

Physicist, 65535 - не слабое число! Можно раз в неделю / месяц / год выполнять проверку максимального индекса в таблице, и если приближается к краю - сообщать администратора о смене типа таблицы

для младших версиях думаешь тоже кэширование такое хорошее?

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

Physicist, 65535 - не слабое число! Можно раз в неделю / месяц / год выполнять проверку максимального индекса в таблице, и если приближается к краю - сообщать администратора о смене типа таблицы

Можно. С удовольствием пожму руку тому администратору, который приблизится к этому краю.

Обещение сдержал
http://demo.joostina.ru/ - новый тип таблиц. memmory для session + smalint
http://demo.joostina.ru/old/ - старый тип таблиц.

По скорости новый тип выиигрывает чуть более 0.01 сек, но это на небольшом количестве тестовых данных. И по расходу памяти выигрывает - расход меньше на около метра, вот это уже существенно!

а что запросов то так "много" 30?

Зато MySQL будет больше кушать.

Sedoy, эито что бы побольше базу нагрузить.

era, из-за таблицы сессий которая в памяти висит?

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

ОЧЕНЬ волнует по сему вопрос, уважаемые специ...:
планируется сайт на Жумла 1,13 - каталог статей- около 1000-1200 статей(типа энциклопедия).. посещаемость ориентировочная (будет раскручиваться и продаваться под рекламу,партнерки..)- около 1000-2000 хостов в сутки.. и никаких голосований, регистраций, отзывов, форумов и прочих модулей-примочек на страницах не будет- больше текста и картинок опо 1-2 на статью..
ВОПРОС: как по-вашему мнению, уважаемые специ.. -стоит ли ставить OPENSEF? (нравятся мне ссылки вида *.html) или пользоваться встроенным (/..../..../)??   
! И вообще- насколько это серъёзная нагрузка на БД, для ДЖУМЛЫ ? провайдер платный -СВЭБ (spaceweb).. вроде хорошие компы..2 зиона и 4 гига оперативы.. не хочу чтоб потом выгнали с перегрузом и с этой cms..