Бесполезный кэш

[morgenshtern 5]

С мемкешем разобрался, стало все понятно еще месяц назад - он не работает так как надо. Перешел на файловый кэш и тут ждала очередная подстава о которой и не подозревал.

Заметил что большинство старых страниц очень тяжело грузятся и всему виной оказался  fullcache_days

 

Я почему то всегда считал что этот параметр задает время жизни кэша, по истечении которого кэш пересоздается, а нет, после 30 дней кэш отключается.

 

Как написано в админке  "Создание и обновление кеша, эта тоже ресурсоемкая операция."  Т.е. по-вашему запрос на создание кэша для страницы раз в неделю это хуже чем сотня тяжелых mysql запросов на страницу в час? И дело тут не в избыточных дисковых операциях и большом количестве файлов в папке cache. Mysqld начинает очень сильно жрать процессорное время и вешать сервер.

 

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

 

Нужно создать отдельную вкладку с кэшем, где можно будет задать время жизни кеша для страниц fullstory, main, alltags итд

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

[celsoft 6 082]

25 минут назад, morgenshtern сказал:

Я почему то всегда считал что этот параметр задает время жизни кэша, по истечении которого кэш пересоздается, а нет, после 30 дней кэш отключается.

C чего вы это взяли непонятно. Это время в течении которого для публикации будет использоваться кеш.

 

25 минут назад, morgenshtern сказал:

Т.е. по-вашему запрос на создание кэша для страницы раз в неделю это хуже чем сотня тяжелых mysql запросов на страницу в час?

В какую раз в неделю? Кеш чистится не раз в неделю, а при изменениях в БД.

 

25 минут назад, morgenshtern сказал:

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

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

 

25 минут назад, morgenshtern сказал:

Нужно создать отдельную вкладку с кэшем, где можно будет задать время жизни кеша для страниц fullstory, main, alltags итд

У кеша нет времени жизни, он всегда меняется по мере изменения информации в БД автоматически, а не по прошествии какого то времени.

[morgenshtern 5]

6 минут назад, celsoft сказал:

Так оно и есть.

Нет, не так и есть

showfull

        $config['fullcache_days'] = intval($config['fullcache_days']);
        
        if( $config['fullcache_days'] < 1 ) $config['fullcache_days'] = 30;
        if( strtotime($row['date']) >= ($_TIME - ($config['fullcache_days'] * 86400)) ) {
                
            $allow_full_cache = true;
            
        }

У всех старых новостей $allow_full_cache = false а значит до create_cachе не доходит

 

7 минут назад, celsoft сказал:

В какую раз в неделю? Кеш чистится не раз в неделю, а при изменениях в БД.

Раз в неделю написал в качестве примера. При любом изменении он полностью удаляется. Т.е. если новости будут создавать раз в минуту, то и чистится он будет раз в минуту. Какой тогда вообще прок от кэша?

function clear_cache($cache_areas = false) {
    global $mcache;
    if ( $mcache !== false ) {
        $mcache->flush();
    }
....

 

12 минуты назад, celsoft сказал:

У кеша нет времени жизни, он всегда меняется по мере изменения информации в БД автоматически

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

 

16 минут назад, celsoft сказал:

Мы ничего за вас не решили, никто не мешает вам поставить в этот параметр например 10000

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

[celsoft 6 082]

7 минут назад, morgenshtern сказал:

Раз в неделю написал в качестве примера. При любом изменении он полностью удаляется. Т.е. если новости будут создавать раз в минуту, то и чистится он будет раз в минуту. Какой тогда вообще прок от кэша?

Прок в том что на нормальном сайте не создают новости раз в минуту. Если у вас новости создаются раз в минуту, значит кеш вам нужно вообще отключать, для этого также есть соответствующая настройка.

 

8 минут назад, morgenshtern сказал:

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

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

 

13 минуты назад, morgenshtern сказал:

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

По вашему они не читают настройки и их суть?

[SKYNET74 315]

1 час назад, celsoft сказал:

У кеша нет времени жизни, он всегда меняется по мере изменения информации в БД автоматически, а не по прошествии какого то времени.

Есть, тот же крон убивает кеш...

1 час назад, celsoft сказал:

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

Это всё решается "продвинутым" кешировнием на базе мемкеша.
PS: Нужно бы сжатие данных в мемкеше отключить по дефолту, это позволяет в несколько раз быстрее генерировать страницы.

1 час назад, celsoft сказал:

По вашему они не читают настройки и их суть?

Как показывает практика, 95% пользователей не всегда более простые настройки понимают, не говоря уже о таких сложных штуковинах как время кеширования какого либо участка данных.
А если им рассказать про "продвинутое" кеширование на мемкеше, то у них вообще CPU сгорит, произведя знатный фейерверк...

[celsoft 6 082]

1 час назад, SKYNET74 сказал:

Есть, тот же крон убивает кеш...

Это не время жизни кеша. Кеш изначально не рассчитывается жить весь цикл между кронами. Задача кеша не жить вечно. Его задача условно говоря если в секунду например к сайту обратились 100 человек, то для одного человека задействовалась БД, а для всех остальных кеш. А если сайт не может обработать полностью одного человека, со всеми запросами, то это не проблема кеша, а проблема серверного ПО и его конфигурации.

 

1 час назад, SKYNET74 сказал:

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

У меня другая практика, никто кроме автора топика еще не понял эту настройку  как то неправильно, и ни разу не написал об этом. И это честный факт.

[SKYNET74 315]

1 час назад, celsoft сказал:

Это не время жизни кеша. Кеш изначально не рассчитывается жить весь цикл между кронами. Задача кеша не жить вечно. Его задача условно говоря если в секунду например к сайту обратились 100 человек, то для одного человека задействовалась БД, а для всех остальных кеш. А если сайт не может обработать полностью одного человека, со всеми запросами, то это не проблема кеша, а проблема серверного ПО и его конфигурации.

Я вкурсе что такое кеш и для чего он... У кеша так же есть КПД, но вот именно у DLE этот КПД очень низкий, возьмём даже то что поддержка мемкеша была сделана на "лишь бы отвалили", а не качественное внедрение с хотя бы тем же тегированием...

1 час назад, celsoft сказал:

У меня другая практика, никто кроме автора топика еще не понял эту настройку  как то неправильно, и ни разу не написал об этом. И это честный факт.

Конкретно это, частный случай.
Но выразился он верно, нужна более тонкая настройка, и не только кеша, но и выборки, и т.п., чего сейчас нет в DLE из-за его ориентации по принципу "что бы даже тупой разобрался", это огорчает тех кому нужны большее кастомные настройки.

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

[celsoft 6 082]

42 минуты назад, SKYNET74 сказал:

У кеша так же есть КПД, но вот именно у DLE этот КПД очень низкий

Это лишь ваше собственное мнение. Я с вами абсолютно не согласен, но переубеждать не буду. Пусть каждый остается при своем мнении.

 

42 минуты назад, SKYNET74 сказал:

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

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

 

Сортировка по ID может быть идентичной с датой только если не предоставляется возможность вообще поменять дату. Например так реализовано в DLE для комментариев, там сортировка по дате реализована именно по ID.

[SKYNET74 315]

49 минут назад, celsoft сказал:

Это лишь ваше собственное мнение. Я с вами абсолютно не согласен, но переубеждать не буду. Пусть каждый остается при своем мнении.

Очистка всего кеша (полных новостей, комментариев, похожих новостей и т.п.) при добавлении новости это разве эффективно?

51 минуту назад, celsoft сказал:

Сортировка по ID может быть идентичной с датой только если не предоставляется возможность вообще поменять дату. Например так реализовано в DLE для комментариев, там сортировка по дате реализована именно по ID.

А вы не думали что каким то проектам вообще не надо менять дату у новостей и что им эта лишняя нагрузка при сортировке по дате не нужна?
Дня большинства статейников, и других сайтов "одного человека" в большинстве случаев менять дату не требуется, и даже если её и менять, сортировка будет по ID, и раз человек её выбрал, ему именно это и нужно.
Нужно больше типов сортировки, тем более раз уже индексы есть по этим колонкам.
Это так, к слову о КПД и нагрузке было по ID.

[celsoft 6 082]

14 часа назад, SKYNET74 сказал:

Очистка всего кеша (полных новостей, комментариев, похожих новостей и т.п.) при добавлении новости это разве эффективно?

Добавление новости не чистит кеш полной новости, не чистит кеш комментариев, и лишь частично сбрасывает кеш похожих новостей. Откуда вы это взяли совершенно не понятно.

[SKYNET74 315]

10 часов назад, celsoft сказал:

Добавление новости не чистит кеш полной новости, не чистит кеш комментариев, и лишь частично сбрасывает кеш похожих новостей. Откуда вы это взяли совершенно не понятно.

Забыл добавить что это при использовании мемкеша.
Файловый кеш для меня как таковой мёртв изначально, т.к. это уже давно не эффективно и вообще прошлый век как минимум...

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

PS: Проводил тесты на чистеньком и свеженьком сервере на DDR4 с включённым сжатием, чем жирнее контент сохраняемый в мемкеш, тем жестче просидяет скорость записи/чтения, иногда до безобразия просидает.
PS2: $memcached->setOption(Memcached::OPT_COMPRESSION, false);

[celsoft 6 082]

16 часов назад, SKYNET74 сказал:

В идеале ещё бы увидеть сначала Memcached, а уже потом Memcache, а не наоборот. Ибо первый по всем тестам опережает второй, и умеет куда больше второго. Ибо первый по всем тестам опережает второй, и умеет куда больше второго.

Простите но это полная ерунда. Библиотека Memcached функциональней по функциям, но медленней по работе чем Memcache. И это гарантированый факт.

 

16 часов назад, SKYNET74 сказал:

Сжатие сохраняемых данных тоже бы по дефолту выключить, толку особо нет, но вот на скорость записи/чтения существенно влияет это.

Это да имеет смысл, если большой контент одновременно добавляется.

[SKYNET74 315]

1 час назад, celsoft сказал:

Простите но это полная ерунда. Библиотека Memcached функциональней по функциям, но медленней по работе чем Memcache. И это гарантированый факт.

Я просто оставлю это тут... (с)

 

Видимо этим руководствовались: http://thehighload.com/index.php/2010/05/07/memcache-vs-memached-сравниваем-клиенты-для-php/
Однако там внезу есть интересное примечание, которое ставит вообще под сомнение эту информации...

А это так, к слову:
https://www.leaseweb.com/labs/2013/03/memcache-vs-memcached-php-benchmark/
https://anton.logvinenko.name/ru/blog/redis-vs-memcache-vs-memcached.html
PS: Мои результаты тоже говорят в пользу Memcached...

1 час назад, celsoft сказал:

Это да имеет смысл, если большой контент одновременно добавляется.

т.е. в следующей версии DLE увидим отключение?

 

Изменено 8 февраля 2017 пользователем SKYNET74

[celsoft 6 082]

31 минуту назад, SKYNET74 сказал:

Видимо этим руководствовались

Нет.

 

35 минут назад, SKYNET74 сказал:

А это так, к слову:
https://www.leaseweb.com/labs/2013/03/memcache-vs-memcached-php-benchmark/
https://anton.logvinenko.name/ru/blog/redis-vs-memcache-vs-memcached.html
PS: Мои результаты тоже говорят в пользу Memcached...

Принципы по которым изначально проведены эти тесты изначально не корректны. Тот кто занимается тестированием сразу поймет почему. Например запись данных одной длины, и нет анализа разных версий PHP.

 

40 минут назад, SKYNET74 сказал:

т.е. в следующей версии DLE увидим отключение?

Незнаю, нужно проводить тестирование и изучать расход памяти, сопоставлять с тем что доступно на большинстве хостингов и тарифах. Мы не делаем ничего просто так и не подумав. Потому как делаем скрипт для большинства пользователей, а не для одного конкретного. И у нас много лимитов и ограничений, о которых вы даже не думали. Если тесты покажут приемлемость этого изменения, то да отключим.

[SKYNET74 315]

22 минуты назад, celsoft сказал:

Принципы по которым изначально проведены эти тесты изначально не корректны. Тот кто занимается тестированием сразу поймет почему. Например запись данных одной длины, и нет анализа разных версий PHP.

У меня скрипт более "богатый" на тесты сделан был, и там писалось от нескольких символов, и заканчивая "войной и миром", результат тот же.
На Debian 8 + PHP-FPM + Memcached 1G: Memcached был ощутимо быстрее Memcache.

[php84@bk.ru 0]

Добрый день, перешел на VPS с php 7 но там нет memcache  но есть  memcached

Подскажите ктонибуть модифицировал DLE на работу с memcached

[celsoft 6 082]

15 часов назад, php84@bk.ru сказал:

Добрый день, перешел на VPS с php 7 но там нет memcache  но есть  memcached

Подскажите ктонибуть модифицировал DLE на работу с memcached

DLE актуальных версий поддерживает обе библиотеки автоматически из коробки.