Перейти к публикации

Рекомендованные сообщения

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, radrigo сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах
40 minutes ago, Sander1 said:

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

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

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, Sander1 сказал:

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

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

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

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

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, Sander1 сказал:

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
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

 

Ссылка на сообщение
Поделиться на других сайтах
17 часов назад, Gameer сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах

у меня запрос 

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

Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Sander1
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Sander1 сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, Sander1 сказал:

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

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

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

GtDXzjTwSACbIuugm8hlnA.png

Стандартный

EBu4gZrzQKKPCt9ycB1uQw.png

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

PHP 7.3, MariaDB 10.3

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

Ссылка на сообщение
Поделиться на других сайтах
16.11.2020 в 18:18, Sander1 сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
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.

Ссылка на сообщение
Поделиться на других сайтах
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 гб 

Изменено пользователем Хоббит
Ссылка на сообщение
Поделиться на других сайтах

Локалка:

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах
22.11.2020 в 04:58, skd сказал:

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • celsoft изменил заголовок на Пожелания для новых версий DataLife Engine

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
×
  • Создать...