Joomla сильно перегружает сервер? :(

[leko]

После долгих скитаний по хостингам нашёл очень подходящий американский  вариант для себя , просидел месяц там, все работало стабильно ... и вдруг support пишет мне что сайт безумно перегружает CPU и memory  :-\ и это при максимум 1500 посетителей в день  :-[
До этого была подобная проблема на русском хостинге 
Вот сижу и не знаю что и делать  .... или это не в Joomle дело  ...

сайт мой http://legko.be/ модулей минимум, debug включён если кто захочет посмотреть ....

[Alex_A]

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

[bzzik]

boston - до 20? 

[a.Lexus]

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

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

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

483 queries executed
1
SET sql_mode = 'MYSQL40'

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

[userxp]

boston - до 20? 

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

[boston]

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

[bzzik]

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

[MrBin]

Меня вообще настораживает следущее:

Код:

DELETE FROM jos_session
 WHERE (
 ( time < '1172571909' )
 AND guest = 0
 AND gid > 0
 ) OR (
 ( time < '1172571909' )
 AND guest = 1
 AND userid = 0
 )

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

[Physicist]

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

Код:

alter table jos_session type=heap;

[boston]

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

[era]

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

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

[Physicist]

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

[boston]

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

[smart]

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

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

[era]

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

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

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

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

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

[Physicist]

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

[era]

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

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

[Physicist]

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

[era]

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

Код:

SELECT ms.id AS sid, ms.type AS stype, mc.id AS cid, mc.type AS ctype, i.id as sectionid, i.id As catid, ms.published AS spub, mc.published AS cpub
 FROM jos_content AS i
 LEFT JOIN jos_sections AS s ON i.sectionid = s.id
 LEFT JOIN jos_menu AS ms ON ms.componentid = s.id
 LEFT JOIN jos_categories AS c ON i.catid = c.id
 LEFT JOIN jos_menu AS mc ON mc.componentid = c.id
 WHERE ( ms.type IN ( 'content_section', 'content_blog_section' ) OR mc.type IN ( 'content_blog_category', 'content_category' ) )
 AND i.id = 119
 ORDER BY ms.type DESC, mc.type DESC, ms.id, mc.id

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

[boston]

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

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

[Physicist]

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

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

[boston]

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

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

[Physicist]

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

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

[boston]

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

[Physicist]

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

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

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

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

[boston]

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

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

[Sedoy]

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

[era]

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

[boston]

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

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

[era]

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

[rusreach]

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