Оптимизация DLE для DLE

Оптимизация DLE

Оптимизация DLE

Периодически у меня появлялось желание как-то оптимизировать DLE в плане программной части. Но все никак руки не доходили или желания не было.
Хочу немного поделиться своими решениями в плане оптимизации запросов к БД в DLE.
UPD [2020-12-01]: Добавлен пункт 6
UPD [2021-02-13]: Добавлен пункт 7

Не так давно проводил ряд работ по оптимизации сайта. Монитор нагрузки показывал загрузку процессора на 70-90%. Тут и top не нужно смотреть, чтобы понять что проблема в mysql.
Специально для этой задачи был написан относительно простенький модуль, который вел лог всех запросов в бд и записывал статистику. На скриншотах ниже - результат сбора статистики за один вечер, время 20:40 - 22:20.
Вот по результатам этих данных (и не только) проведем небольшой анализ и постараемся оптимизировать по максимуму.
Внимание: Если у вас DLE 13.x, то вместо ручного внесения изменений вам нужно использовать утилиту управления плагинами, как ею пользоваться описано в инструкции.


1. Общие рекомендации
В самую первую очередь строго обязательно рекомендуется отключить функцию "Поддержка публикации новостей на еще не наступившую дату". Этот параметр очень много дает.
Если вы не используете и не планируете использовать функционал "фиксации новостей", то я так же настоятельно рекомендую его отключить. В некоторых ситуациях это даст ощутимый прирост производительности.
Так же рекомендую отключить все другие не используемые модули, типа topnews, календарь, RSS информер и т.п.
Отдельно хочу обратить внимание на RSS информер. По умолчанию он включен и так же по умолчанию уже есть созданный и включенный информер яндекс новостей. Это следует знать и лучше его отключать или удалять.
UPD: Решил просто привести наглядный пример. Чистая DLE 14.0. В БД 50к записей.
[query] => SELECT ... FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 AND allow_main=1 AND date < '2020-05-07 12:08:02' ORDER BY fixed desc, date DESC LIMIT 0,10
[time] => 0,52297616004944
[num] => 3
[query] => SELECT COUNT(*) as count FROM dle_post WHERE approve=1 AND allow_main=1 AND date < '2020-05-07 12:08:02'
[time] => 0,65341997146606
[num] => 4

А теперь отключаем "Поддержка публикации новостей на еще не наступившую дату"
[query] => SELECT ... FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 AND allow_main=1 ORDER BY fixed desc, date DESC LIMIT 0,10
[time] => 0,0053451061248779
[num] => 3
[query] => SELECT COUNT(*) as count FROM dle_post WHERE approve=1 AND allow_main=1
[time] => 0,00032711029052734
[num] => 4

Думаю не стоит говорить на сколько существенна разница во времени.


2. not detected
Не актуально для DLE 13.3 и старше
Оптимизация DLE

Думаю тут все и так ясно, за исключением последней колонки GC (group count). Это количество - сколько раз выполнялся этот запрос.
Данные запросы появляются при обращении к не существующим категориям. В принципе не критично, но блин, зачем выполнять 2 запроса если априори известно, что в результате ничего не будет и быть не должно.
Решение:
Открыть файл engine/modules/show.short.php
Найти строку:
if( $allow_active_news ) {

Выше нее вставить:
if ($do == 'cat' && !(int)$category_id) {
	$allow_active_news = false;
}



3. SELECT COUNT(*) as count FROM dle_post
Оптимизация DLE

Просто посмотрите на эти числа, а главное количество этих запросов. Разумеется кеширование включено, но...
Вот еще мне человек писал, цитата от хостера:
При проверке, мы видим, что в момент обновления указанной Вами ссылки, в базу данных поступает запрос вида:
SELECT COUNT(*) as count FROM dle_post WHERE category regexp '[[:<:]](702|703|704|706|707|709|710|711|712|713|714|715|716|717|718|719|720|721|723|724|725|726|729|730|731|732|733|734|735|737|738|739|740|741)[[:>:]]' AND approve=1;

При ручном выполнении данного запроса, мы и вправду наблюдаем затрату времени 2.70 sec

Решение:
Если у вас DLE 11.1 или младше, то потребуется установить хак Количество новостей в категории
Для более старших версий - в настройках необходимо включить параметр "Осуществлять подсчет количества новостей в категориях"
Открыть файл engine/modules/show.short.php
Найти строку (первую):
		$count_all = $db->super_query( $sql_count );

Выше нее вставить:
		if ($do == 'cat' && isset($cat_info[(int)$category_id]['newscount'])) {
			$count_all = array(
				'count' => (int)$cat_info[$category_id]['newscount']
			);
		} else 

Данный хак полностью исключит вышеуказанные проблемные запросы. Но именно только для категорий. Хотя по сути в категориях-то как раз и выполняется наибольшее количество подобных запросов.


4. Мысли по п.3
Запросы мы убрали, все хорошо. Но вот вопрос, почему этих запросов так много при включенном кешировании.
Тут немножко дело зависит от версии DLE. К примеру в версии 10.6 и младше кешировались только первые 5 страниц навигации, остальные вообще без кеша. Затем это число было увеличено до 10 страниц, так продолжалось вплоть до 11.2. И уже начиная с 11.3 и до актуальной версии это число можно вручную указывать в настройках - "Количество страниц сайта, которое необходимо кешировать при показе кратких публикаций".
Это правильный шаг, но пользоваться этим параметром нужно тоже с умом. Если у вас к примеру 10-20 категорий, то можно кешировать и 20-30 страниц, получится 200 - 600 файлов кеша, что вполне приемлемо.
Но если у вас много категорий, то количество кешируемых страниц оптимально как раз около 10.

Немного отвлекся от основной темы данного раздела, а именно почему этих запросов так много? И ответ достаточно прост - кеширование. А именно очистка кеша. Добавление нового комментария, оценка в рейтинге - оба эти действия полностью сносят кеш всех страниц с отображением короткой новости и блоков custom. Не слабо так, один лайк и кеш обнулен.
Многое зависит от сайта и желаний владельца сайта - нужно ли вам, чтобы каждое действие тут же было видно в короткой новости или может в короткой новости вообще не отображается ни рейтинг ни количество комментариев. Так что я просто приведу инструкцию, а вносить эти правки или нет - уже решать вам.
Открыть файл engine/modules/addcomments.php
Найти строку:
clear_cache( array( 'news_', 'comm_'.$post_id, $cprefix ) );

или
clear_cache( array( 'news_', 'rss', 'comm_'.$post_id, $cprefix ) );

Заменить на:
clear_cache( array( 'comm_'.$post_id, $cprefix ) );

Таким образом, при добавлении комментария будет очищен только кеш текущей новости и сами комментарии.

Открыть файл engine/ajax/rating.php
Найти строку (2шт):
clear_cache( array( 'news_', $cprefix ) );

или
clear_cache( array( 'news_', 'rss', $cprefix ) );

Заменить на:
clear_cache( array( $cprefix ) );

Теперь при выставлении оценки в рейтинге новости будет очищен только кеш самой новости.


5. order="RAND()"
RAND() - зло.
Но если вам очень уж хочется использовать эту сортировку, но я приведу простую аналогию.
К примеру новости - это стальные шарики весом 10г каждый. У вас есть 100 шариков и вы хотите выбрать из них 10 случайных.
Засыпаете их в ведро и колотите пока не выпадут 10шт. Это не сложно, всего-то 1кг шариков + вес ведра.
Теперь у вас 2000 шариков (новостей), вы хотите так же выбрать из них 10 случайных. Повторяем процедуру, только теперь уже нужно активно и быстро месить 20кг, что не так-то и просто, но пока вполне реально.
И совсем уж для понимания, когда в среднем на том же киносайте порядка 30тыс новостей, получается что месить уже нужно 300 кг. Думаю суть ясна.
Но чтобы закрепить понимание, добавим 100 посетителей, когда каждый заходит раз в 1 секунду и просит из 10кг шариков выбрать один любой. И причем каждый посетитель хочет свой уникальный шарик (типа без кеша). В один прекрасный момент наш работяга метусильник (mysql) пошлет все в ж**пу и пойдет на перекур (Server has gone away). И возможно сам не захочет возвращаться.
Если уж хотите использовать rand - делайте это с умом. Либо не заставляйте его каждую секунду метусить 300кг (кеширование результатов выборки, тут кстати может помочь Ручной кеш), либо пусть месит до 1кг (ограничить изначальную выборку, по дате или другим параметрам, чтобы итоговое максимальное количество новостей было небольшим). А еще лучше комбинировать оба метода.

6. Оптимизация запросов SELECT count(*) на страницах новостей


Этот раздел можно считать продолжением п.3. Но это решение немного более продвинутое и функциональное.
Полагаю, что многие сталкивались с такой проблемой, что запрос count(*) обрабатывается довольно таки продолжительное время.
[query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('1') AND approve=1
[time] => 0,28818893432617

Выше я уже предлагал одно из решений этой проблемы. Но у него есть свои минусы:
- работает только на страницах категорий;
- необходимо чтобы был включен счетчик новостей в категориях.
Оба эти недостатка решены в этой реализации.

Суть проблемы в том, что на каждой странице /page/1/ - page/N/ повторно выполняется один и тот же запрос, который на каждой странице отдает один и тот же результат.
Данный хак запоминает этот результат и сохраняет его в кеше. В результате чего, не зависимо от количества страниц, запрос на получение количества новостей в разделе будет выполняться только один раз.
UPD: Если используется отложенная публикация (на не наступившую дату), то этот плагин лучше не использовать.

7. Использование {include file='...'} для PHP файлов


Данный раздел скорее можно отнести к категории "микрооптимизации". Однако это не отменяет того факта, что есть что улучшить.
Как показала практика, одно подключение элементарнейшего php файла (даже пустого) в шаблоне - по времени занимает порядка 0.005 секунд.
И это, скажу я вам, достаточно много. Один такой файл особо не сыграет роли (относительно), но если их используется хотя бы 10 шт или он подключается в shortstory.tpl и выводится скажем 30-60 раз. Уже имеем 0.005 * 30 = 0.15с (150-300мс) и это безусловно очень много.
Важное замечание. Речь идет не о времени формирования страницы (или TTFB), а именно о времени которое занимает только DLE.
Причины
Чтобы разобраться в данной проблеме, достаточно изучить файл engine/classes/templates.class.php
Доходим до места подключения php файла и видим строку:
$tpl = new dle_template();

Получается не важно, что находится внутри подключаемого php файла - для него всегда будет создаваться свой экземпляр класса шаблоназитора.
Посмотрев в конструктор класса, мы видим, что там так же создается новый экземпляр класса mobiledetect и соответственно выполняется определение устройства пользователя. Вот именно на это бесполезное действие и тратятся те злополучные 5мс.
Решение
Решение, на самом деле, достаточно простое и на мой взгляд - очевидное.
Мы не будет создавать новый экземпляр класса, просто создадим копию текущего и обнулим значения переменных.
Для этого нужно найти строки:
			$tpl = new dle_template();
			$tpl->dir = TEMPLATE_DIR;

И заменить их на:
			$tpl = clone $this;
			$tpl->template = $tpl->copy_template = '';
			$tpl->block_data = $tpl->data = $tpl->result = [];


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


На этом, пожалуй, пока все. Спасибо что дочитали до конца (если это так :)), буду рад вашим комментариям и предложениям.

С уважением,
Олег Александрович a.k.a. Sander
Комментарии: (67)
  1. foto
    VIP 4 июля 2018 22:00 #
    Применимо ко всем версиям?
    0
    1. foto
      Администратор 4 июля 2018 22:02 #
      На 10.1 проверял, для более ранних не проверял. Возможно и подойдет.
      0
      1. foto
        VIP 4 июля 2018 22:23 #
        На сколько снизилась нагрузка у Вас после всех манипуляций?
        0
        1. foto
          Администратор 4 июля 2018 22:34 #
          Нельзя сказать однозначно.
          Там было несколько однотипных сайтов и реальную проблемную нагрузку создавал запрос от страниц поиска по доп.полям - /xfsearch/... (актеры, режиссеры и т.п)
          Там использовался старый алгоритм, где поиск выполнялся по xfields LIKE '%слово%' который собственно и создавал огромную нагрузку. Страниц нереально много и наличие кеша не играло вообще никакой роли.

          Вы можете легко попробовать у себя и провести замеры. Все эти изменения не являются необратимыми.
          0
  2. foto
    Гость 5 июля 2018 15:24 #
    Доброе время. А можно подогнать модуль и инструкцию для модуля Custom-Cache для DLE 13. А то после установки модуля, блок вообще перестаёт кешироваться и обновляется при каждой перезагрузке страницы. Пробовали ставить и через модули и через правку файлов, ни один вариант не работает, всё делал строго по инструкции, блок так и обновляется постоянно.
    0
    1. foto
      Администратор 5 июля 2018 15:28 #
      1. Почему вы задаете этот вопрос здесь, а не в теме модуля
      2. Техподдержка только по указанным контактам.

      PS. В dle 13 необходимо вносить правки только посредством утилиты управления плагинами.
      0
  3. foto
    Гость 10 июля 2018 05:10 #
    Есть один нюанс на DLE 12, в show.short.php вы указали найти строчку и выше вставить нужный код
    $count_all = $db->super_query( $sql_count );

    у меня нашло 2 такие строчки, выше которой ставить?

    Сам код выглядит так
    
    		$count_all = $db->super_query( $sql_count );
    		if($news_found AND !$count_all['count']) {
    			$db->query("ANALYZE TABLE `" . PREFIX . "_post`, `" . PREFIX . "_post_extras`");
    			$count_all = $db->super_query( $sql_count );
    		}
    
    0
    1. foto
      Администратор 10 июля 2018 11:08 #
      Перед первой
      0
  4. foto
    VIP 14 июля 2018 20:04 #
    Sander, указанные правки будут все работать, если их оформить через плагины? ))
    0
    1. foto
      Администратор 14 июля 2018 20:05 #
      Да, конечно.
      Разве что для п3. нужно будет в поле "Найти" вставить не одну строку, а сразу 2:
      		$count_all = $db->super_query( $sql_count );
      		
      		if($news_found AND !$count_all['count']) {

      И уже перед этим кодом вставлять.
      +1
      1. foto
        VIP 14 июля 2018 20:39 #
        Спасибо, проверю.
        +1
  5. foto
    Гость 28 августа 2018 19:38 #
    Если выполнить пункт 3 (SELECT COUNT(*) as count FROM dle_post) на DLE 13, то почему-то пропадают ссылки на страницы пагинации в категории.
    0
    1. foto
      Гость 28 августа 2018 19:52 #
      Удалите этот коммент - все заработало)))
      0
  6. foto
    VIP 29 сентября 2018 14:55 #
    Для Dle 13.1 актуальны все правки? Или там уже исправили некоторые?
    -2
    1. foto
      Администратор 30 сентября 2018 15:02 #
      Вам следует задать этот вопрос тому, кто занимается разработкой DLE 13.1
      Я эту версию еще в глаза не видел.
      +1
      1. foto
        Гость 30 сентября 2018 15:17 #
        А если взять к примеру 13.0?
        +1
        1. foto
          Администратор 30 сентября 2018 21:45 #
          Для DLE 13.0 актуальны все пункты.
          +1
  7. foto
    VIP 14 октября 2018 05:01 #
    Sander, что можете сейчас сказать по поводу актуальности правок на Dle 13.1.
    Также возможно вы владеете неплохими знаниями, хотел спросить у вас - в целом, с каждой новой версией DLE ситуацию в плане оптимизации исправляют?
    Про их код и гибкость я в курсе, что это полное безобразие, а вот по поводу скорости работы и оптимизации было бы интересно что-то от вас услышать.
    +1
    1. foto
      Администратор 20 октября 2018 01:14 #
      Актуальны все пункты.

      По оптимизации не могу ничего однозначно сказать. В основном только добавляется функционал. Хотя скорее всего я просто не обращал внимания.
      Из того, что сразу пришло в голову - это создание таблицы dle_xfsearch для ускорения поиска по доп.полям.

      Но в целом хочу заметить, нельзя сказать, что DLE плох в плане оптимизации.
      Да, есть места, которые не плохо бы проработать, но зачастую они индивидуальны.
      0
  8. foto
    VIP 7 ноября 2018 20:00 #
    А скажите, при каждом заходе в категорию или её страницу /page/ DLE делает вот такой запрос к БД: ANALYZE TABLE `dle_post`, `dle_post_extras`
    Толком ничего нагуглить не удалось, чем чревато выпиливание этого "затяжного" запроса? Таблицы у меня в innodb.
    0
    1. foto
      Администратор 7 ноября 2018 21:38 #
      Если делает постоянно, то вам определенно необходимо что-то настраивать в сервере. Или какие-то модули/хаки в самом DLE.
      Данный запрос выполняется только в случае несоответствия. Т.е. в контенте новости есть, а запрос о количестве новостей говорит - что новостей нет.
      0
      1. foto
        VIP 8 ноября 2018 00:08 #
        Действительно, выпиливал ненужные запросы для подсчета новостей и отсюда пошли расхождения. Все нашел, все починил, спасибо.
        0
  9. foto
    VIP 8 ноября 2018 16:41 #
    <offtop>
    Давненько ничего нового не появлялось на сайте. Пора встряхнуть сообщество? ;)
    </offtop>
    +3
    1. foto
      Администратор 9 ноября 2018 18:25 #
      Только недавно освободился.
      Сейчас есть одна перспективная идейка, работаю над ней.
      +4
      1. foto
        VIP 18 ноября 2018 14:06 #
        Намекните хоть для интриги какой направленности?!
        Может я зря ТЗ сейчас вымучиваю )))
        0
        1. foto
          Администратор 18 ноября 2018 14:42 #
          Оптимизированный быстрый поиск.
          http://kino.sandev.pro/
          0
          1. foto
            VIP 18 ноября 2018 17:48 #
            confused Довольно специфичная штука
            +1
  10. foto
    Клиент 12 ноября 2018 13:16 #
    У меня вопрос про 5 пункт файл engine/ajax/rating.php. Что это даст? Страницы сайта будут загружаться быстрее?
    0
    1. foto
      Администратор 14 ноября 2018 13:40 #
      Не могу сказать, даст ли это что-то. Зависит от многих фактров.
      Может снизит нагрузку на процессор на 1-5%, а может и на все 50%.
      А может у вас вообще сайт на котором 500 статей и посещалка 100 уников в сутки, тогда это вообще ничего не даст.
      0
  11. foto
    Посетитель 26 ноября 2018 06:12 #
    У меня за раз 5910 запросов в БД проскачило xD это норма?
    -1
    1. foto
      Администратор 27 ноября 2018 00:42 #
      Это крон движка. Он выполняется каждые 2 часа. У вас вероятнее всего включен кеш счетчика просмотров.
      Если это так, то такое количество запросов - норма. Но норма только если выполняется раз в 2 часа, а не постоянно.
      В противном случае просто удалите все php файлы в папке engine/cache/system (у самой папки должны быть права 777)
      0
  12. foto
    Посетитель 1 февраля 2019 19:15 #
    У меня с сайтом так все в порядке пока что, у меня Dle 10, но сделал все эти действия которые ты написал, хуже же не будет правильно?
    0
    1. foto
      Администратор 2 февраля 2019 13:29 #
      Хуже - однозначно не будет.
      Единственный нюанс - п.4, он возможно не для всех подойдет. Но в любом случае ничего непоправимо страшного от этого не будет.
      0
  13. foto
    Посетитель 6 февраля 2019 11:06 #
    Ну я сделал по п4. все нашлось все прописал ошибок не возникало..
    0
  14. foto
    Клиент 6 марта 2019 10:07 #
    Актуальны ли данные действия для DLE 13.2?
    0
    1. foto
      Администратор 6 марта 2019 11:31 #
      Да.
      +1
      1. foto
        Гость 6 мая 2019 18:34 #
        Добрый день. Это актуально только для файлового кеша, ведь в мемкеше есть префикс нужно ли это ставить если на сайте не файловый кеш а мемкеш
        0
        1. foto
          Посетитель 7 мая 2019 07:52 #
          Да интересно, не повредит ли установка пунктов особенно 3-4 при выборе кеширования memcached
          0
          1. foto
            Администратор 9 мая 2019 15:05 #
            Без разницы какой кеш используется.
            Суть не в месте хранения кеша, а в работе с ним.
            0
  15. foto
    Гость 2 июля 2019 15:38 #
    А как тоже сделать лог всех запросов в бд как у вас?
    0
    1. foto
      Администратор 2 июля 2019 15:47 #
      Это экспериментальный образец не вышедший в свет по ряду причин.
      0
  16. foto
    VIP 5 октября 2019 16:21 #
    Добрый день! Для версии 13.3 актуально ???
    0
    1. foto
      Администратор 6 октября 2019 18:51 #
      Частично да, частично не знаю.
      0
      1. foto
        Посетитель 15 октября 2019 22:20 #
        Скажите пожалуйста, а как можно убрать обнуление кэша при модерации комментариев в админке?

        Очень сильно раздражает это, так как на сайт каждый час публикуются примерно по 100 комментов. При одобрении каждого коммента, весь кэш сносится к чертям. Таким образом в моем случае кэширование перестает вообще иметь смысл. Подскажите пожалуйста куда копать хоть?
        0
        1. foto
          Администратор 15 октября 2019 22:33 #
          engine/inc/cmoderation.php
          Функция clear_cache();
          0
          1. foto
            Посетитель 15 октября 2019 22:52 #
            Да к сожалению мало что понял там, думал будет так же просто как и с engine/modules/addcomments.php
            clear_cache( array( 'news_', 'comm_'.$post_id, $cprefix ) );


            Но там похожего кода и в помине нету)
            0
  17. foto
    VIP 11 ноября 2019 02:47 #
    Какие пункты наверняка не актуальны для DLE 13.3?
    +1
    1. foto
      Администратор 14 ноября 2019 14:27 #
      п.2 исправлен.
      Остальное актуально.
      Со временем возможно будет что-то сделано и касательно 3го пункта.
      Так же возможно для п.4. будет добавлена настройка в админке.
      1 и 5 - это больше рекомендации и они будут актуальными всегда.
      +1
      1. foto
        Клиент 21 ноября 2019 08:41 #
        А почему п2 стал не актуален?
        Разрабы сами исправили эту проблему?
        0
      2. foto
        Клиент 14 февраля 2020 13:03 #
        А не подскажите относительно 14-й версии?
        +1
  18. foto
    VIP 21 февраля 2020 14:56 #
    Также интересна информация касательно 14-й версии DLE.
    0
    1. foto
      Администратор 21 февраля 2020 15:03 #
      п.2 исправлен.
      Остальное актуально.
      Со временем возможно будет что-то сделано и касательно 3го пункта.
      Так же возможно для п.4. будет добавлена настройка в админке.
      1 и 5 - это больше рекомендации и они будут актуальными всегда.
      0
  19. foto
    Посетитель 25 марта 2020 13:14 #
    Добрый день, не подскажите такое актуально в современных версиях dle.
    https://habr.com/ru/post/217521/
    0
    1. foto
      Администратор 25 марта 2020 20:24 #
      Если вопрос касается самого факта долгой работы с LIMIT на больших базах, то да.
      Если говорить о целесообразности этих правок, то нет.
      0
  20. foto
    Посетитель 20 октября 2020 00:23 #
    Подскажите если грузить библиотеки jquary и другие с серверов гугл или яндекса нагрузка снизится? Не планируете выпустить хак менять порядок загрузки jquary с сайта или гугл, а также другие библиотеки.
    0
    1. foto
      Администратор 20 октября 2020 17:12 #
      Нет, не снизится.
      Нет, не планирую.
      0
  21. foto
    Гость 29 октября 2020 23:05 #
    А лайк в комментарии сбрасывает кеш на всем сайте? Если да то где это подправить.dle14.1
    0
    1. foto
      Администратор 29 октября 2020 23:19 #
      Нет, там чистится только кеш всех комментариев.
      Там важность кеша не столь существенна, поэтому можно ничего не делать.
      0
  22. foto
    Клиент 5 декабря 2020 10:05 #
    Зачем подняли новость? Что нового добавили? Что-то не смог найти сам.
    0
    1. foto
      Администратор 5 декабря 2020 12:35 #
      п.6
      0
  23. foto
    Клиент 15 февраля 2021 12:12 #
    Подскажите, правильно ли я понимаю, что вместо 3 пункта лучше использовать 6? Или надо оба использовать?
    0
    1. foto
      Администратор 15 февраля 2021 13:08 #
      Верно.
      п.3 работает только на страницах категорий и требует (относительно затратной) включенной функции подсчета новостей в категориях.
      В п.6 я считаю более удачное решение.

      PS. Оба использовать не получится.
      0
      1. foto
        Клиент 15 февраля 2021 15:01 #
        Понял, спасибо за ответ.
        Установил себе 6 и 7 пункт, не особо разбираюсь конечно, но сайт как будто бы чуть чуть быстрее стал грузиться :)
        0
      2. foto
        VIP 16 февраля 2021 17:49 #
        Тоесть если использовать пункт 6, то подсчёт новостей из категорий лучше выключить?
        0
        1. foto
          Администратор 16 февраля 2021 18:02 #
          Не совсем верно.
          Для п.3 было необходимо, чтобы подсчет был включен.
          Для п.6 функционал подсчета новостей не используется, поэтому его можно выключить если он не используется.

          Резюмируя вышесказанное можно сказать, что если используется п.6 и в шаблоне не выводится количество новостей, то да, подсчет лучше отключить.
          +2
  24. foto
    VIP 15 апреля 2021 23:21 #
    Скажите какие пункты актуальны для версии 14.2 ???
    +1
    1. foto
      Администратор Сегодня, 00:47 #
      Полагаю, что все.
      0
Добавить комментарий

Внимание! Все сообщения касающиеся техподдержки будут удалены или проигнорированы

Attention! All messages asking for technical support will be removed or ignored

  • Логин
  • E-mail (не обязательно)
Повторите рисунок:
antibot
© Sander-Development. 2009-2021.
При копировании, ссылка на источник обязательна.