Sander1

Обновление - v.1.1 Добавлен раздел с отображением структуры папок сайта и их размеров.

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

Да, точно. Прошу прощения, то видимо я что-то запутался. Сбило с толку, что при разных типах кеширования один и тот же код в одинаковой ситуации возвращает NULL и string('')

Если по заданным критериям не найдено никаких комментариев и используется memcache, то кеширование не будет работать, поскольку метод: $content = $comments->build_customcomments( $tpl, $custom_template.'.tpl' ); Ничего не возвращает, т.е. имеем $content = NULL И в мемкеш так же записывается значение NULL И следовательно проверка кеша уже недействительна. if( $content !== false ) {

С помощью данного модуля можно организовать разделение страницы полной новости на вкладки с отдельными URL адресами. Для каждой вкладки создается своя отдельная URL страница со своим шаблоном. Панель навигации подключается автоматически, но так же можно подключить ее вручную в любом месте сайта. Внешний вид панели можно оформить в любом стиле. Единственное что необходимо - это наличие знаний html+css. Админка:

Данный модуль предназначен для легкого и удобного управления всеми custom блоками на вашем сайте. Но главной и ключевой его особенностью является полноценная, удобная и безопасная организация AJAX навигации в custom блоке. Админка: Виды навигации: В модуле поддерживается 5 типов навигации (и без навигации). Стандартная, цифры и кнопки Вперед-Назад. Только цифры Только кнопки Вперед-Назад Показать еще lazyLoad - автоподгрузка по мере прокрутки контента.

Новая версия модуля - дополнения для тега custom, который позволяет организовать вывод реально популярных материалов исходя из значений текущих просмотров. Как известно, в DLE есть возможность вывод "популярных" новостей. Это можно сделать через тег {topnews} или посредством {custom order="reads" days="30"} Но в обоих случаях будет выведен топ популярных материалов основываясь на дате публикации. Т.е. если новость была опубликована более месяца назад, но по сей день пользуется популярностью, то вышеуказанные методы такую новость не будут показывать в ТОП-е.

У меня - нулевая посещаемость, это тестовые сайты. На хостинге и на локалке.

Не знаю. Может и есть, не сомневаюсь в этом. Но про такие числа и не идет речь. Все тестирования я провожу на вполне реальных сайтах с количеством публикаций 50-100к Сайт кинотематики 61к новостей: 44к фильмов, 10к сериалов, 6к мультиков. Сайт с играми 94к.

Я не могу сказать точно в процентном соотношении, но полагаю что бОльшая часть часть сайтов не использует этот функционал. Но он включен в движке по умолчанию. Поэтому я и рекомендую его отключать. Кто знает, что это такое, тот оставит включенным. Кто нет - лучше выключить. К тому же то, как сейчас реализована отложенная публикация - это лишь один из вариантов. Который тоже не без недостатков. Пока кеш новостей не будет очищен - новость не будет отображаться в общей ленте на сайте. Другое дело, что кеш чистится довольно таки часто, в зависимости от активности пользователя (выставл

Мой хак хранит кеш всех результатов запросов в одном файле с именем news_select-count.tmp. Добавление или удаление новости удаляет все файлы кеша с префиксом news_. В том числе мой файл кеша так же будет удален и создан заново с новыми, правильными значениями. "Отложенная публикация" - это как раз то, что я у себя в статье рекомендую отключать в первую очередь. Вот примеры запросов: В разделе 110к новостей [query] => SELECT COUNT(*) as count FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('2')) c ON (p

Вновь подниму вопрос касательно оптимизации. Как известно, на средних и больших БД, запрос вида: SELECT count(*) as count_all FROM dle_post WHERE {...} Порой занимает довольно продолжительное время. И чем больше новостей в разделе, тем дольше запрос. И получается, что на всех (!!) страницах где есть навигация: /page/2/, /page/3/, /page/4/, /page/5000 Будет повторно выполняться один и тот же медленный запрос, который всегда будет отдавать один и тот же результат. Таким образом, в результате сканирования всех 5000 страниц, будет выполнено минимум 10000 запросов. Хотя могло

Локалка: Версия PHP: 7.3.17 Версия MySQL: 8.0.19 Часть 1. Пустые записи, 88к штук. InnoDB. Размер таблиц: dle_post = 37.7Мб dle_post_extras = 14.6Мб Результаты замеров плюс минус пол секунды, но в основном такие: dle_post_extras - 9.067 sec dle_post - 9.268 sec Часть 2. Новости частично заполнены, 89к записей, InnoDB. dle_post = 4.8 ГиБ dle_post_extras = 15.6 МБ dle_post_extras - 8.922 sec dle_post - 16.041 sec Часть 2.1 Эти же данные, но на MyISAM dle_post_extras - 1.361 sec dle_post - 1.994

Мне нет смысла выдумывать. Операционная система: Linux 3.10.0-1062.18.1.el7.x86_64 Версия PHP: 7.2.29 Версия MySQL: 5.5.5-10.0.38-MariaDB dle_post 60,703 MyISAM utf8mb4_general_ci 201.5 МБ dle_post_extras 60,703 MyISAM utf8mb4_general_ci 7.6 МБ Обычный кино-сайтец, где-то одно предложение в short_story, где-то абзац, где-то вообще нету. Поле xfields заполнено везде, примерно по 500 символов в каждом. <?php error_reporting(E_ALL ^ E_NOTICE); defi

Вот, провел небольшой тест: $ids = range(10000, 60000); shuffle($ids); $mt = microtime(true); for ($i = 0; $i < 10000; $i++) { $id = array_pop($ids); //$db->query('UPDATE dle_post SET views = views + 1 WHERE id = ' . $id); $db->query('UPDATE dle_post_extras SET news_read = news_read + 1 WHERE news_id = ' . $id); } echo microtime(true) - $mt; Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов. Но ведь к тому же есть кеширование счетчика просмотров. Сохранение оценки в рейтинге выполняется достаточно редко, уж точно не 10к оценок в секунду, поэтому полагаю им