Sander1
-
Публикации
119 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
20
Сообщения, опубликованные пользователем Sander1
-
-
Проблема во всех версиях до DLE 15.3 включительно.
$custom_cache_id = "customcomments".$param_str.$config['skin'];
Кеш проверятся с использованием значения вышеуказанной переменной.
$content = dle_cache( "news", "customcomments".$custom_cache_id, true );
Т.е. значение получается "customcommentscustomcomments параметры"
А создается кеш с другим именем:
if ( $config['allow_cache'] ) create_cache( "news", $content, "customcomments".$param_str.$config['skin'], true );
Т.е. тут значение получается "customcomments параметры"
-
Обновление - v.1.1
Добавлен раздел с отображением структуры папок сайта и их размеров.
-
Основная цель этого модуля - это помощь в поиске проблемных мест и анализе общей производительности сайта.
Модуль собирает всю подробную информация по всем медленным запросам.
Затем в админке можно увидеть общую картину, какие разделы дольше всего обрабатываются, какие запросы в БД наиболее частые и наиболее медленные, какие проблемные файлы шаблонов и многое другое.Как показывает практика, поиск проблемы занимает гораздо больше времени и усилий, чем её решение.
С помощью данного модуля, можно легко узнать и увидеть всё, что происходит в движке на различных этапах его работы.
ЦитатаСтраница модуля: Highload by Sander
Цена: $17На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме
-
Да, точно.
Прошу прощения, то видимо я что-то запутался.Сбило с толку, что при разных типах кеширования один и тот же код в одинаковой ситуации возвращает NULL и string('')
-
Если по заданным критериям не найдено никаких комментариев и используется memcache, то кеширование не будет работать, поскольку метод:
$content = $comments->build_customcomments( $tpl, $custom_template.'.tpl' );Ничего не возвращает, т.е. имеем $content = NULL
И в мемкеш так же записывается значение NULLИ следовательно проверка кеша уже недействительна.
if( $content !== false ) { -
С помощью данного модуля можно организовать разделение страницы полной новости на вкладки с отдельными URL адресами.
Для каждой вкладки создается своя отдельная URL страница со своим шаблоном.
Панель навигации подключается автоматически, но так же можно подключить ее вручную в любом месте сайта.
Внешний вид панели можно оформить в любом стиле. Единственное что необходимо - это наличие знаний html+css.
Админка:
ЦитатаСтраница модуля: Fullpage-Tabs by Sander
Демо: Довод / Tenet (2020)
Цена: $8На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме
-
1
-
-
Данный модуль предназначен для легкого и удобного управления всеми custom блоками на вашем сайте.
Но главной и ключевой его особенностью является полноценная, удобная и безопасная организация AJAX навигации в custom блоке.Админка:
Виды навигации:
В модуле поддерживается 5 типов навигации (и без навигации).-
Стандартная, цифры и кнопки Вперед-Назад.
-
Только цифры
-
Только кнопки Вперед-Назад
-
Показать еще
-
lazyLoad - автоподгрузка по мере прокрутки контента.
ЦитатаСтраница модуля: AJAX-Custom by Sander
Демо: TestFilm - тестовый сайт
Цена: $7На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме
-
Стандартная, цифры и кнопки Вперед-Назад.
-
Новая версия модуля - дополнения для тега custom, который позволяет организовать вывод реально популярных материалов исходя из значений текущих просмотров.Как известно, в DLE есть возможность вывод "популярных" новостей.Это можно сделать через тег {topnews} или посредством {custom order="reads" days="30"}Но в обоих случаях будет выведен топ популярных материалов основываясь на дате публикации.Т.е. если новость была опубликована более месяца назад, но по сей день пользуется популярностью, то вышеуказанные методы такую новость не будут показывать в ТОП-е.Для решения этой проблемы и создан модуль Views-Top.Основной его функционал - это сбор суточной статистики и предоставление возможности вывести реально популярные материалы за заданный промежуток времени.
Так же, помимо его основного функционала, он работает в разы быстрее чем order="reads"Пример его использования:{custom order="views_top_7"}где 7 - количество дней (ТОП созданный в админке модуля).ЦитатаСтраница модуля: Views-Top v.2 by Sander
Демо: TestFilm - тестовый сайт
Цена: $5На странице модуля представлена более подробная информация, а так же там его можно купить в автоматическом режиме
-
2 часа назад, kamensk сказал:
Посещалка какая? На хостинге размещенны?
У меня - нулевая посещаемость, это тестовые сайты. На хостинге и на локалке.
-
22 минуты назад, kamensk сказал:
А много ли сайтов на дле - 200-300тысяч публикаций?
Не знаю. Может и есть, не сомневаюсь в этом.
Но про такие числа и не идет речь. Все тестирования я провожу на вполне реальных сайтах с количеством публикаций 50-100к
Сайт кинотематики 61к новостей: 44к фильмов, 10к сериалов, 6к мультиков.
Сайт с играми 94к. -
14 часов назад, ntrtv сказал:
А как без отложек? У нас несколько корреспондентов на сайте. Они расставляют новости с интервалом 20-30 минут. Как без отложки это делать? А как на раннее утро ставить, на поздний вечер и т.п.?
Я не могу сказать точно в процентном соотношении, но полагаю что бОльшая часть часть сайтов не использует этот функционал.
Но он включен в движке по умолчанию. Поэтому я и рекомендую его отключать.
Кто знает, что это такое, тот оставит включенным. Кто нет - лучше выключить.К тому же то, как сейчас реализована отложенная публикация - это лишь один из вариантов. Который тоже не без недостатков.
Пока кеш новостей не будет очищен - новость не будет отображаться в общей ленте на сайте.
Другое дело, что кеш чистится довольно таки часто, в зависимости от активности пользователя (выставление оценки, добавление комментария).Более правильным вариантом - было бы использование планировщика заданий. И это, кстати, идея. Подумаю над реализацией такого модуля.
16 часов назад, crafic сказал:ну тогда я предлагаю и AND approve=1 убрать для ускорения запроса
и перемещать все новости на модерации в отдельный раздел. например вот так https://skr.sh/s5PsSZX3P3X
а если бы мне за оптимизацию платили я бы еще кое что придумал, да такое что dle точно бы прибавил газу ?
Не могу не согласиться. Но вряд ли такое будет реализовано, уж очень много надо будет переделывать как мне кажется.
-
33 минуты назад, MSK сказал:
$cache_hash = md5($sql_count);
если я правильно понял про кеширование, то при появлении новых новостей в момент хождения по страницам - $sql_count не изменится, изменится результат его выполнения...
Мой хак хранит кеш всех результатов запросов в одном файле с именем news_select-count.tmp. Добавление или удаление новости удаляет все файлы кеша с префиксом news_. В том числе мой файл кеша так же будет удален и создан заново с новыми, правильными значениями.
29 минут назад, crafic сказал:Sander1 у тебя наверно отключена отложенная публикация. и запрос один и тот же. а так на самом деле и AND date<'...' добавляется
"Отложенная публикация" - это как раз то, что я у себя в статье рекомендую отключать в первую очередь.
Вот примеры запросов:В разделе 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.id=c.news_id) WHERE approve=1 [time] => 1,4607090950012 В категории 44к новостей [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('1') AND approve=1 [time] => 0,27791213989258 В категории 10к новостей [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('2') AND approve=1 [time] => 0,083189964294434 В разделе 5к новостей [query] => SELECT COUNT(*) as count FROM dle_post WHERE xfields LIKE '%2019%' AND approve=1 [time] => 0,746661901474 -
Вновь подниму вопрос касательно оптимизации.
Как известно, на средних и больших БД, запрос вида:
SELECT count(*) as count_all FROM dle_post WHERE {...}
Порой занимает довольно продолжительное время. И чем больше новостей в разделе, тем дольше запрос.
И получается, что на всех (!!) страницах где есть навигация:
/page/2/, /page/3/, /page/4/, /page/5000Будет повторно выполняться один и тот же медленный запрос, который всегда будет отдавать один и тот же результат.
Таким образом, в результате сканирования всех 5000 страниц, будет выполнено минимум 10000 запросов. Хотя могло, и следовало бы - 5001.Я предлагаю сделать отдельный кеш для счетчика количества новостей во всех разделах.
PS. Для желающих использовать или попробовать это решение - выложил в виде плагина на github:
https://github.com/San-Dev/dle-plugins/blob/master/cat-optim.xml-
1
-
1
-
-
Локалка:
Версия 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 secЧасть 3. Заполнена только короткая новость, в среднем по ~20кб текста и немного в доп.полях. Количество записей 134к, InnoDB, MariaDB-10.3
dle_post = 7.1 ГиБ
dle_post_extras = 21.6 Мбdle_post_extras - 5.292 sec dle_post - 8.445 secЧасть 3.1 Сократил short_story до 900 символов
dle_post = 2.0 ГиБdle_post_extras - 5.394 sec dle_post - 5.66 secЗато запрос:
WHERE category REGEXP '[[:<:]](1)[[:>:]]' AND approve=1 ORDER BY e.news_read desc
Выполняется 2,65 сек
При том, что запрос с p.views обрабатывается за 0,0013 секА все потому что Using temporary; Using filesort
На большой таблице запрос с news_read DESC вообще выполнялся дольше минуты. Я не знаю почему так...
А главную страницу сайта я вообще так и не смог открыть пока не выключил topnews. У меня банально закончилось место на винте под эту временную таблицу. -
18 минут назад, celsoft сказал:
Оно не может быть одинаковое. Там данные в принципе другие и таблица dle_post априори намного больше, ее обновление занимает больше времени. При условии что у вас там тексты новостей нормальные и обьемные, как и положено, а не одно предложение.
Мне нет смысла выдумывать.
Операционная система: 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); define('DATALIFEENGINE', true ); define('ROOT_DIR', __DIR__); define('ENGINE_DIR', ROOT_DIR . '/engine'); include_once ENGINE_DIR . '/classes/plugins.class.php'; header('Content-type: text/plain; charset=utf-8'); echo date('Y-m-d H:i:s') . ' dle_post_extras' . PHP_EOL; $ids = range(10000, 60000); shuffle($ids); $mt = microtime(true); for ($i = 0; $i < 10000; $i++) { $id = array_pop($ids); $db->query('UPDATE dle_post_extras SET news_read = news_read + 1 WHERE news_id = ' . $id); } echo round(microtime(true) - $mt, 3) . ' sec' . PHP_EOL . PHP_EOL; echo date('Y-m-d H:i:s') . ' dle_post' . PHP_EOL; $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); } echo round(microtime(true) - $mt, 3) . ' sec' . PHP_EOL . PHP_EOL;
Результаты 4 замеров:
2020-11-17 16:01:27 dle_post_extras 1.251 sec 2020-11-17 16:01:29 dle_post 1.168 sec ------------------------------------ 2020-11-17 16:06:29 dle_post_extras 1.488 sec 2020-11-17 16:06:31 dle_post 1.38 sec ------------------------------------ 2020-11-17 16:06:38 dle_post_extras 1.279 sec 2020-11-17 16:06:39 dle_post 1.271 sec ------------------------------------ 2020-11-17 16:06:50 dle_post_extras 1.443 sec 2020-11-17 16:06:51 dle_post 1.394 secСейчас на локалке сделаю 80к новостей в каждой заполнив shortstory по 1 - 10кб текста
Так же проверю заполнив и fullstory по 30-60кб текста, хотя и считаю, что full_story следует перенести в post_extras. -
34 минуты назад, celsoft сказал:
А на запись она какой станет? Не проверили. А вот существенно увеличится.
Вот, провел небольшой тест:
$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к оценок в секунду, поэтому полагаю им можно пренебречь. Да и не будет там ситуация сильно отличаться.
43 минуты назад, celsoft сказал:Ваше тестирование в данном случае по одному запросу не совсем корректно.
Справедливости ради стоит заметить, что этот один запрос тоже может быть не один, если в настройках DLE или категории по умолчанию включена сортировка по просмотрам.
-
Следующая тема о которой я так же хотел бы поговорить - тег {sort}
Я согласен с тем, что разделение таблицы dle_post на dle_post и dle_post_extras - это хорошее решение.
Но вот с тем как выполнено это разделение - я немного не согласен.По моему мнению, во вторую таблицу так же следовало бы вынести второстепенные данные, которые используются преимущественно только на странице полной новости.
К примеру это такие поля как:
descr, keywords, allow_br и, пожалуй, full_storyНо в свою очередь перенести обратно из dle_post_extras поля:
news_read, allow_rate, rating, vote_num, editdate, editor, reasonЧтобы при штатном выводе контента show.short.php - вообще не использовалась таблица dle_post_extras (за исключением rss).
Теперь немного конкретики и зачем я изначально упомянул тег {sort}
При использовании сортировки по популярности или посещаемости:SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE category IN ('1') AND approve=1 ORDER BY e.news_read desc LIMIT 0,60
Время запроса стабильно 1 - 1.5 сек. Количество новостей в категории 44к
EXPLAIN: Using index condition; Using where; Using temporary; Using filesortНо если перенести колонку news_read в dle_post, то картина совершенно другая
SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE category IN ('1') AND approve=1 ORDER BY p.views desc LIMIT 0,60
Время запроса не превышает 5мс
EXPLAIN: Using whereАналогичная проблема касается сортировок в custom
-
1
-
2
-
-
17 часов назад, Gameer сказал:
Как на счёт такого запроса?
С тем же успехом, 220мс.
Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. -
13 часов назад, Gameer сказал:
А можно поделится базой? Хочу кое что проверить.
Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям.
6 часов назад, celsoft сказал:Если вы можете вы знаете лучшее решение, то я был бы рад это услышать.
К сожалению, если бы оно у меня было - я бы его уже озвучил :(
Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории.7 часов назад, celsoft сказал:Чистый, это априори значит плохо.
Не могу не согласиться. Но так же нельзя сказать, что эти базовые настройки отвратно оптимизированы для небольших БД.
Я попробовал поиграться с настройками, это дало некоторый результат, но все равно он далек от приемлемого.Но обнаружил интересный факт.
WHERE cat_id IN (2) - обрабатывается в среднем 220мс (против 900мс раньше) при количестве 54кЗато когда несколько категорий, то уже совершенно другое дело.
WHERE cat_id IN (2,3) - за 39мс. 71к записей.
WHERE cat_id IN (2,1000) - за 28мс. 1000 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт -
46 минут назад, celsoft сказал:
Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще.
Вопрос немного не по теме. Я акцентировал внимание на одной категории, чтобы показать, что это "голая" система и там не отмечено по 100 категорий в каждой новости.
Есть много кино-сайтов, где мультикатегории используются в качестве жанров, подборок или еще чего-либо.
59 минут назад, celsoft сказал:Этот запрос не будет работать например в MySQL 8.xx
Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса.
1 час назад, celsoft сказал:Он не должен столько выполняться при 60к публикаций. Что то некорректно настроено в MySQL, недостаточно выделено под служебные данные.
Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19
DLE 14.1, добавил 78к новостей, каждая отмечена в 3х категориях. Ситуация чуть лучше, но все равно за пределами нормы.SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 10,10
[time] => 0.94885897636414
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 ('3')) c ON (p.id=c.news_id) WHERE approve=1
[time] => 0.33806180953979
Когда несколько категорий в запроса (подкатегории), ситуация частично лучше, частично хуже
Тайминги 0.482 и 0.55 соответственно.Если в категории 10к новостей, то тайминги: 0.137 и 0.041. Наличие подкатегорий не сильно влияет.
-
Хочу обсудить вопрос оптимизации и целесообразности использования таблицы dle_post_extras_cats
Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории.
Берем штатный, стандартный запрос для категории (в ней 44к записей) и проведем несколько замеров:
SELECT SQL_NO_CACHE p.id, p.autor, p.date, p.short_story, full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (1)) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 50,20
Запрос занял 2.1704 сек.
Запрос занял 1.7433 сек.
Запрос занял 1.6352 сек.Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие:
Запрос занял 0.0024 сек.
Запрос занял 0.0017 сек.
Запрос занял 0.0020 сек.На другом тестовом сайте, где в категории ~100к записей - ситуация абсолютно такая же.
И вот еще, если в запросе несколько категорий, то в первом случае время запроса всегда больше 2 сек, во втором практически не меняется, так же в районе 0,002 сек.
EXPLAIN запроса показывает вовсе не радостную картину: Using temporary; Using filesort - т.е. используется временная таблица и сортировка выполняется без использования каких-либо индексов.Я не хочу сказать, что использование REGEXP - хорошая практика. Его действительно следовало заменить, но текущая реализация, как мне кажется, тоже не является лучшим решением.
-
WHERE cat_id IN ('" . implode ( ',', $allowed_cats ) . "')В результате имеем:
WHERE cat_id IN ('1,2,3,4,5')PS. В админке можно одновременно выбрать '- Все -' и другие категории, в результате в строке allow_cats будет сохранена строка: 'all,1,2,3,4,5'
Ну и соответственно эта проверка уже работать не будет:if ($value['allow_cats'] != "all" AND !$value['allow_short'] )-
1
-
-
DLE 14.0
Для сортировки и редактирования используется "виртуальный" ID, который по сути является просто номером строки в файле xfields.txt
Но при перемещении поля, в HTML коде остаются прежние ID, а файл перестраивается и эти же поля уже имеют новые ID.
Приходится каждый раз обновлять страницу.
-
engine/modules/functions.php и engine/inc/include/functions.inc.php
if( $file != '.htaccess' AND !is_dir($file) ) {
is_dir($file) - проверяется по отношению к имени файла, а не его полному пути к директории
Должно быть:
if( $file != '.htaccess' AND !is_dir(ENGINE_DIR . '/cache/' . $file) ) {
DLEPlugins и DIRECTORY_SEPARATOR на Windows
в Прием багов
Опубликовано:
При использовании DIRECTORY_SEPARATOR на Windows - путь к файлу получается с обратным слешем:
\engine\modules\file.phpВ то время как в утилите управления плагинами прописан путь:
/engine/modules/file.phpОтчего DLEPlugins::Check() не находит файл.
В принципе мелочь, но ведь не сложно из коробки прописать строку: