Sander1
-
Публикации
109 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
19
Сообщения, опубликованные пользователем Sander1
-
-
14 часов назад, ntrtv сказал:
А как без отложек? У нас несколько корреспондентов на сайте. Они расставляют новости с интервалом 20-30 минут. Как без отложки это делать? А как на раннее утро ставить, на поздний вечер и т.п.?
Я не могу сказать точно в процентном соотношении, но полагаю что бОльшая часть часть сайтов не использует этот функционал.
Но он включен в движке по умолчанию. Поэтому я и рекомендую его отключать.
Кто знает, что это такое, тот оставит включенным. Кто нет - лучше выключить.К тому же то, как сейчас реализована отложенная публикация - это лишь один из вариантов. Который тоже не без недостатков.
Пока кеш новостей не будет очищен - новость не будет отображаться в общей ленте на сайте.
Другое дело, что кеш чистится довольно таки часто, в зависимости от активности пользователя (выставление оценки, добавление комментария).Более правильным вариантом - было бы использование планировщика заданий. И это, кстати, идея. Подумаю над реализацией такого модуля.
16 часов назад, crafic сказал:ну тогда я предлагаю и AND approve=1 убрать для ускорения запроса
и перемещать все новости на модерации в отдельный раздел. например вот так https://skr.sh/s5PsSZX3P3X
а если бы мне за оптимизацию платили я бы еще кое что придумал, да такое что dle точно бы прибавил газу 😁
Не могу не согласиться. Но вряд ли такое будет реализовано, уж очень много надо будет переделывать как мне кажется.
-
33 минуты назад, MSK сказал:
$cache_hash = md5($sql_count);
если я правильно понял про кеширование, то при появлении новых новостей в момент хождения по страницам - $sql_count не изменится, изменится результат его выполнения...
Мой хак хранит кеш всех результатов запросов в одном файле с именем news_select-count.tmp. Добавление или удаление новости удаляет все файлы кеша с префиксом news_. В том числе мой файл кеша так же будет удален и создан заново с новыми, правильными значениями.
29 минут назад, crafic сказал:Sander1 у тебя наверно отключена отложенная публикация. и запрос один и тот же. а так на самом деле и AND date<'...' добавляется
"Отложенная публикация" - это как раз то, что я у себя в статье рекомендую отключать в первую очередь.
Вот примеры запросов:В разделе 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.id=c.news_id) WHERE approve=1 [time] => 1,4607090950012 В категории 44к новостей [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('1') AND approve=1 [time] => 0,27791213989258 В категории 10к новостей [query] => SELECT COUNT(*) as count FROM dle_post p WHERE category IN ('2') AND approve=1 [time] => 0,083189964294434 В разделе 5к новостей [query] => SELECT COUNT(*) as count FROM dle_post WHERE xfields LIKE '%2019%' AND approve=1 [time] => 0,746661901474 -
Вновь подниму вопрос касательно оптимизации.
Как известно, на средних и больших БД, запрос вида:
SELECT count(*) as count_all FROM dle_post WHERE {...}
Порой занимает довольно продолжительное время. И чем больше новостей в разделе, тем дольше запрос.
И получается, что на всех (!!) страницах где есть навигация:
/page/2/, /page/3/, /page/4/, /page/5000Будет повторно выполняться один и тот же медленный запрос, который всегда будет отдавать один и тот же результат.
Таким образом, в результате сканирования всех 5000 страниц, будет выполнено минимум 10000 запросов. Хотя могло, и следовало бы - 5001.Я предлагаю сделать отдельный кеш для счетчика количества новостей во всех разделах.
PS. Для желающих использовать или попробовать это решение - выложил в виде плагина на github:
https://github.com/San-Dev/dle-plugins/blob/master/cat-optim.xml-
1
-
1
-
-
Локалка:
Версия 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. У меня банально закончилось место на винте под эту временную таблицу. -
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 минуты назад, 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 или категории по умолчанию включена сортировка по просмотрам.
-
Следующая тема о которой я так же хотел бы поговорить - тег {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
-
1
-
2
-
-
17 часов назад, Gameer сказал:
Как на счёт такого запроса?
С тем же успехом, 220мс.
Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. -
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 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт -
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. Наличие подкатегорий не сильно влияет.
-
Хочу обсудить вопрос оптимизации и целесообразности использования таблицы 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 - хорошая практика. Его действительно следовало заменить, но текущая реализация, как мне кажется, тоже не является лучшим решением.
-
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'] )-
1
-
-
DLE 14.0
Для сортировки и редактирования используется "виртуальный" ID, который по сути является просто номером строки в файле xfields.txt
Но при перемещении поля, в HTML коде остаются прежние ID, а файл перестраивается и эти же поля уже имеют новые ID.
Приходится каждый раз обновлять страницу.
-
engine/modules/functions.php и engine/inc/include/functions.inc.php
if( $file != '.htaccess' AND !is_dir($file) ) {
is_dir($file) - проверяется по отношению к имени файла, а не его полному пути к директории
Должно быть:
if( $file != '.htaccess' AND !is_dir(ENGINE_DIR . '/cache/' . $file) ) {
-
В настройках доп.поля есть параметр Разделитель для списка перекрестных ссылок в котором если указать символ с пробелами с обеих сторон, пример " / " - то пробел справа будет обрезан.
При выводе в шаблоне, запись получается такая:
ЦитатаОдин /Два /Три
Приходится в поле записывать спецсимвол:
Цитата/
-
1
-
-
В 30.12.2018 в 14:31, SSID сказал:
Раньше она и скрывалась, потом видимо сделали показ краткой, т.к. количество закладок не соответствовало показываемому количеству.
Никогда не скрывалась. Вероятнее всего вы не замечали или не обращали внимания. Ведь ситуация на самом деле довольно таки редкая и мало кто из пользователей заметит, что в избранном не открывается какая-либо новость. А если и заметит, то вряд ли сообщит.
На счет количества закладок скажу даже больше, если удалить новость находящуюся в закладках - счетчик уже будет невозможно починить.
Можете попробовать сами, создайте тестовый аккаунт и тестовую новость. В тестовом аккаунте добавьте новость в закладки и тут же удалите новость с сайта. Счетчик будет показывать одну новость в закладках, а на странице /favorites/ будет пусто. И никак средствами движка это не исправить. Только посредством ручной правки БД через phpMyAdmin.
-
Новость на модерации видна в списке коротких новостей на странице закладок example.com/favorites/ для всех пользователей.
Версия DLE: любая.
Фикс:
Открыть файл engine/modules/favorites.php
Найти строку:
if( $user_group[$member_id['user_group']]['allow_short'] ) $stop_list = "";
Ниже нее вставить:
$stop_list .= 'approve=1 AND ';
-
1
-
-
1 час назад, celsoft сказал:
И этот тег для перечисленных вами шаблонов не заявлен в принципе
Это признаю, не проверил.
Столкнулся с проблемой именно в {custom }. Там этот тег есть и работает неправильно.
-
На странице полной новости тег {news-id} во всех (!!!) шаблонах отображает ID просматриваемой новости.
А именно в шаблонах topnews.tpl, relatednews.tpl и в блоках {custom ...}
Происходит это из-за коллизии имени тега в engine/classes/templates.class.php
if( defined( 'NEWS_ID' ) ) $this->template = str_ireplace( "{news-id}", NEWS_ID, $this->template );
-
1. Если контент главной заменить на статическую страницу или custom, то страница http://example.com/catalog/ будет обрабатываться как главная $dle_module = 'main'
И в то же время в контенте будет выводится обычный список новостей, игнорируя параметр "Информация выводимая по умолчанию на главной странице:"
2. http://example.com/catalog/0/
engine/init.php
elseif (!$do AND $catalog) $dle_module = "catalog";
И получается, что контент страницы формируется правильно, а тут опять $dle_module = 'main'
PS. Кто не знает, переменная $dle_module отвечает за работу тега [aviable=...]. И получается, что по URL и контенту мы находимся в каталоге, а тег [aviable - считает, что на главной.
PPS. Почему бы в htaccess не использовать запись
index.php?do=catalog&catalog=$1 -
Предложение №1 - убрать запросы в БД при входе на не существующие/удаленные категории:
Предложение №2 - исключить запросы вида SELECT count(*) as count FROM dle_post для страниц категорий.
Вместо выполнения запросов использовать параметр newscount из переменной $cat_info
Предложение №3 - Добавить возможность администратору настраивать очистку кеша при голосовании в рейтинге и добавлении комментария.
Сейчас при выставлении оценки и при добавлении комментария - очищается весь кеш новостей с префиксом news_, а это как контент так и блоки custom (и newscount).
Но что если на сайте в короткой новости не отображаются ни рейтинг ни количество комментариев. Получается достаточно чистить только кеш полной новости и комментариев.
Если кому интересно, решение №1 и №2 описал у себя на сайте
-
Если я правильно понял ТС, то сейчас статическая страница представляет собой конструкцию:
<div> <h1>Заголовок</h1> Текст </div>
А нужно типа так:
<div> <h1>Заголовок</h1> Текст </div> <div> <h2>Заголовок второй</h2> Текст еще какой-то </div>
Для этого можно воспользоваться параметром индивидуального файла шаблона для статической страницы http://prntscr.com/k6bn1m
-
Предложение по утилите управления плагинами.
Добавить "Режим разработчика", чтобы вручную внесенные изменения тут же отображались в работе сайта, но при этом учитывались включенные плагины.
Сейчас для этого достаточно вручную добавить автоматическую очистку кеша плагинов, но было бы удобнее если бы была просто кнопка в самой панели управления плагинами.
Если кому интересно, в файле engine/classes/plugins.class.php
Перед строкой
abstract class DLEPlugins {
Вставить:
@unlink(ENGINE_DIR . '/cache/system/plugins.php');
-
Когда много категорий становится довольно неудобно добавлять подкатегории. В частности каждый раз приходится искать нужную категорию в списке.
Данный хак добавляет кнопку, при клике на которую сразу становится отмеченной выбранная категория.
Установщик плагина для DLE 13.0
<?xml version="1.0" encoding="utf-8"?> <dleplugin> <name>Автовыбор родительской категории</name> <description>При создании подкатегории будет автомаитически выбрана родительская категория. by Sander</description> <icon></icon> <version></version> <dleversion></dleversion> <versioncompare>less</versioncompare> <mysqlinstall><![CDATA[]]></mysqlinstall> <mysqlupgrade><![CDATA[]]></mysqlupgrade> <mysqlenable><![CDATA[]]></mysqlenable> <mysqldisable><![CDATA[]]></mysqldisable> <mysqldelete><![CDATA[]]></mysqldelete> <file name="engine/inc/categories.php"> <operation action="before"> <searchcode><![CDATA[<a href=\"?mod=categories&action=edit]]></searchcode> <replacecode><![CDATA[<a href=\"#\" onclick=\"return addSubCat({$id});\"><i title=\"{$lang['cat_add']}\" class=\"fa fa-plus-circle text-success\"></i></a> ]]></replacecode> </operation> <operation action="after"> <searchcode><![CDATA[<script>]]></searchcode> <replacecode><![CDATA[function addSubCat(id) { $('.uniform[name=category]').val(id).selectpicker('render'); $('#newcats').modal(); return false; }]]></replacecode> </operation> </file> </dleplugin>
С уважением,
Олег Александрович a.k.a. Sander
-
3
-
2
-
Пожелания для новых версий DataLife Engine
в DataLife Engine (Общие вопросы)
Опубликовано:
Не знаю. Может и есть, не сомневаюсь в этом.
Но про такие числа и не идет речь. Все тестирования я провожу на вполне реальных сайтах с количеством публикаций 50-100к
Сайт кинотематики 61к новостей: 44к фильмов, 10к сериалов, 6к мультиков.
Сайт с играми 94к.