Пожелания Для Новых Версий Линейки 14.хх

[stihhi 8]

Уважаемые разрабоичики, очень не хватает списка запрещенных слов, а то вводить вручную 700 матерных слов очень не удобно и ещё добавить пункт оповещение администратора если какой-то пользователь употребил запрещённое слово, очень не обходимо чтоб быстро искать нарушителей на сайте.

[MSK 148]

23 минуты назад, stihhi сказал:

вводить вручную 700 матерных слов очень не удобно

Для подобного фильтра есть класс "матотест" для русского языка - хорошо справляется с детектированием (я использовал когда-то в чатах), а "извратные" сочетания отдельно добавлял. Автор класса был раньше на dklab, сейчас сайт уже не фурычит - гугл в помощь.

[stihhi 8]

13 часов назад, MSK сказал:

Для подобного фильтра есть класс "матотест" для русского языка - хорошо справляется с детектированием (я использовал когда-то в чатах), а "извратные" сочетания отдельно добавлял. Автор класса был раньше на dklab, сейчас сайт уже не фурычит - гугл в помощь.

А оповещение, если человеку просто выводится Аякс окно о запрещенных Слован он просто ставит пару точек и все dle принимает такой комент.

[videowoolf 0]

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

[Nicksemsujahan 2]

Обновления которые очень нужны:
-убрать быдлокод при вставке картинок через редактор

-видео с ютуба вставляются некоректно (у бутсрап есть готовое решение)

-кнопка генерации сайтмап после публикации статьи
-при загрузке картинки к ее названию добавляется кучу мусора. Это не нужно и негативно влияет на сео

[celsoft 5 560]

22 часа назад, Nicksemsujahan сказал:

-видео с ютуба вставляются некоректно (у бутсрап есть готовое решение)

Все прекрасно и корректно вставляется. На чем основано подобное утверждение непонятно.

22 часа назад, Nicksemsujahan сказал:

-убрать быдлокод при вставке картинок через редактор

Никакого "быдлокода" там нет.

22 часа назад, Nicksemsujahan сказал:

-при загрузке картинки к ее названию добавляется кучу мусора. Это не нужно и негативно влияет на сео

Никакого мусора тоже там нет. Если не знаете для чего и почему, это не значит что это мусор.

P.S. Вам предупреждение, за не уважение к другим участникам форума и не умение корректно излагать свои мысли и сообщения. Здесь долго не задерживаются те, кто кто считает что если ему что то не нужно, то это уже и "быдлокод" и "мусор".

[Drage 17]

Хотелось бы добавить возможность показывать пользователю последние посещенные новости.

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

[radrigo 90]

3 часа назад, Drage сказал:

Хотелось бы добавить возможность показывать пользователю последние посещенные новости.

Данная возможность добавлена в версии 14.0
Смотрите 12 пункт
https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html

[Drage 17]

3 часа назад, radrigo сказал:

Данная возможность добавлена в версии 14.0
Смотрите 12 пункт
https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html

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

[Sander1 48]

Хочу обсудить вопрос оптимизации и целесообразности использования таблицы 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 - хорошая практика. Его действительно следовало заменить, но текущая реализация, как мне кажется, тоже не является лучшим решением.

[crafic 3]

40 minutes ago, Sander1 said:

Мультикатегории включены, но каждая новость отмечена только в одной категории

если новость в одной категории то зачем юзать мульти?

[celsoft 5 560]

7 часов назад, Sander1 сказал:

Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории.

Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще.

7 часов назад, Sander1 сказал:

Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие

Этот запрос не будет работать например в MySQL 8.xx

7 часов назад, Sander1 сказал:

Запрос занял 2.1704 сек.
Запрос занял 1.7433 сек.
Запрос занял 1.6352 сек.

Он не должен столько выполняться при 60к публикаций. Что то некорректо настроено в MySQL, недостаточно выделено под служебные данные.

[Sander1 48]

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. Наличие подкатегорий не сильно влияет.

[Gameer 253]

26 минут назад, Sander1 сказал:

Ради интереса и чистоты эксперимента, поставил свежий 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. Наличие подкатегорий не сильно влияет.

А можно поделится базой? Хочу кое что проверить.

[celsoft 5 560]

7 часов назад, Sander1 сказал:

Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса.

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

7 часов назад, Sander1 сказал:

Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19

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

[Sander1 48]

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 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт

[Gameer 253]

2 часа назад, Sander1 сказал:

Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям.

К сожалению, если бы оно у меня было - я бы его уже озвучил :(
Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории.

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

Но обнаружил интересный факт.
WHERE cat_id IN (2) - обрабатывается в среднем 220мс (против 900мс раньше) при количестве 54к

Зато когда несколько категорий, то уже совершенно другое дело.
WHERE cat_id IN (2,3) - за 39мс. 71к записей.
WHERE cat_id IN (2,1000) - за 28мс. 1000 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт

Как на счёт такого запроса?

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) JOIN (SELECT id FROM dle_post LEFT JOIN dle_post_extras e ON (id=e.news_id) INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (2)) z ON (id=z.news_id) WHERE approve=1 ORDER BY date desc LIMIT 0,10) as l ON p.id=l.id ORDER BY date desc

 

[Sander1 48]

17 часов назад, Gameer сказал:

Как на счёт такого запроса?

С тем же успехом, 220мс.
Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. 

[crafic 3]

у меня запрос 

SELECT 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  LEFT JOIN dle_post_extras e ON (p.id=e.news_id) 
    WHERE approve=1  AND date < '2020-11-16 16:38:32' AND p.category REGEXP '[[:<:]](29|30)[[:>:]]'
    ORDER BY date DESC 
    LIMIT 20;

занял 0.003сек при 26 912 новостях. если же с INNER JOIN DISTINCT , то (0.590 s) 

подставлял и по 4 категории. p.category REGEXP '[[:<:]](9|10|12|23)[[:>:]]' - (0.003 s) . с INNER JOIN DISTINCT , то  (0.412 s)

версия mysql 5.7.29-log

так что подтверждаю с регуляркой быстрее. ето логично. так как один только запрос

SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (9,10,12,23) 

занимает (0.342 s) . не говоря уже о обьединениях с dle_post dle_post_extras

[Sander1 48]

Следующая тема о которой я так же хотел бы поговорить - тег {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

Изменено 16 ноября пользователем Sander1

[crafic 3]

на счет полей я тут тему создавал https://searchengines.guru/ru/forum/1021845

если по рейтингу сортируем то беда. 

[celsoft 5 560]

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

Но если перенести колонку news_read в dle_post, то картина совершенно другая

А на запись она какой станет? Не проверили. А вот существенно увеличится. Во время просмотра не только чтение происходит, но и запись. Ваше тестирование в данном случае по одному запросу не совсем корректно.

[Gameer 253]

4 часа назад, Sander1 сказал:

С тем же успехом, 220мс.
Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. 

Очень странно.

Тот что я предложил.

Стандартный

В базе 54000 записей.

PHP 7.3, MariaDB 10.3

[Sander1 48]

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 или категории по умолчанию включена сортировка по просмотрам.

[celsoft 5 560]

16.11.2020 в 18:18, Sander1 сказал:

Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов.

Оно не может быть одинаковое. Там данные в принципе другие и таблица dle_post априори намного больше, ее обновление занимает больше времени. При условии что у вас там тексты новостей нормальные и обьемные, как и положено, а не одно предложение.