В conf_global.php можно подключить различные оптимизаторы, такие как например eAccelerator, XCache и APC

 

Стоит ли это делать? Какие плюсы и минусы в этом?

Обратите внимание

По указанному вами в профиле "Board url" находится не IP.Board, либо модифицированный пиратский скрипт с удаленными копирайтами. Если вы указали неверный URL, пожауйста, поправьте его, потому что он скорее всего потребуется при диагностике вашей проблемы. Нелицензионные скрипты не приветствуются, т.к. зачастую именно некорректное "нуление" и является причиной проблем в них.

Стоит ли это делать?

Пару лет назад на community.invisionpower.com писали что стоит.

 

Какие плюсы и минусы в этом?

Минусов быть не должно. Плюсы - надо смотреть код форума. Возможно где-то это обыгрывается.

А если само кеширование на форуме отключено, то будуь ли работать описанные выше вещи? Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кеша.

А если само кеширование на форуме отключено

То зачем форуму говорить, что включено?

 

то будуь ли работать описанные выше вещи?

Не проверял. По логике скорее всего получим задержку в работе.

 

Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кеша.

О каком кэше идет речь?

 

Вопрос же несколько об другом.

Вопрос, в принципе снимается, ибо уже сижу и читаю про акселераторы эти. Кеширование, которое я отключил, оно действительно на другое влияет.

 

Как уже писал в другое теме, мой текущий shared хостинг имеет непонятный жесткий лимит на объем БД. После установки форума я заметил, что мы очень быстро приближаемся к лимиту. Стал искать причину в БД, нашел таблицы с максимальным количеством строк и одна из этих таблиц была неким кешем таблицы сообщений, то есть дублировала её по количеству строк и объёму. Отключил в админке кеширование сообщений и очистил таблицу. В чем заключается такое кеширование не смотрел, думаю, в таблицу кеша заносится не только сообщения, но и некая информация из других таблиц, чтобы в будущем извлекать её из этой одной таблицы более простым запросом. Или же это сделано, чтобы уменьшить число чтений из основной таблицы сообщений. в которую ещё и запись идёт. Вам виднее.

Если после установки форума приближаетесь к лимиту - меняйте хостера. Без вариантов

Буду менять, конечно, просто отключение этого кеша позволило с лимитом БД в 200 МБ набрать почти 40000 сообщений.

Вопрос, в принципе снимается, ибо уже сижу и читаю про акселераторы эти

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

 

Кеширование, которое я отключил, оно действительно на другое влияет.

Сторонние кэширующие программы тоже помогают, но на серверах с большой памятью. Если нехватка памяти, проще про них забыть.

 

Как уже писал в другое теме, мой текущий shared хостинг имеет непонятный жесткий лимит на объем БД

На любом shared-е есть ограничение к MySQL. Где больше, где меньше.

 

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

Я тоже не смотрел. Или уже не помню. Мог посмотреть и забыть.

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

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

 

В том и прикол данного кеша, что он тоже лежит в mysql.

 

Попробовал включить eaccelerator - напоролся на старую багу с open_basedir, пришлось пока отключить. Разбираюсь.

Попробовал включить eaccelerator

Я его мало использовал, главным образом на Zend Server -ах. В основном раньше сидел на XCache. После переездов все перевел на APC. Хотя основной форум на APC уже давно.

 

напоролся на старую багу с open_basedir

Не слышал. Но у меня традиционно везде open_basedir отключен.

 

Все эти игрушки имеют смысл только на своем VDS

Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кеша

Поздравляю, вы удвоили себе время генерации страниц, так как основная нагрузка ложится на парсинг бб кодов. Эта фигня без кеша будет запускаться при каждом запросе. Для этого кеш постов и прдумали

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

Особенно интересно с поиском (не Сфинкс, внутренний) - с акселераторами намного шустрее ищет.

@siv1987, перееду на другой хостинг - включу обратно. У меня база уже около 220 МБ при лимите на хостинге 200 МБ. Если включить этот кеш, то будет под 400 МБ объем.

@siv1987, перееду на другой хостинг - включу обратно. У меня база уже около 220 МБ при лимите на хостинге 200 МБ. Если включить этот кеш, то будет под 400 МБ объем.

 

у меня база 150 метров за 4,5 года (41000 сообщений + файло и фотопомойки)

у тебя там логи посещений ботов не хранятся год?

@muslimgauze, у меня сообщения есть очень объёмные, в этом причина. Судебные решения, много судебных решений. Киллобайты под спойлерами. Смотрел объёмы таблиц, именно в сообщениях дело.

 

ТОП таблиц

 

Name		Size		Rows	
ibf_posts		167.42		37822	
ibf_inline_notifications		26.41		3836	
ibf_skin_cache		6.08		164	
ibf_members_tracker		3.72		14963	
ibf_message_posts		3.14		3213	
ibf_sessions		2.20		55	
ibf_skin_templates		1.89		850	
ibf_core_sys_lang_words		1.81		10819	
ibf_task_logs		1.15		1547	
ibf_core_editor_autosave		0.45		1

Изменено 10 ноября 201312 г пользователем tasker