Sander1

У меня - нулевая посещаемость, это тестовые сайты. На хостинге и на локалке.

Не знаю. Может и есть, не сомневаюсь в этом. Но про такие числа и не идет речь. Все тестирования я провожу на вполне реальных сайтах с количеством публикаций 50-100к Сайт кинотематики 61к новостей: 44к фильмов, 10к сериалов, 6к мультиков. Сайт с играми 94к.

Я не могу сказать точно в процентном соотношении, но полагаю что бОльшая часть часть сайтов не использует этот функционал. Но он включен в движке по умолчанию. Поэтому я и рекомендую его отключать. Кто знает, что это такое, тот оставит включенным. Кто нет - лучше выключить. К тому же то, как сейчас реализована отложенная публикация - это лишь один из вариантов. Который тоже не без недостатков. Пока кеш новостей не будет очищен - новость не будет отображаться в общей ленте на сайте. Другое дело, что кеш чистится довольно таки часто, в зависимости от активности пользователя (выставл

Мой хак хранит кеш всех результатов запросов в одном файле с именем news_select-count.tmp. Добавление или удаление новости удаляет все файлы кеша с префиксом news_. В том числе мой файл кеша так же будет удален и создан заново с новыми, правильными значениями. "Отложенная публикация" - это как раз то, что я у себя в статье рекомендую отключать в первую очередь. Вот примеры запросов: В разделе 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

Вновь подниму вопрос касательно оптимизации. Как известно, на средних и больших БД, запрос вида: SELECT count(*) as count_all FROM dle_post WHERE {...} Порой занимает довольно продолжительное время. И чем больше новостей в разделе, тем дольше запрос. И получается, что на всех (!!) страницах где есть навигация: /page/2/, /page/3/, /page/4/, /page/5000 Будет повторно выполняться один и тот же медленный запрос, который всегда будет отдавать один и тот же результат. Таким образом, в результате сканирования всех 5000 страниц, будет выполнено минимум 10000 запросов. Хотя могло

Локалка: Версия 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

Мне нет смысла выдумывать. Операционная система: 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); defi

Вот, провел небольшой тест: $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к оценок в секунду, поэтому полагаю им

Следующая тема о которой я так же хотел бы поговорить - тег {sort} Я согласен с тем, что разделение таблицы dle_post на dle_post и dle_post_extras - это хорошее решение. Но вот с тем как выполнено это разделение - я немного не согласен. По моему мнению, во вторую таблицу так же следовало бы вынести второстепенные данные, которые используются преимущественно только на странице полной новости. К примеру это такие поля как: descr, keywords, allow_br и, пожалуй, full_story Но в свою очередь перенести обратно из dle_post_extras поля: news_read, allow_rate, rating, vote_num, edit

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

Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям. К сожалению, если бы оно у меня было - я бы его уже озвучил :( Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории. Не могу не согласиться. Но так же нельзя сказать, что эти базовые настройки отвратно оптимизированы для небольших БД. Я попробовал поиграться с настройками, это дало некоторый результат, но все равно он далек от приемлемого. Но обнаружил интересный факт. WHERE cat_id IN (2) - обраб

Вопрос немного не по теме. Я акцентировал внимание на одной категории, чтобы показать, что это "голая" система и там не отмечено по 100 категорий в каждой новости. Есть много кино-сайтов, где мультикатегории используются в качестве жанров, подборок или еще чего-либо. Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса. Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19 DLE 14.1, добавил 78к новостей, каждая отмечена в 3х категориях. Ситуация чуть лучше, но все равно за пределам

Хочу обсудить вопрос оптимизации и целесообразности использования таблицы 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_p

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'] )

DLE 14.0 Для сортировки и редактирования используется "виртуальный" ID, который по сути является просто номером строки в файле xfields.txt Но при перемещении поля, в HTML коде остаются прежние ID, а файл перестраивается и эти же поля уже имеют новые ID. Приходится каждый раз обновлять страницу.