Пожелания для новых версий DataLife Engine

[Sander1 62]

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 311]

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 6 093]

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

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

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

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

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

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

[Sander1 62]

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 311]

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 62]

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

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

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

[crafic 32]

у меня запрос 

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 62]

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

[crafic 32]

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

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

[celsoft 6 093]

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

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

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

[Gameer 311]

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

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

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

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

Стандартный

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

PHP 7.3, MariaDB 10.3

[Sander1 62]

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 6 093]

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

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

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

[Sander1 62]

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.

[Хоббит 35]

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

Мне нет смысла выдумывать.

Операционная система:	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.

Если надо могу дать доступ к бд с 300к+ новостями, чисто контентый сайт, бд весит ~6 гб 

Изменено 17 ноября 2020 пользователем Хоббит

[Sander1 62]

Локалка:

Версия 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. У меня банально закончилось место на винте под эту временную таблицу.

[crafic 32]

SELECT COUNT в MyISAM тоже в разы быстрее чем на Innodb

[skd 5]

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Например, пусть основной категорией первая, выбранная пользователем, или сделать поле выбора основной категории. Спасибо за движок!

[crafic 32]

если для ред публ на сайте выбран bbcode то невозможно загрузить изображение пока не будет фокус в textarea

аналогично кнопочка возле нее

[alex32 942]

22.11.2020 в 04:58, skd сказал:

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке.

Поддерживаю, потому что сейчас  с этой принудительной сортировкой сильно снижается функционал тегов [category] и [catlist]

[dimitron 34]

Дополнительно поле СПИСОК. Нужно расшыть его что бы можно было выбрать несколько пунктов из списка. Такое же поля как мы выбираем категории (несколько категорий).

[Mr. Bot 26]

21.11.2020 в 23:58, skd сказал:

Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Например, пусть основной категорией первая, выбранная пользователем, или сделать поле выбора основной категории. Спасибо за движок!

Этому багу уже 100 лет в обед, но судя по всему @celsoft не видит ничего зазорного в том что второстепенные категории могут заменять основную, в зависимости от того чей ID категории меньше.

23.11.2020 в 23:46, alex32 сказал:

Поддерживаю, потому что сейчас  с этой принудительной сортировкой сильно снижается функционал тегов [category] и [catlist]

Так то данные теги перебирают все указанные категории у новости, им без разницы кто на каком месте по счёту указанна категория.

@celsoft, почему доп. поле дата и время не использует unixtime?
Элементарно же можно было сделать много интересных вещей (вроде привязки к времени сайта, сортировке, различные кастомные выборки), а так это сугубо текст в БД.

[alex32 942]

5 минут назад, Mr. Bot сказал:

Так то данные теги перебирают все указанные категории у новости, им без разницы кто на каком месте по счёту указанна категория.

 

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

[Crashlabs 65]

Просьба добавить тег  [inform_имя] текст [/inform_имя] для проверки информера по аналогии с [banner_имя] текст [/banner_имя].

[Crashlabs 65]

Также, не хватает аналогичных тегов [page-description] текст [/page-description], [not-page-title] текст [/not-page-title] только для {category-title} и {category-description}