Модератор
Yui
(@fierevere)
永子
вообще-то ему все равно на адреса,
скорее всего у вас просто есть куки о входе и включена настройка не кешировать страницы для известных пользователей (это правильная в большинстве случаев настройка)
Тут какой-то иной бздик, ибо:
1. я не залогирован.
2. почистил куки.
3. если заходишь на страницу, где копия сделана, то в комментах документа
«<!— Dynamic page generated in 1.447 seconds. —>»
«<!— Cached page generated by WP-Super-Cache on 2018-11-18 10:47:23 —>»
4. если заходишь на страницу где копии нет, то копии физически не создаёт. И сколько не перезагружай, то надписи как в пункте 3 не увидишь.
5. «Режим предзагрузки» не должен зависить от coockie, как и через cron.
Решил пилить код и как бы не пришлось делать костыли.
Обнаружилось, что функция is_dir не всегда определяет папку как папку когда символы пути кириллицей (/home/wp/www/wp-content/cache/supercache/<домен>/product/%d0%bc%d0%bd%d0%be%d0%b3%d0%be%d1%80%d0%b0%d0%b7%d0%be%d0%b2%d1%8b%d0%b9-%d1%86%d0%b2%d0%b5%d1%82-%d0%b2%d0%be%d0%bb%d0%be%d1%81-%d0%ba%d0%be%d0%bb%d0%bf%d0%b0%d1%87%d0%be%d0%ba-s-%d1%86%d0%b2%d0%b5/) и проходит отторжение через фукцию wpcache_do_rebuild( $dir ) {
…
if ( !is_dir( $dir ) ) {
wp_cache_debug( «wpcache_do_rebuild: exiting as directory is not a directory: $dir» );
return false;
}
…
}
Возможный костыль:
Плохо, что получение значения папки ($dir) копий разбросано во многих местах и будет трудновато собрать все места преобразование пути, чтобы преобразовать условную данность в преобразованный путь.
У меня на сайте более 200к страниц. Поэтому 200к копий размещённые в единственной папке какой-то тихий ужас.
-
Ответ изменён 5 лет, 5 месяцев назад пользователем
xrayboy.
Модератор
Yui
(@fierevere)
永子
не на венде сервер случаем?
функция is_dir не всегда определяет папку как папку когда символы пути кириллицей
опять же юниксовые фс достаточно спокойно переваривают по 200к файлов на папку.
ext4 в частности.
-
Ответ изменён 5 лет, 5 месяцев назад пользователем
Yui.
Узкое место это самое медленное устройство чем и явлен HDD. При охеренном количестве объектов в папке опрос содержания папки у жёсткого диска вызывает длительные судороги.
Пока нет возможности всё это барахло пихнуть в оперативную память.
Пока для подобных самостоятельных проектов не хватает знаний и мозга. Поэтому пользуюсь сторонним совтом, который допиливаю бывает основательно, ибо базовая логика работы стороннего совта запилина на условные «несколько» страниц.
200к это не граница, будет 2,5кк+. В день добавляется около 2к страниц. И чем дальше тем больше судороги у жёсткого диска.
Модератор
Yui
(@fierevere)
永子
а обязательно ли вообще кеширование при таком огромном количестве страниц?
неужели на них на все заходят с таким трафиком, что серверу сложно становится просто заново страницу сгенерировать?
Вполне достаточно установить кеширование на короткое время, чтобы в кеше жили самые посещаемые, их не должно быть уж очень много.
И да, уточните, у вас именно страницы или все-таки записи? Если страницы, то WP плохо переваривает базу с огромным количеством страниц, в отличие от записей
На счёт страницы или листы, то все оные лежат в единственной таблице wp_posts и выскрёбывание от туда чего либо с сортировкой занимает много времени. Поэтому мне пришлось изменить код WP и после обновления приходится постоянно менять код. Сортировка делается раз в сутки и лежит всё это в таблицах на движке MEMORY (в оперативной памяти). При обращении WP к получению чего либо идёт перехват и подсовывание отсортированных данных из «быстрых» таблиц.
У меня слабое железо, чтобы думать о «в реальном времени». Генерация страницы занимает около 2 секунды. Раньше было больше 3 секунд и поисковик (робот-паук) ругался.
Если брать готовые копии, то сайт начинает отдавать страницы за миллисекунды (2-30).
На счёт «волшебности» is_dir оказывается она и простые пути не может адекватно воспринять: «<!— wp_cache_debug wpcache_do_rebuild: exiting as directory is not a directory: /home/wp/www/wp-content/cache/supercache/<домен>/page/2/ 1 —>»
Если «/home/wp/www/wp-content/cache/supercache/<домен>/page/2/» не папка, то что?
Чем дальше в «лес» тем суровее «партизаны».
Виновником «отключения» кэширования оказался плагин «Advanced lazy load».
Расследование:
дебаг показал что «Page not cached by WP Super Cache. No closing HTML tag. Check your theme.»
Согласно файла темы footer.php вывод документа полноценно заканчивался закрывающими тегами «</body></html>». Я даже поэкспериментировал те ли это закрывающие теги, поставив после них «</body></html>12345». После обработки на выходе получалось «… 12345 …</body></html>» (вот это кувырки!).
Обнаружилось, что наш WP_Super_Cache не первый хотелец пооперировать с буфером вывода. И кроме его запуска в виде
ob_start( ‘wp_cache_ob_callback’ );
было ещё
ob_start(«Advaced_lazyload»);
ob_start( ‘nxs_ogtgCallback’ );
В итоге выходило, что при каких то условиях:
if (!is_admin() and (!wp_is_mobile() or get_option(‘cb_adlzylad_mobile’)==»on»)){
…
if (!strposa($currURL, explode(«\n», $skipURL_value))) {
ob_start(«Advaced_lazyload»);
}
…
}
Callback-функция «Advaced_lazyload» отваливалась и «не мешала». В итоге WP_Super_Cache находил нужные для него закрывающие теги и начинал кэшировать страницу.
Теория:
Из-за разных манипуляций с выводом какой-то плагин, их может быть много, запускает ob_start ([callback])(включает буферизацию вывода).
Кто последний запустил буферизацию с callback функцией, то та callback-функция последняя получит буфер.
Каждая функция кувыркает буфер как может и как знает, то есть насколько кривые руки и мозг был у программиста, то настолько криво и будет работать на выходе.
ЗЫ: Программисты данного плагина в некоторых логах пишут так, что могут ввести в заблуждение.
