radrigo 170 Опубликовано: 13 ноября 2020 Рассказать Опубликовано: 13 ноября 2020 3 часа назад, Drage сказал: Хотелось бы добавить возможность показывать пользователю последние посещенные новости. Данная возможность добавлена в версии 14.0 Смотрите 12 пункт https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html 1 Цитата Ссылка на сообщение Поделиться на других сайтах
Drage 20 Опубликовано: 13 ноября 2020 Рассказать Опубликовано: 13 ноября 2020 3 часа назад, radrigo сказал: Данная возможность добавлена в версии 14.0 Смотрите 12 пункт https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html Да, у меня было ощущение что эта функция есть, и я даже припоминал что добавлена в одном из последних релизов, но я не смог найти. Спасибо большое! Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 59 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 Хочу обсудить вопрос оптимизации и целесообразности использования таблицы 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 31 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 40 minutes ago, Sander1 said: Мультикатегории включены, но каждая новость отмечена только в одной категории если новость в одной категории то зачем юзать мульти? Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 985 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 Автор 7 часов назад, Sander1 сказал: Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории. Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще. 7 часов назад, Sander1 сказал: Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие Этот запрос не будет работать например в MySQL 8.xx 7 часов назад, Sander1 сказал: Запрос занял 2.1704 сек. Запрос занял 1.7433 сек. Запрос занял 1.6352 сек. Он не должен столько выполняться при 60к публикаций. Что то некорректо настроено в MySQL, недостаточно выделено под служебные данные. Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 59 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 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 299 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 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 985 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 Автор 7 часов назад, Sander1 сказал: Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса. Ну а это самый быстрый запрос который бы поддерживал и функциональность и новое серверное ПО, отказаться от поддержки нового ПО, которое уже используется повсеместно невозможно. Под "самый быстрый" я безусловно имею ввиду что из тех, что известны мне. Если вы можете вы знаете лучшее решение, то я был бы рад это услышать. Быстродействие наш приоритет, мы всегда прислушиваемся к таким советам. 7 часов назад, Sander1 сказал: Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19 Чистый, это априори значит плохо. Стандартая конфигурация, это всегда самые неоптимальные настройки, потому как заточены на совместимость а не на быстродействие. Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 59 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 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 299 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 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 59 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 17 часов назад, Gameer сказал: Как на счёт такого запроса? С тем же успехом, 220мс. Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 31 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 у меня запрос 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 59 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 (изменено) Следующая тема о которой я так же хотел бы поговорить - тег {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 1 2 Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 31 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 на счет полей я тут тему создавал https://searchengines.guru/ru/forum/1021845 если по рейтингу сортируем то беда. Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 985 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 Автор 1 час назад, Sander1 сказал: Но если перенести колонку news_read в dle_post, то картина совершенно другая А на запись она какой станет? Не проверили. А вот существенно увеличится. Во время просмотра не только чтение происходит, но и запись. Ваше тестирование в данном случае по одному запросу не совсем корректно. Цитата Ссылка на сообщение Поделиться на других сайтах
Gameer 299 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 4 часа назад, Sander1 сказал: С тем же успехом, 220мс. Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. Очень странно. Тот что я предложил. Стандартный В базе 54000 записей. PHP 7.3, MariaDB 10.3 Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 59 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 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 985 Опубликовано: 17 ноября 2020 Рассказать Опубликовано: 17 ноября 2020 Автор 16.11.2020 в 18:18, Sander1 сказал: Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов. Оно не может быть одинаковое. Там данные в принципе другие и таблица dle_post априори намного больше, ее обновление занимает больше времени. При условии что у вас там тексты новостей нормальные и обьемные, как и положено, а не одно предложение. Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 59 Опубликовано: 17 ноября 2020 Рассказать Опубликовано: 17 ноября 2020 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 Опубликовано: 17 ноября 2020 Рассказать Опубликовано: 17 ноября 2020 (изменено) 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 59 Опубликовано: 17 ноября 2020 Рассказать Опубликовано: 17 ноября 2020 Локалка: Версия 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 31 Опубликовано: 18 ноября 2020 Рассказать Опубликовано: 18 ноября 2020 SELECT COUNT в MyISAM тоже в разы быстрее чем на Innodb Цитата Ссылка на сообщение Поделиться на других сайтах
skd 5 Опубликовано: 21 ноября 2020 Рассказать Опубликовано: 21 ноября 2020 Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Например, пусть основной категорией первая, выбранная пользователем, или сделать поле выбора основной категории. Спасибо за движок! 1 4 Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 31 Опубликовано: 23 ноября 2020 Рассказать Опубликовано: 23 ноября 2020 если для ред публ на сайте выбран bbcode то невозможно загрузить изображение пока не будет фокус в textarea аналогично кнопочка возле нее Цитата Ссылка на сообщение Поделиться на других сайтах
alex32 934 Опубликовано: 23 ноября 2020 Рассказать Опубликовано: 23 ноября 2020 22.11.2020 в 04:58, skd сказал: Здравствуйте! Мегаважно сделать выбор основной категории новости, категории, которая будет отражаться в url новости. Это крайне не удобно, когда назначается категория, которая просто выше в списке. Поддерживаю, потому что сейчас с этой принудительной сортировкой сильно снижается функционал тегов [category] и [catlist] 1 Цитата Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Присоединяйтесь к обсуждению
Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.