Сколько категорий потянет движок без проблем?

У меня на форуме сейчас порядка 5000 категорий, это не предел. Сейчас при открывании страницы категории приходиться ждать пока загрузиться вся портянка сколькото (значительно дольше, чем когда было до 100 шт.) секунд.
По фронтэнду пока нет вопросов по времени, хотя я может просто еще не заметил.
На вопрос про непродуманную структуру разделов - продумывал.

 

Можно увидеть это чудо?

 

Пока к сожалению нет. В процессе набивка, наладка, допил.

 

Это видимо форум "Обо всем" иначе зачем ему столько категорий???

 

понимаете хочу сделать сразу форум обо всем интернете. Ну вообще обо всем. Ну типа википедии, тока в форуме. И чтобы можно было грабить корованы. А если серьезно, то какая разница о чем форум. Если вопрос был про производительность движка форума. Да собственно вопрос то и снят. Двиг тянит стока скока тянит бд. Там все проблемы с выводом подкатегорий и категорий разом и на одной странице. Если дополнением ограничить по необходимости, то тянит стока скока надо.

 

Здесь совсем не правы. Все упирается как раз не в базу а в производительность пхп. Запросы к базе занимают минимальную часть времени (если конечно не стоят какие-то кривые дополнения) и это независимо от количества узлов.

 

Ну хотел бы оспорить утверждение про неважность бд. Если к примеру пхп запросит из базы вывести все записи, а записей к примеру мульён. Тогда скорее всего пока будет суть да дело пхп крякнет.
А если в тойже бд записей опять таки мульён, а скрипт запросит выборку у базы последних 10 записей. Не вижу не молейших проблем в производительности. Т.е. Как я понял узкое место это кол-во записей на выборке. Я их сознательно обрезаю во фронтендеде и в админке.

 

В режиме отладки сайта можно посмотреть, какие запросы сколько записей отдавали, а также, использовали ли они индексы и как. Запросы к базе данных сильно зависят не только от количества записей, но и от индексов, их комбинаций, а также от самого запроса. Поиск записи по ключевому полю даже на многомиллионных таблицах производится достаточно быстро, а вот выдать даже из небольшой таблицы в пару десятков тысяч записей сразу 1000 записей по условию WHERE без индекса - это будет офигенный тормоз. А если еще и сортировку добавить не по индексируемому полю, то можно смело закрывать форум на обслуживание. Ведь помимо самого по себе медленного запроса без индексов добавится еще и крайне медленная обработка получения такого большого числа записей в PHP, да еще и последующая их обработка там же для отображения.

 

Я говорил не о сферическом коне в вакууме а именно в контексте xenforo - при большом количестве узлов база не является узким местом.

 

Уважаемые. Я уже приобрел движек. И когда начал набивку сталкнулся с проблемой большого количества категорий. Затем начав рытся по интернету наткнулся на ифу в 500 категорий без проблем. Начал ковырять и понял, таки да . Даже кое где в коде разрабы косвенно указывают на цифру 500. То, что структура вывода форума, и структура админки построенна именоо так и ни иначе, говорит о том, что разработчики видели примерно 500 категорий. С увеличением количества, генирируемая портянка в админке и фронтенде просто огромна.
Насчет infis вашего поста. Я с вами согласен целиком и полностью. Но. Перекапывать движек по мне намного затратнее, чем обрезать функционал потенциально создающий проблемы. Сугубо личное мнение.

 

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

 

Совершенно верно. Так и сделал.

А можно саму идею обьяснить?
Просто на данном этапе пока вроде как подрезал, да подзаточил форум под нужды. А вот на перспективу интересно, куда копать.

 

Можно использовать кеширование. Но это не панацея. То есть кеширование хорошо помогает при медленных или частых запросах. А вот отображение оптимизировать можно, только убрав какие-то "лишние" элементы. Но все равно такие вещи лучше оформлять плагином. Изменения шаблонов надо делать через модификации. Это упростит апгрейды и установку новых стилей.
Ну и можно изменить в принципе логику отображения в админке узлов. То есть отображать их не все сразу, а по мере обращения раскрывать вложенные узлы. Для этого удобно будет использовать AJAX, чтобы динамически подгружать нужное.

 

Спасибо за ответ. Вы подтвердили мои мои мысли по поводу высоко нагрузок. Согласен со всем.