DataLife Engine v.11.3 Press Release

[Captain 625]

Celsoft, SKYNET74 к вам на работу напрашивается походу, утомляет.

SKYNET74, не отвечай мне, ну пожалуйста.

Изменено 7 апреля 2017 пользователем Captain

[SKYNET74 315]

13 часа назад, celsoft сказал:

Еще раз даю ссылку https://forum.dle-news.ru/topic/71136-datalife-engine-v113-press-release/?do=findComment&comment=355730 там указан пример того сколько ключей. Откуда вывод что все будет в одном ключе????????

Ключ массива != ключ записи в memcache однако...

13 часа назад, celsoft сказал:

Да ладно? Вы разработчик DLE? Вот я лично разработчик DLE и пишу код DLE. И все что реализуется беру из Пожелания Для Новых Версий Линейки 11.хх Там клойдак для идей, и того что нужно реализовать. Откуда вы как человек даже близко не имеющий отношения к разработке скрипта, утверждаете, что берется из каких то модулей. Последний сторонний модуль, я смотрел года три назад, и то когда попросили разобраться с проблемами в нем, очень хорошие люди. Так что ваше утверждение просто высосано из пальца, не обоснованное ничем.

Ну тогда вы просто "Ванга"...
А в теме много чего написано того, что уже есть в сторонних решениях, но почему то нет из коробки, по этому вы тему считаете как первоисточник видимо, хотя обычно всё наоборот...
Я уже много лет наблюдаю за "движением мод" в разработке DLE, и могу точно сказать что многие идеи просто взяты из модулей, которые были созданы задолго до вашей реализации того же функционала.

13 часа назад, celsoft сказал:

Так вы же сами этому мешаете. Вместо того чтобы писать новые возможности, я читаю и комментирую ваши очередные глупости.  И таких уже 540 на форуме от вас. Новую версию можно было разработать за этот срок.

Дак вам же подсказывают часто как сделать всё сразу, кастомно, и юзабельно, а вы одну и туже функцию растягиваете на 2-5 релизов, постепенно допиливая в ней то что де факто должно быть там сразу, смысл растягивать? Имитация бурной деятельности? Это как браться за все дела сразу, и не одно не доделать до конца, лучше всё таки браться за несколько, и сделать их полностью и качественно.
Возьмём хотя бы вот это:

Цитата

27. Для шаблонов вывода меню категорий (categorymenu.tpl) добавлен новый тег {id}, который выводит ID категории. Данный тег будет полезен, когда нужно визуально выделить какую-либо категорию.

Ну и отчасти вот это:

Цитата

3. В настройки скрипта добавлена возможность указания количества страниц, при показе кратких публикаций, которое необходимо кешировать. Ранее в скрипте кэшировались только первые 10 страниц по навигации по сайту. Теперь вы можете по своему желанию указать любое количество страниц, которое необходимо кешировать.
 

И если одно и тоже нововведение растягивать на 2-4 пункта в списке изменений, список конечно увеличится, но по факту будет сделано в 2-4 раза меньше нововведений...
Например пункты 6 и 7 это одно и тоже...
PS: Я надеюсь проверка файлов на допустимость и вывод ошибок будет на ajax, и пользователи не будут проклинать всех причастных к созданию сего сайта, когда в конце страница обновится, и ему будет сообщено о недопустимости такого то файла?

 

13 часа назад, celsoft сказал:

Как файловое кеширование в DLE узнает какой кеш нужно сбросить? Точно также об этом узнает DLE и в memache. Только читает не список файлов, а список им же созданных и им же запомненных ключей. Служебный ключ запоминает информацию о ключе где хранится информация. А не хранит все в одном ключе. Ваше "тегирование" работает точно так же, есть ключи с информацией, есть ключ со служебной информацией где храняться теги и привязки их ключам. DLE делает точно также, только теги не использует, он хранит имена префиксов, как в файловом кешировании.

На текущий момент DLE никак не узнаёт даже для файлового кеша как сбросить определённый кеш (кроме полного кеша новости), а убивает весь префикс, как вы реализовали блокировки в мемкеше остаётся загадкой конечно, с учётом того что алгоритм в пару строк.
PS: Моё (хотя оно не моё) тегирование работает иначе, теги хранятся прямо в массиве ключа, и сравниваются с "источником" таймштампа, у каждой группы кеша свой тег, и как только нужно её убить, таймштамп в источнике меняется на текущий, всё, алгоритм видит что они не совпадают (таймштамп из источника и из тега кеш-записи в мемкеше) и признаёт кеш устаревшим и просто перезаписывает его актуальными данными полученными из БД, и никаких дополнительных запросов к мемкешу для получения служебных тегов делать не нужно, это экономит ресурсы и время.
Источником может служить любое хранилище, но использовать мемкеш не желательно, из-за отсутствия блокировок, это вызовет проблемы при отсутствии "горячего" кеша для популярных данных.
PS2: Обновление алгоритмов кеширования в мемкеш внезапно появилось когда я в нескольких темах доступным языком "вскрыл" его неэффективность, совпадение? Не думаю... (*тут_фото_киселёва.jpg*)

 

 

Цитата

19. Для модуля добавления публикаций на сайте добавлена возможность передавать в URL браузера категории, которые необходимо сделать выбранными по умолчанию. Для этого используется URL http://вашсайт.ru/index.php?do=addnews&category=X где "X" это ID нужных вам категорий, перечисленные через запятую. Например, по адресу http://вашсайт.ru/index.php?do=addnews&category=3,4,5 в форме добавления новости на сайте будут выбраны по умолчанию категории с ID 1, 2 и 3. Данное нововведение будет полезно для сайтов, которые используют доп. поля для публикаций назначенные разным категориям, и хотят дать пользователям при добавлении публикаций несколько уже предустановленных форм добавления публикации, для различных категорий.

Сразу вопрос, а почему не сделать сразу же теги с возможностью вложенности в друг друга:
[addnews_category_id=1,2,3,4,5][/addnews_category_id]

И
[not_addnews_category_id=1,2,3,4,5][/not_addnews_category_id]
Элементарно скорее всего нужно будет что то выводить в зависимости от того, в какой раздел добавляется новость, например подсказки и т.д., и для разных разделов они должны быть разные соответственно.
Вот вам и почти что полноценные разные формы добавления новостей.
Неужели это не очевидно?
Смысл лишь в заранее выбранной категории?
Если не ошибаюсь, это и на JS можно было реализовать раньше.

12 часа назад, Captain сказал:

Celsoft, SKYNET74 к вам на работу напрашивается походу, утомляет.

SKYNET74, не отвечай мне, ну пожалуйста.

Просто конструктивный диалог, или вы как обычно за то что бы "бить себя пяткой в грудь" и являться правдой в последней инстанции?
PS: На работу я ни к кому не напрашиваюсь, мне хватает и того что есть.

Изменено 8 апреля 2017 пользователем SKYNET74

[celsoft 6 082]

9 часов назад, SKYNET74 сказал:

Ключ массива != ключ записи в memcache однако...

 Очень смешная фпаза. Ключом массива является то что в этот ключ будет записано. Будет записан в него ключ записи в memcache, то ключем массива будет именно он. И самое смешное вы написали это не видя как это сделано в DLE, а в DLE как раз таки и сделано так, что в служебном массиве ключем является ключ записи с данными в memcache, т.е. вы написали о невозможности того, что как раз и используется в DLE.

9 часов назад, SKYNET74 сказал:

А в теме много чего написано того, что уже есть в сторонних решениях, но почему то нет из коробки, по этому вы тему считаете как первоисточник видимо, хотя обычно всё наоборот...

Тема, что я дал ссылку является источником для меня. Мне не нужно куда то ходить и смотреть, достаточно посмотреть то что просят, при составлении списка что будет в новой версии.

9 часов назад, SKYNET74 сказал:

Дак вам же подсказывают часто как сделать всё сразу, кастомно, и юзабельно, а вы одну и туже функцию растягиваете на 2-5 релизов, постепенно допиливая в ней то что де факто должно быть там сразу, смысл растягивать? Имитация бурной деятельности? Это как браться за все дела сразу, и не одно не доделать до конца, лучше всё таки браться за несколько, и сделать их полностью и качественно.

Сразу видно, что вы всегда занимались лишь копированием готового, а не созданием своего с нуля. Поэтому в вашей голове может рождаться только одна мысль. Это имитация деятельности. Когда я пишу, я пишу с нуля, так как по моему мнению является оптимальным, чтобы было меньше нагрузки, чтобы работало максимально быстро и было только то что нужно. И необходимости например {id} я не увидел при создании. Потом когда это появилось и заработало, люди стали обращаться ко мне, и писать, вы знаете мы делаем то то и то то, хотим чтобы было так, и знаете, нам вот этого не хватает для реализации, пожалуйста добавьте. Я вижу что их слова действительно обоснованы и имеют логику, поэтому и добавляю. А у вас только одна мысль в голове, это не добавили, чтобы сделать потом. Это заблуждение. Этого не было изначально, потому что я не счел это необходимым сразу, потому как я изначально не увидел сценария использования.

9 часов назад, SKYNET74 сказал:

PS: Моё (хотя оно не моё) тегирование работает иначе, теги хранятся прямо в массиве ключа, и сравниваются с "источником" таймштампа, у каждой группы кеша свой тег, и как только нужно её убить, таймштамп в источнике меняется на текущий, всё, алгоритм видит что они не совпадают (таймштамп из источника и из тега кеш-записи в мемкеше) и признаёт кеш устаревшим и просто перезаписывает его актуальными данными полученными из БД, и никаких дополнительных запросов к мемкешу для получения служебных тегов делать не нужно, это экономит ресурсы и время.

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

9 часов назад, SKYNET74 сказал:

Сразу вопрос, а почему не сделать сразу же теги с возможностью вложенности в друг друга:
[addnews_category_id=1,2,3,4,5][/addnews_category_id]

И
[not_addnews_category_id=1,2,3,4,5][/not_addnews_category_id]
Элементарно скорее всего нужно будет что то выводить в зависимости от того, в какой раздел добавляется новость, например подсказки и т.д., и для разных разделов они должны быть разные соответственно.
Вот вам и почти что полноценные разные формы добавления новостей.
Неужели это не очевидно?
Смысл лишь в заранее выбранной категории?
Если не ошибаюсь, это и на JS можно было реализовать раньше.

Вы находитесь на этом форуме постоянно. Просили эту возможность кстати именно в теме на форуме. Вот найдите ее и почитайте. Я сделал ровно то, что попросили. Когда будет пожелания именно по этим тегам, и к ним присоединиться достаточное количество людей, которым это нужно, появятся и они. А пока есть другие желания, которые также нужно делать, и которые давно просят пользователи.

Цитата

Просто конструктивный диалог

Если бы он был таковым. Я был бы рад, но к сожалению это не так. Весь диалог состоит в том что вы бросаете какую либо фразу, и ждете пока перед вами оправдаются, или придумаете то о чем никто не писал, и ждете пока вам это разъяснят. Это не конструктивный диалог. А оправдываться перед вами или обьяснять как и что почему так работает, или разжевывать алгоритмы, мне уже надоело. Это не конструктивный диалог, а пустая трата времени. Поэтому я устраняюсь с этого диалога. Больше не вижу смысла его вести.

[celsoft 6 082]

8 часов назад, SKYNET74 сказал:

На текущий момент DLE никак не узнаёт даже для файлового кеша как сбросить определённый кеш

DLE это не может это сделать для кеша вывода кратких новостей. Да это действительно так. И это сделано было также специально, поэтому как он кеширует в данном случае страницы и блоки целиком в полностью готовом виде. А не каждую краткую новость по отдельности. И я в отличие от вас проводил исследование по этому вопросу, и различного рода тестирования. И кеширование кратких новостей по отдельности, их контроль и в итоге давало большую нагрузку и расходы по памяти и файловым дескрипторам, нагрузку на HDD чем кешировать целиком и сбрасывать также целиком, а потом постепенно пересоздавать их также целиком. Это для вас является недостатком, а для меня это осознанное решение на основе общего тестирования и исследований. Поэтому DLE и является самым быстрым скриптом из всех аналогов, и создает самую низкую нагрузку из всех конкурентов, имея больший набор функций при этом из коробки. Я говорю именно о возможностях из коробки, а не о том что можно сделать потом с парой десятков плагинов. Я никогда ничего не делаю, тщательно не подумав над алгоритмом и что это даст. Иногда может месяц уйти тестирований, на три строчки кода в итоге. А иногда и больше. Самый простой пример. Древовидные комментарии, алгоритм который в DLE самый быстрый из всех конкурирующих CMS, он не делает множественных запросов к БД, не строит дерево с использованием рекурсии. Чтобы придти к этому алгоритму и понять его потребовалось очень много времени, а вылилось это в итоге в 10 строк.

[webair 178]

37 минут назад, celsoft сказал:

Тема, что я дал ссылку является источником для меня. Мне не нужно куда то ходить и смотреть, достаточно посмотреть то что просят, при составлении списка что будет в новой версии.

Может быть возродить http://dle.reformal.ru/ ?

Или сделать такую систему на dle-news.ru

Всё сваливать в одну тему не очень хорошо, сложно искать и поддержать чью то инициативу.

 

Да хотя бы банально сделать это на DLE Новость - инициатива, стандартая система рейтингов, комментариев )

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

 

И каждый может сортировать по популярности / дате / кол-ву комментариев

[celsoft 6 082]

13 минуты назад, webair сказал:

Может быть возродить http://dle.reformal.ru/ ?

Так он работает, я его всегда читаю, и на dle-news.ru ссылка на пожелания также на него.

[SKYNET74 315]

13 часа назад, celsoft сказал:

 Очень смешная фпаза. Ключом массива является то что в этот ключ будет записано. Будет записан в него ключ записи в memcache, то ключем массива будет именно он. И самое смешное вы написали это не видя как это сделано в DLE, а в DLE как раз таки и сделано так, что в служебном массиве ключем является ключ записи с данными в memcache, т.е. вы написали о невозможности того, что как раз и используется в DLE.

Это уже каша, вобщем посмотрим как реализовали по факту, а то уже демагогия начнётся так скоро...

 

13 часа назад, celsoft сказал:

Сразу видно, что вы всегда занимались лишь копированием готового, а не созданием своего с нуля. Поэтому в вашей голове может рождаться только одна мысль. Это имитация деятельности. Когда я пишу, я пишу с нуля, так как по моему мнению является оптимальным, чтобы было меньше нагрузки, чтобы работало максимально быстро и было только то что нужно. И необходимости например {id} я не увидел при создании. Потом когда это появилось и заработало, люди стали обращаться ко мне, и писать, вы знаете мы делаем то то и то то, хотим чтобы было так, и знаете, нам вот этого не хватает для реализации, пожалуйста добавьте. Я вижу что их слова действительно обоснованы и имеют логику, поэтому и добавляю. А у вас только одна мысль в голове, это не добавили, чтобы сделать потом. Это заблуждение. Этого не было изначально, потому что я не счел это необходимым сразу, потому как я изначально не увидел сценария использования.

Если бы вы делали сайты на DLE (а у меня подозрение что вы не используете свой же продукт ), то для большинства случаев сразу бы понимали что нужно добавить, а что ещё под сомнением и нужно подождать реакции потребителей...

 

13 часа назад, celsoft сказал:

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

Вы читали что там написано? Судя по вашему тексту нет, т.к. говорите совсем о другом...
Задача у служебного тега (таймштампа) в массиве записанном в мемкеш лишь одна, это признать устаревшими группу кеша по данному тегу (таймштампу) при наступлении какого то события (например добавили новую новость или отредактировали уже существующую и нужно сбросить записи кеша с префиксом "news_", в которых хранится уже сгенерированный код кратких новостей), и больше ничего другого он делать не должен и не будет. И для проверки актуальности кеша не нужны никакие дополнительные запросы никуда, только лишь получить таймштамп из источника, а его можно хранить в элементарном файле.
Более того, даже если файл источника будет удалён, алгоритм проверки кеша просто его пересоздаст с текущим таймштампом, попутно признав все записи мемкеша с данным тегом сделанные до этого устаревшими (но физически они по прежнему будут дожидаться окончания таймаута хранения).

 

14 часа назад, celsoft сказал:

Вы находитесь на этом форуме постоянно. Просили эту возможность кстати именно в теме на форуме. Вот найдите ее и почитайте. Я сделал ровно то, что попросили. Когда будет пожелания именно по этим тегам, и к ним присоединиться достаточное количество людей, которым это нужно, появятся и они. А пока есть другие желания, которые также нужно делать, и которые давно просят пользователи.

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

 

14 часа назад, celsoft сказал:

Если бы он был таковым. Я был бы рад, но к сожалению это не так. Весь диалог состоит в том что вы бросаете какую либо фразу, и ждете пока перед вами оправдаются, или придумаете то о чем никто не писал, и ждете пока вам это разъяснят. Это не конструктивный диалог. А оправдываться перед вами или обьяснять как и что почему так работает, или разжевывать алгоритмы, мне уже надоело. Это не конструктивный диалог, а пустая трата времени. Поэтому я устраняюсь с этого диалога. Больше не вижу смысла его вести.

Как работает большинство алгоритмов в DLE я и сам как бы знаю...
Зачем мне ваши оправдания? Мне нужно лишь что бы реализации делались полностью, и не на коленке, а полноценно, что бы каждый раз не допиливать то что практически всегда нужно практически на любом адекватном сайте построенном на базе DLE, а то "мартышкин труд" немного наскучивает после апдейтов.

13 часа назад, celsoft сказал:

DLE это не может это сделать для кеша вывода кратких новостей. Да это действительно так. И это сделано было также специально, поэтому как он кеширует в данном случае страницы и блоки целиком в полностью готовом виде. А не каждую краткую новость по отдельности. И я в отличие от вас проводил исследование по этому вопросу, и различного рода тестирования. И кеширование кратких новостей по отдельности, их контроль и в итоге давало большую нагрузку и расходы по памяти и файловым дескрипторам, нагрузку на HDD чем кешировать целиком и сбрасывать также целиком, а потом постепенно пересоздавать их также целиком. Это для вас является недостатком, а для меня это осознанное решение на основе общего тестирования и исследований. Поэтому DLE и является самым быстрым скриптом из всех аналогов, и создает самую низкую нагрузку из всех конкурентов, имея больший набор функций при этом из коробки. Я говорю именно о возможностях из коробки, а не о том что можно сделать потом с парой десятков плагинов. Я никогда ничего не делаю, тщательно не подумав над алгоритмом и что это даст. Иногда может месяц уйти тестирований, на три строчки кода в итоге. А иногда и больше. Самый простой пример. Древовидные комментарии, алгоритм который в DLE самый быстрый из всех конкурирующих CMS, он не делает множественных запросов к БД, не строит дерево с использованием рекурсии. Чтобы придти к этому алгоритму и понять его потребовалось очень много времени, а вылилось это в итоге в 10 строк.

Просто пора уже не рассматривать файловый кеш как что то нужное, это для сайта визитки оно конечно хорошо, но там и без кеша можно вовсе.
Вы видели крупные сайты с файловым кешем? По моему ответ как бы очевиден что использование файлового кеша морально (и не только) устаревшая ветвь развития CMS, куда перспективней видится хранение кеша в быстрой RAM.
Об скорости удаления нескольких тысяч файлов кеша по префиксу я уже вообще молчу, да и на SSD личного сервера не хотелось бы этого делать, когда у него приличное количество RAM.

Ваш алгоритм вывода древовидных комментариев конечно потребляет меньше ресурсов, но и "подводные камни' у него есть, за всё же приходится платить.

[celsoft 6 082]

5 часов назад, SKYNET74 сказал:

Задача у служебного тега (таймштампа) в массиве записанном в мемкеш лишь одна, это признать устаревшими группу кеша по данному тегу (таймштампу) при наступлении какого то события (например добавили новую новость или отредактировали уже существующую и нужно сбросить записи кеша с префиксом "news_", в которых хранится уже сгенерированный код кратких новостей), и больше ничего другого он делать не должен и не будет. И для проверки актуальности кеша не нужны никакие дополнительные запросы никуда, только лишь получить таймштамп из источника, а его можно хранить в элементарном файле.

Что вы так резко перескакиваете с одного на другое? Я вам что про задачи служебного тега писал? Нет не про это. Я вам что комментировал? Я вам комментировал ваше сообщение, где вы написали что в этом алгоритме нет служебных тегов вообще. Вы написали что там нет служебных тегов, и нет обращений к служебному тегу и соответственно экономия времени. Я вам написал что это невозможно и он есть везде, а для каких целей служебный ключ уже роли не играет. И оказался прав. Вы написали нет, служебного ключа, а он по факту есть. Его задачи это уже второстепенны, задачи назначаются в зависимости от того для чего он делается. У него может быть какие угодно задачи. Не надоело уже переиначивать чужие сообщения? Также вам написал что кешировать по отдельности вывод кратких публикаций и последующий контроль, это большая нагрузка чем кеширование страницы целиком, даже несмотря на то что потом придется сбросить все краткие кеши. Это факт, который мне лично известен достоверно, который я уже тестировал. И тот данный алгоритм по сути описывает описывает отдельное кеширование для просмотра полных новостей, а не кеширование и вывод кратких. А отдельное кеширование полных новостей в DLE есть итак, только сделано иначе. 

 

Префикс "news_" не содержит в себе записей полный новостей. Это записи полных готовых блоков кратких новостей. Краткая новость может быть где угодно, на первой странице, на десятой, в категории, в последних новостях, в рандомном блоке  плюсом для разного раздела сайта, у нее может быть назначено разное оформление и т.д. Для того чтобы контролировать контролировать кеширование кратких новостей по отдельности каждой краткой, нужно краткую новость записать отдельно в кеш, т.е. если 10 новостей на странице, сделать это 10 раз, также все блоки по странице пройти, там еще будет с десяток выводов кратких по блокам, еще 10 раз записать каждую по отдельности, у каждого блока свое оформление, значит записать ее в кеш своем оформлении. В другом разделе сайта у них тоже может быть другое оформление, а значит создать еще 10 отдельных копий. Говоря простым языком создать многократно в кеше полную копию БД, что дикий расход по памяти, потом не просто показывать при показе блок, а идти в кеш из 10 разных ключей собирать 10 новостей в блок. Так и только так можно закешировать краткие новости по отдельности, ради одной цели очистить потом только одну новость при изменении информации в нем. Это дикий расход по памяти, это нагрузка на запись кеша по отдельности. Это нагрузка при сборке данных из кеша, т.к. нужно отдельно выбирать из кеша отдельную новость. Подобное кеширование теряет всякую эффективность. Т.к. ресурсы идут на поддержание и контроль кеша, и забивание памяти данными. И если для очень простой функциональности, это можно применить, то для обширной функциональности DLE нет. Поэтому DLE делает проще, он сохраняет страницу целиком, да он не может потом очистить только одну краткую новость, если она изменилась, но он все равно потребляет ресурсов меньше, если бы это делал по отдельности. Я такие тесты провел. А вы нет, и вы мне будете будете объяснять как это нужно делать. Вы сидите просто и статьи читаете, сделать в реальности и проверить и применить это ко всех функциональности DLE даже не пробовали. Я пробовал и знаю о чем говорю. Это алгоритм теория, для маленькой функциональности, и между теорией и практикой для работы с большой функциональностью и большими данными огромная разница.

 

5 часов назад, SKYNET74 сказал:

Просто пора уже не рассматривать файловый кеш как что то нужное, это для сайта визитки оно конечно хорошо, но там и без кеша можно вовсе.
Вы видели крупные сайты с файловым кешем? По моему ответ как бы очевиден что использование файлового кеша морально (и не только) устаревшая ветвь развития CMS, куда перспективней видится хранение кеша в быстрой RAM.
Об скорости удаления нескольких тысяч файлов кеша по префиксу я уже вообще молчу, да и на SSD личного сервера не хотелось бы этого делать, когда у него приличное количество RAM.

Я рассматриваю все с точки зрения того что доступно пользователям скрипта. Далеко не каждому доступен memcache на обычном shared хостинге. Огромное количество хостингов такую возможность не предоставляет. И не мне и уж тем более не вам указывать им какими хостингами пользоваться людям.

5 часов назад, SKYNET74 сказал:

Ваш алгоритм вывода древовидных комментариев конечно потребляет меньше ресурсов, но и "подводные камни' у него есть, за всё же приходится платить.

Видимо эти камни известны только вам. До сих пор мне еще никто не жаловался на проблемы с ним.

5 часов назад, SKYNET74 сказал:

Мне нужно лишь что бы реализации делались полностью, и не на коленке, а полноценно, что бы каждый раз не допиливать то что практически всегда нужно практически на любом адекватном сайте построенном на базе DLE, а то "мартышкин труд" немного наскучивает после апдейтов.

Так зачем вы это делаете? Вы не делайте. Пользуйтесь продуктами где нет "мартышкина труда". Более того вы мастер и профессионал по алгоритмам. Вы напишите собственный продукт, и пользуйтесь только им. Я уверен вы сделаете все лучше. Поэтому я вас не уговариваю пользоваться тем что сделано мной. По вашему глубокому убеждению я не умею делать нормально, поэтому я не понимаю почему вы пришли ко мне и пользуетесь моим продуктом. Всегда удивлялся людям которые приходят у другим, пользуются результатом работы других, и при этом утверждают что их труд полная "фигня", они могут намного лучше, и при этом продолжают пользоваться чужим трудом. Если мне чей то труд не нравится, я им попросту не пользуюсь, но я не учу других как им нужно жить. Поэтому не нужно учить меня, как мне делать. Если мой труд нравится, значит пользуйтесь, не нравиться, кнопка выхода наверху справа. Я буду дальше работать для тех кого моя работа устраивает. Не нужно тратить чужое время и заниматься "мазохизмом". Вас не заставляли и насильно сюда не приводили. Вы уже три года как пользуетесь нелегальной копией скрипта, может быть вместо того чтобы показывать свою "крутизну", приобрете лицензию на использование скрипта, или если вам так не нравится скрипт попросту перестанете им пользоваться? Или вы думали что мне неизвестно что "SOFTOLAB" который пользуется нелегальными копиями и "SKYNET74" это одно и то же лицо? Всегда это было мне известно. Почему не забанил до сих пор, несмотря на явные нарушения? Незнаю, любой на моем месте просто в бан бы вас отправил и все давно. А я еще продолжаю с вами разговаривать, сам не знаю почему. Видимо есть желание исправить человека. Поэтому определяйтесь уже в жизни.

[SKYNET74 315]

20 часов назад, celsoft сказал:

Что вы так резко перескакиваете с одного на другое? Я вам что про задачи служебного тега писал? Нет не про это. Я вам что комментировал? Я вам комментировал ваше сообщение, где вы написали что в этом алгоритме нет служебных тегов вообще. Вы написали что там нет служебных тегов, и нет обращений к служебному тегу и соответственно экономия времени. Я вам написал что это невозможно и он есть везде, а для каких целей служебный ключ уже роли не играет. И оказался прав. Вы написали нет, служебного ключа, а он по факту есть. Его задачи это уже второстепенны, задачи назначаются в зависимости от того для чего он делается. У него может быть какие угодно задачи. Не надоело уже переиначивать чужие сообщения? Также вам написал что кешировать по отдельности вывод кратких публикаций и последующий контроль, это большая нагрузка чем кеширование страницы целиком, даже несмотря на то что потом придется сбросить все краткие кеши. Это факт, который мне лично известен достоверно, который я уже тестировал. И тот данный алгоритм по сути описывает описывает отдельное кеширование для просмотра полных новостей, а не кеширование и вывод кратких. А отдельное кеширование полных новостей в DLE есть итак, только сделано иначе. 

 

Префикс "news_" не содержит в себе записей полный новостей. Это записи полных готовых блоков кратких новостей. Краткая новость может быть где угодно, на первой странице, на десятой, в категории, в последних новостях, в рандомном блоке  плюсом для разного раздела сайта, у нее может быть назначено разное оформление и т.д. Для того чтобы контролировать контролировать кеширование кратких новостей по отдельности каждой краткой, нужно краткую новость записать отдельно в кеш, т.е. если 10 новостей на странице, сделать это 10 раз, также все блоки по странице пройти, там еще будет с десяток выводов кратких по блокам, еще 10 раз записать каждую по отдельности, у каждого блока свое оформление, значит записать ее в кеш своем оформлении. В другом разделе сайта у них тоже может быть другое оформление, а значит создать еще 10 отдельных копий. Говоря простым языком создать многократно в кеше полную копию БД, что дикий расход по памяти, потом не просто показывать при показе блок, а идти в кеш из 10 разных ключей собирать 10 новостей в блок. Так и только так можно закешировать краткие новости по отдельности, ради одной цели очистить потом только одну новость при изменении информации в нем. Это дикий расход по памяти, это нагрузка на запись кеша по отдельности. Это нагрузка при сборке данных из кеша, т.к. нужно отдельно выбирать из кеша отдельную новость. Подобное кеширование теряет всякую эффективность. Т.к. ресурсы идут на поддержание и контроль кеша, и забивание памяти данными. И если для очень простой функциональности, это можно применить, то для обширной функциональности DLE нет. Поэтому DLE делает проще, он сохраняет страницу целиком, да он не может потом очистить только одну краткую новость, если она изменилась, но он все равно потребляет ресурсов меньше, если бы это делал по отдельности. Я такие тесты провел. А вы нет, и вы мне будете будете объяснять как это нужно делать. Вы сидите просто и статьи читаете, сделать в реальности и проверить и применить это ко всех функциональности DLE даже не пробовали. Я пробовал и знаю о чем говорю. Это алгоритм теория, для маленькой функциональности, и между теорией и практикой для работы с большой функциональностью и большими данными огромная разница.

Я как бы не говорил что по отдельности кешировать, хотя это открывает новые возможности, но и нагрузку повышает, всё точто вы написали я как бы и до этого знал...
Я говорил лишь об алгоритме сброса группы кеш-записей, а что в них хранить уже не так важно, можно сформированный HTML, можно массив выборки из БД, да даже изображение можно там хранить...
На текущий момент остаётся только ждать и посмотреть что вы там придумали.

20 часов назад, celsoft сказал:

Я рассматриваю все с точки зрения того что доступно пользователям скрипта. Далеко не каждому доступен memcache на обычном shared хостинге. Огромное количество хостингов такую возможность не предоставляет. И не мне и уж тем более не вам указывать им какими хостингами пользоваться людям.

Если не рассматривать ГСы работающие на нулледе и хосте за пол бакса с паблик шаблонами которые все замусорены скрытыми ссылками, то вполне можно обойтись одним мемкешем, а визиткам у которых 20 новостей и 3 статических страницы вообще кеш как бы и не нужен особо, это на случай если мемкеша для сайта-визитки жалко. Раньше одним НО было неэффективное управление кешем (скидывался весь даже при выставлении рейтинга комментарию), то сейчас поводов отказываться от мемкеша у более менее нормального сайта нет. Тем более что с ним он меньше нагружает железо и быстрее отдаёт результат клиентам. Сколько не работал с проектами на DLE, практически все могут позволить себе обзавестись им, а если на одном мемкеш сервере можно держать теперь разные кеши сайтов, то тем более.

20 часов назад, celsoft сказал:

Видимо эти камни известны только вам. До сих пор мне еще никто не жаловался на проблемы с ним.

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

20 часов назад, celsoft сказал:

Так зачем вы это делаете? Вы не делайте. Пользуйтесь продуктами где нет "мартышкина труда". Более того вы мастер и профессионал по алгоритмам. Вы напишите собственный продукт, и пользуйтесь только им. Я уверен вы сделаете все лучше. Поэтому я вас не уговариваю пользоваться тем что сделано мной. По вашему глубокому убеждению я не умею делать нормально, поэтому я не понимаю почему вы пришли ко мне и пользуетесь моим продуктом. Всегда удивлялся людям которые приходят у другим, пользуются результатом работы других, и при этом утверждают что их труд полная "фигня", они могут намного лучше, и при этом продолжают пользоваться чужим трудом. Если мне чей то труд не нравится, я им попросту не пользуюсь, но я не учу других как им нужно жить. Поэтому не нужно учить меня, как мне делать. Если мой труд нравится, значит пользуйтесь, не нравиться, кнопка выхода наверху справа. Я буду дальше работать для тех кого моя работа устраивает. Не нужно тратить чужое время и заниматься "мазохизмом". Вас не заставляли и насильно сюда не приводили. Вы уже три года как пользуетесь нелегальной копией скрипта, может быть вместо того чтобы показывать свою "крутизну", приобрете лицензию на использование скрипта, или если вам так не нравится скрипт попросту перестанете им пользоваться? Или вы думали что мне неизвестно что "SOFTOLAB" который пользуется нелегальными копиями и "SKYNET74" это одно и то же лицо? Всегда это было мне известно. Почему не забанил до сих пор, несмотря на явные нарушения? Незнаю, любой на моем месте просто в бан бы вас отправил и все давно. А я еще продолжаю с вами разговаривать, сам не знаю почему. Видимо есть желание исправить человека. Поэтому определяйтесь уже в жизни.

Вот вы опять передёргиваете, где я сказал что "DLE унылое кафно которое настолько никчёмно что им ваще низя пользоваться"?
Оно просто сырое, функции не доработаны, без доработки большинство "фич" не совсем удобны, многое из того что я вам присылал вы всё таки реализовали (список так то огромный, мелочи, но юзабилити повышается), видать всё таки убедил как то.
И может покажите мои сайты с пиратскими копиями скрипта? А то я просто давно их сам не видел, видимо потому что у меня нет своих сайтов на DLE уже много лет, а старые лицензии до сих пор как бы не отвязаны от доменов, которых уже к слову тоже давно нет в живых...
Для работы с кодом DLE по "заказу" ваших же клиентов тоже лицензию приобретать мне предлагаете?

[Datagor 31]

Уважаемый хозяин этого форума!

Вам оправдываться смешно и не нужно.

Просим: не тратье ваше драгоценное время.