Скорость com_conten сравнительно с разными CCK - Joomla 3.x: Общие вопросы

Ранее все сайты делал стандартными средствами Joomla, впринципе устраивало. Новый проект хочу попробовать делать на на "конструкторе" и вот думаю стоит ли (делать на конструкторе). Так вот вопрос: пробовал ли кто сравнивать скорость работы com_content с разными конструкторами контента (предположим что они не нагружены сторонними модулями, плагинами и компонентами, тобиж работают в чистом виде)?

Например К2 работает быстрее чем стандартный com_content, но в нем тона индусского кода..
поэтому писал свое расширение узкозаточенное под нужды сайта.. как то не хочется пару кирпичей везти на белазе )

Я с конструкторами слабо знаком, но многочисленым отзывам решил попробовать k2 и увы (может настроил Неправильно) его скорость не порадовала, присматриваюсь к seblod...

Я с конструкторами слабо знаком, но многочисленым отзывам решил попробовать k2 и увы (может настроил Неправильно) его скорость не порадовала, присматриваюсь к seblod...

ну сравнивалась скорость k2 и com_content на которых 20+ тысяч материалов! и поверьте, к2 рвет com_content как тузик грелку ) притом что уже на 15 тысячах статей в com_content вы будете статью сохранять больше минуты )
но это не меняет того что в к2  все через одно место сделано.. да и скорость всегда вас радовать не будет в любом конструкторе!

я пробовал на 3800 материалов.

да и скорость всегда вас радовать не будет в любом конструкторе

да уж, похоже так оно и есть ((

так что меряем, ребят? скорость показа материалов или скорость сохранения материала в админке?))) для овер10к мне кажется напрямую с базой надо работать в плане наполнения, разве не?

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

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

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

притом что уже на 15 тысячах статей в com_content вы будете статью сохранять больше минуты )

Оффтоп: это как количество статей влияет на скорость сохранения? Каким образом количество записей влияет на INSERT?

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

Оффтоп: это как количество статей влияет на скорость сохранения? Каким образом количество записей влияет на INSERT?

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

Все банально, проблема с таблицей #__assets! при каждой вставке материала идет и вставка данных в эту таблицу! в этой таблице дерево в виде nested sets! При каждой вставке насколько я понимаю идет пересчет ключей.. и вот чем больше записей тем дольше пересчет, в итоге как то делал сайт, после 10к материалов ощутимо чувствовалось.. пришлось писать свою обертку, и юзать свою таблицу! на другом сайте когда импортнул 24 тысячи материалов, я две минуты ждал сохранение нового материала и не дождавшись закрыл и таки влупил тоже свой компонент!

А можно взглянуть на этот волшебный компонент?

А можно взглянуть на этот волшебный компонент?

а чего на него смотреть? там ничего особенного нет ) узкозаточенный под нужды сайта )

а как посмотреть кол-во запросов в базу?

а как посмотреть кол-во запросов в базу?

Включить режим отладки в админке.

Подтверждаю, k2 быстрее com_content. В com_content не только создание материала начинает тормозить, а ещё если вывести блог категории, в которой 10000 материалов, то переход по его страницам превращается в сполшной тормоз. А если там ещё вывод из подкатегорий, то это всё.

Самый заточенный на поддержание нагрузки компонент для Joomla - это imho движок форума Kunena. Его разработчики реально большую работу в плане оптимизации проделали. Пример http://www.joomlapolis.com/forum/index 50000 тем, 200000 сообщений. Всё шевелится прекрасно, почти как на пустом и это ещё далеко не предел.
Конечно доп. полей туда так просто не добавишь, но к примеру видел как из него сделали блог простой переделкой шаблона категории. И получается, что тут-же блог, тут-же добавление с фронта, тут-же комментарии, тут-же модерация, права разные и всякое такое.

Ну насчет Kunena - не совсем, есть форум который еле жив...
Относительно может только.
А насчет cck - циферки.

А насчет cck - циферки.

Довольно таки интересно.

А может ли кто-то что-то сказать по поводу этого коммента

Недавно Rockettheme отаказались от поддержки К2 именно по причине что он очень медленный.

А может ли кто-то что-то сказать по поводу этого коммента

Он не только медленный ) если смотреть его код... от него попахивает ))) вроде такой мощный компонент, а костыль на костыле, да ещё и в стиле человека который только программированием начал заниматься )
Но как я выше говорил ничего не будет лучше самописного узкозаточенного компонента, но это только в том случае если у вас достаточно знаний!

K2 не обновляют давно, просто сами JoomlaWorks предлагаю другое решение уже в своем клубе... так что не знаю что с ним будет.

Недавно Rockettheme отаказались от поддержки К2 именно по причине что он очень медленный.

Кстати я не вижу такой новости у них можно пруф? Последний шаблон у них поддерживает K2 из коробки

По теме так советую попробовать FLEXIcontent он божественен, со своими проблемами конечно но лучше я просто не встречал.

Seblod хоть и работает c com_content, но и отождествлять его с com_content  и сравнивать по этой аналогии с другими CCK некорректно. При необходимости можно отключить интеграцию с com_content и хранить данные в любых таблицах и брать данные из любых таблиц базы данных.

Seblod крутой но очень сложный для не подготовленных)

Seblod крутой но очень сложный для не подготовленных)

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

По теме так советую попробовать FLEXIcontent

тут о флекси не очень хорошо говорят. Статья правда старенькая, но все же. (впринципе, не о скорости статья... ) Поставил, пробую.