Опубликовано: 8 ноября 201312 г В conf_global.php можно подключить различные оптимизаторы, такие как например eAccelerator, XCache и APC Стоит ли это делать? Какие плюсы и минусы в этом?
Опубликовано: 8 ноября 201312 г Обратите внимание По указанному вами в профиле "Board url" находится не IP.Board, либо модифицированный пиратский скрипт с удаленными копирайтами. Если вы указали неверный URL, пожауйста, поправьте его, потому что он скорее всего потребуется при диагностике вашей проблемы. Нелицензионные скрипты не приветствуются, т.к. зачастую именно некорректное "нуление" и является причиной проблем в них.
Опубликовано: 9 ноября 201312 г Стоит ли это делать?Пару лет назад на community.invisionpower.com писали что стоит. Какие плюсы и минусы в этом? Минусов быть не должно. Плюсы - надо смотреть код форума. Возможно где-то это обыгрывается.
Опубликовано: 9 ноября 201312 г А если само кеширование на форуме отключено, то будуь ли работать описанные выше вещи? Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кеша.
Опубликовано: 9 ноября 201312 г А если само кеширование на форуме отключеноТо зачем форуму говорить, что включено? то будуь ли работать описанные выше вещи? Не проверял. По логике скорее всего получим задержку в работе. Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кеша. О каком кэше идет речь? Вопрос же несколько об другом.
Опубликовано: 9 ноября 201312 г Вопрос, в принципе снимается, ибо уже сижу и читаю про акселераторы эти. Кеширование, которое я отключил, оно действительно на другое влияет. Как уже писал в другое теме, мой текущий shared хостинг имеет непонятный жесткий лимит на объем БД. После установки форума я заметил, что мы очень быстро приближаемся к лимиту. Стал искать причину в БД, нашел таблицы с максимальным количеством строк и одна из этих таблиц была неким кешем таблицы сообщений, то есть дублировала её по количеству строк и объёму. Отключил в админке кеширование сообщений и очистил таблицу. В чем заключается такое кеширование не смотрел, думаю, в таблицу кеша заносится не только сообщения, но и некая информация из других таблиц, чтобы в будущем извлекать её из этой одной таблицы более простым запросом. Или же это сделано, чтобы уменьшить число чтений из основной таблицы сообщений. в которую ещё и запись идёт. Вам виднее.
Опубликовано: 9 ноября 201312 г Если после установки форума приближаетесь к лимиту - меняйте хостера. Без вариантов
Опубликовано: 9 ноября 201312 г Буду менять, конечно, просто отключение этого кеша позволило с лимитом БД в 200 МБ набрать почти 40000 сообщений.
Опубликовано: 9 ноября 201312 г Вопрос, в принципе снимается, ибо уже сижу и читаю про акселераторы этиЕсть смысл поставить. Ускоряет работу. На первый взгляд не сильно, но при загрузках сервера, может спасти. Кеширование, которое я отключил, оно действительно на другое влияет.Сторонние кэширующие программы тоже помогают, но на серверах с большой памятью. Если нехватка памяти, проще про них забыть. Как уже писал в другое теме, мой текущий shared хостинг имеет непонятный жесткий лимит на объем БДНа любом shared-е есть ограничение к MySQL. Где больше, где меньше. В чем заключается такое кеширование не смотрел, думаю, в таблицу кеша заносится не только сообщения, но и некая информация из других таблиц, чтобы в будущем извлекать её из этой одной таблицы более простым запросом.Я тоже не смотрел. Или уже не помню. Мог посмотреть и забыть. Принцип нормальных кэширующих программ, выдать данные из кэша. Запрос к MySQL все таки ресурсоемкая вещь.
Опубликовано: 9 ноября 201312 г Принцип нормальных кэширующих программ, выдать данные из кэша. Запрос к MySQL все таки ресурсоемкая вещь. В том и прикол данного кеша, что он тоже лежит в mysql. Попробовал включить eaccelerator - напоролся на старую багу с open_basedir, пришлось пока отключить. Разбираюсь.
Опубликовано: 9 ноября 201312 г Попробовал включить eacceleratorЯ его мало использовал, главным образом на Zend Server -ах. В основном раньше сидел на XCache. После переездов все перевел на APC. Хотя основной форум на APC уже давно. напоролся на старую багу с open_basedirНе слышал. Но у меня традиционно везде open_basedir отключен. Все эти игрушки имеют смысл только на своем VDS
Опубликовано: 9 ноября 201312 г Кеширование отключил, поскольку оно удваивает объём БД, дублируя посты в таблицу кешаПоздравляю, вы удвоили себе время генерации страниц, так как основная нагрузка ложится на парсинг бб кодов. Эта фигня без кеша будет запускаться при каждом запросе. Для этого кеш постов и прдумали
Опубликовано: 10 ноября 201312 г Автор Проверил работу этих акселераторов. На "глазок" страницы стали открываться заметно быстрее, практически моментально.Особенно интересно с поиском (не Сфинкс, внутренний) - с акселераторами намного шустрее ищет.
Опубликовано: 10 ноября 201312 г @siv1987, перееду на другой хостинг - включу обратно. У меня база уже около 220 МБ при лимите на хостинге 200 МБ. Если включить этот кеш, то будет под 400 МБ объем.
Опубликовано: 10 ноября 201312 г @siv1987, перееду на другой хостинг - включу обратно. У меня база уже около 220 МБ при лимите на хостинге 200 МБ. Если включить этот кеш, то будет под 400 МБ объем. у меня база 150 метров за 4,5 года (41000 сообщений + файло и фотопомойки)у тебя там логи посещений ботов не хранятся год?
Опубликовано: 10 ноября 201312 г @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
В conf_global.php можно подключить различные оптимизаторы, такие как например eAccelerator, XCache и APC
Стоит ли это делать? Какие плюсы и минусы в этом?