Перейти к содержимому


- - - - -

Папка cache


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 8

#1 RaSH

RaSH

    Новичок

  • Пользователи
  • Pip
  • 3 сообщений

Отправлено 10.02.2010, 13:06

Здравствуйте. На сайте стоит Zebrum Lite 2.0 . Можно ли отключить создание кэш файлов? Занимает много места на хостинге. Всего ~ 500 страниц было создано, весом 19мб. А папка с кэшом весит 35мб. Удаляю кэш, ставлю 666, а файлы все равно создаются, и меняются права папки на 777. Как решить эту проблему? Работает ли Lite 2.0 без создания кэш файлов?

#2 support

support

    Активный участник

  • Главные администраторы
  • PipPipPip
  • 1 140 сообщений

Отправлено 10.02.2010, 14:02

Можно в настройках вместо zcache_backend_file указать zcache_backend_mem (опция cache.backend), но это значительно снизит производительность сайта.

#3 RaSH

RaSH

    Новичок

  • Пользователи
  • Pip
  • 3 сообщений

Отправлено 10.02.2010, 14:25

А полностью отключить создание кэш файлов никак?

Так же есть 2 сайт на Zebrum Lite. правда уже более ранняя версия.
Добавил при помощи parser.php новые страницы. Статей около 700. + имеющиеся 400. Сайт начал выводить Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 342749 bytes) in /home/user/domains/site.ru/public_html/zengine/classes/zsource/txt.php on line 184
Т.е нехватка места? Нашел похожую проблему и ее решение.

Цитата

Можно попробовать в файле .htaccess прописать строчку:

php_value memory_limit 32M

Прописывать в основной директории сайта?

#4 support

support

    Активный участник

  • Главные администраторы
  • PipPipPip
  • 1 140 сообщений

Отправлено 10.02.2010, 14:56

Просмотр сообщенияRaSH (10.02.2010, 14:25) писал:

А полностью отключить создание кэш файлов никак?
Как это сделать см. ответ выше. Конечно, уже созданные файлы удаляются ручками (или скриптом).

Просмотр сообщенияRaSH (10.02.2010, 14:25) писал:

Так же есть 2 сайт на Zebrum Lite. правда уже более ранняя версия.
Добавил при помощи parser.php новые страницы. Статей около 700. + имеющиеся 400. Сайт начал выводить Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 342749 bytes) in /home/user/domains/site.ru/public_html/zengine/classes/zsource/txt.php on line 184
Т.е нехватка места? Нашел похожую проблему и ее решение.

Прописывать в основной директории сайта?
Да, нехватка оперативной памяти, только вместо 32M лучше уже прописывать 128M.

#5 RaSH

RaSH

    Новичок

  • Пользователи
  • Pip
  • 3 сообщений

Отправлено 10.02.2010, 15:34

Спасибо. Проблема решена.

#6 TruLander

TruLander

    Новичок

  • Пользователи Zebrum CMS
  • Pip
  • 9 сообщений
  • Город: Оренбург
  • Спелеология, програмирование, радиоэлектроника

Отправлено 12.03.2010, 05:25

Здравствуйте.
не стал создавать отдельную тему, хотел высказать пожелания по поводу кеширования и указать на лучший как мне кажется вариант.
зачем кешировать контент полностью? ведь это занимает дополнительно место на хостинге, да при том кеш занимает места в несколько раз больше чем сам контент - это совсем нехорошо((.
я не понимаю смысл такого полного кеширования, ведь разницы практически никакой к какому файлу будет обращаться движок, или к кешу или к самой статье, причем к кешу обращается движок не к одному файлу, а к нескольким что увеличивает время генерации страницы.
Пробовал менять просто файловое кеширование на sqlite - время генерации увеличилось в 2 раза, менял на mem увеличилось в 2 раза по сравнению с простым.
я веду к тому чтобы переделать систему кеша - конечно это решение разработчиков...
Для сравнения я смотрел время генераци страниц на разных файловых движках где кеширование нормальное!! это были neutrino atomic edition с количеством записей в нем около 11500 - время генерации одной страници составляет ~50мс больше чем в Zebrum Lite(все дефолтные статьи) ~25мс в 2 раза, но при генерации страници в 80 постами одновременно генерация увеличилась в 4 раза и составила ~210мс. меня поразил результат в движке satellite-x время генерации ~6мс (всего ~80 статей)причем не важно одна страница это или десять.
В этих движках статьи не дублируются в кеше, в него добавляется лишь информация для построения меню.
Это просто мое пожелание для дальнейшего развития этой cms. Может я не прав - хочу услышать мнение об этом.

#7 support

support

    Активный участник

  • Главные администраторы
  • PipPipPip
  • 1 140 сообщений

Отправлено 12.03.2010, 15:06

Просмотр сообщенияTruLander (12.03.2010, 05:25) писал:

Здравствуйте.
не стал создавать отдельную тему, хотел высказать пожелания по поводу кеширования и указать на лучший как мне кажется вариант.
зачем кешировать контент полностью? ведь это занимает дополнительно место на хостинге, да при том кеш занимает места в несколько раз больше чем сам контент - это совсем нехорошо((.
я не понимаю смысл такого полного кеширования, ведь разницы практически никакой к какому файлу будет обращаться движок, или к кешу или к самой статье, причем к кешу обращается движок не к одному файлу, а к нескольким что увеличивает время генерации страницы.
Пробовал менять просто файловое кеширование на sqlite - время генерации увеличилось в 2 раза, менял на mem увеличилось в 2 раза по сравнению с простым.
я веду к тому чтобы переделать систему кеша - конечно это решение разработчиков...
Для сравнения я смотрел время генераци страниц на разных файловых движках где кеширование нормальное!! это были neutrino atomic edition с количеством записей в нем около 11500 - время генерации одной страници составляет ~50мс больше чем в Zebrum Lite(все дефолтные статьи) ~25мс в 2 раза, но при генерации страници в 80 постами одновременно генерация увеличилась в 4 раза и составила ~210мс. меня поразил результат в движке satellite-x время генерации ~6мс (всего ~80 статей)причем не важно одна страница это или десять.
В этих движках статьи не дублируются в кеше, в него добавляется лишь информация для построения меню.
Это просто мое пожелание для дальнейшего развития этой cms. Может я не прав - хочу услышать мнение об этом.
Здравствуйте,

Прежде чем вдаваться в дискуссии по поводу использования кэша проясним некоторые моменты. Мы открыты для конструктивных предложений по изменению различных частей движка, в том числе и работы с кэшем. Поэтому если будут какие-либо конкретные предложения, то пишите на support@zebrum.ru, обсудим их плюсы/минусы и возможность внедрения в лайте.

Начнем с того, что кэш в Zebrum Lite 2.0 не является кэшем в "чистом виде". Он скорее используется как репозиторий для хранения всех страниц, связанных с ними информации и структуры. После заполнения репозитория страницами из папки pages, движок не обращается к ней. Вся необходимая информация, в том числе и будущие публикации, хранятся в репозитории.

В репозитории страницы хранятся в виде сериализированных объектов + массивов объектов с их кратким описанием для построения меню. Вся структура меню целиком не хранится - это очень накладно.

Дополнительно, могут создаваться списки страниц по каким-либо критериям (например, в дистрибутиве есть списки по тэгам, времени последней публикации). Эти списки могут динамически пополняться в момент наступления времени публикации очередной страницы. И эти списки можно добавлять без изменения ядра! Хотите помимо тэгов использовать категории? Пожалуйста! Все, что требуется, это создать класс по образу и подобию класса ztaxonomy_tags, прописать его в настройках движка. После постоения индекса сайта в репозитории будет информация о всех категориях и страницах, которыые к ним относятся. Останется только скопировать модуль тэгов, заменить использование тэгов на категории и будут категории.

Почему в репозитории дублируется контент страницы? Вообще-то он не совсем дублируется. Перед добавлением объекта страницы в репозиторий к ней применяются преобразователи (ztransform), которые могут добавлять какие-либо новые свойства странице и/или изменять текст страницы (например, ztransform_split, который может делить текст страницы на подстраницы). Это происходит один раз в момент добавления страницы в репозиторий и преобразователи можно создавать свои, неизменяя ядра системы. Конечно, контент можно было бы брать и из папки pages и парсить его перед выводом, но тогда возникает вопрос - как узнать количество подстраниц у конкретной страницы? Придется открывать страницу и применять к ней все преобразователи.

Все это, как и некоторые другие моменты (например, попытка ограничить потребление оперативной памяти), замедляют время создания индекса, но позволяют значительно быстрее генерировать страницу, чем это было в 1.1.4, где использовался именно временный кэш.

Теперь о разнице между sqlite, mem и files для хранения кэша. Эти классы используются исключительно для хранения репозитория в неоптимизированном виде.

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

zcache_backend_factory_sqlite - экспериментальный вариант, т.к. существуют некоторые проблемы при его использовании. Тесты показали, что files выгоднее использовать в качестве бэкэнда кэша. Хочу отметить, что здесь используется sqlite как хранилище сериализованных объектов, а не как база данных репозитория (что в будущем хотелось бы реализовать).

zcache_backend_files - самый оптимальный вариант, и по быстродействию, и по потреблению памяти при построении индекса.

Теперь что касается скорости работы. К чему относится "но при генерации страници в 80 постами одновременно генерация увеличилась в 4 раза и составила ~210мс"? Если к Zebrum Lite, то 210мс в 8 раз больше 25мс и, скорее всего, здесь речь идет о времени создания индекса?

Для Zebrum Lite 2 при построенном индексе это странные цифры, т.к. согласно моим исследованиям (http://zebrum.ru/for...findpost&p=3129) разница по времени генерации страницы сайта из 20 страниц и сайта из 12 тыс. страниц в пределах погрешности (порядка 5%).

Опять же, на одном из наших сайтов, работающих на Zebrum Lite 2, СДЛ, с хорошими показателями и трастом, порядка 1000 страниц и порядка 10000 хитов в день (дополнительно 3000 хитов приходится на 301 редирект и 404 ошибки). Среднее время генерации страницы составляет порядка 50 мс. 92% всех запросов уложились в 100мс, 82% - <50мс, 65% - от 20мс до 30мс.

При генерации страниц не используется кэш каких-то конкретных кусков страницы в HTML-код (облака тэгов или меню), поэтому при желании скорость работы движка можно увеличить, но это зависит от используемого шаблона и условий эксплуотации и приведет к росту объема кэша.

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

#8 TruLander

TruLander

    Новичок

  • Пользователи Zebrum CMS
  • Pip
  • 9 сообщений
  • Город: Оренбург
  • Спелеология, програмирование, радиоэлектроника

Отправлено 12.03.2010, 17:09

Цитата

Тестовый сайт на 12 тыс. страниц

12 тыс. страниц это 78Мб текста в папке pages, порядка 4 тыс. тэгов, по 5-10 тэгов на страницу, 40 минут построения индекса, memory_limit=392M, размер индекса 275Мб.

После построения индекса время генерации страницы для 12 тыс. на 2.0 незначительно больше, чем при генерации страниц сайта из 20 страниц. Если у меня генерация страницы занимает 22 мс для 20 страниц, то для 12 тыс. ~ 22-23 мс. Конечно, это зависит от разветвленности структуры сайта и генерируемой страницы сайта.

Даже если на сайте есть отложенные публикации, то добавление их в индекс пройдет автоматически без его полного перестроения. Перестроить индекс потребуется только после добавления/правки старницы вручную (в будущих версиях и это будет упрощено). Так же индекс будет автоматически перестроен при изменении config.ini.
а в какой кодировке вы использовали текст? ,текст в utf8 в 2 раза больше весит нежели в 1251.

Ко времени генерации страниц не имею никаких претензий, просто приводил примеры для сравнения с разными движками и то как у них строится кеширование. ))) 23мс - не плохое время, но построение индекса 40 мин это конечно слишком, вообще редко кто делает сайты на таких движках с таким количеством страниц и 40мин это частный случай.

Цитата

Почему в репозитории дублируется контент страницы? Вообще-то он не совсем дублируется. Перед добавлением объекта страницы в репозиторий к ней применяются преобразователи (ztransform), которые могут добавлять какие-либо новые свойства странице и/или изменять текст страницы (например, ztransform_split, который может делить текст страницы на подстраницы). Это происходит один раз в момент добавления страницы в репозиторий и преобразователи можно создавать свои, неизменяя ядра системы. Конечно, контент можно было бы брать и из папки pages и парсить его перед выводом, но тогда возникает вопрос - как узнать количество подстраниц у конкретной страницы? Придется открывать страницу и применять к ней все преобразователи.
Можно просто миновать папку pages и сразу оставлять контент в преобразованном виде. т.е в процессе парсинга файла со статьями сразу и строить индекс. это сэкономит место на хостинге.

zcache_backend_factory_sqlite - у меня не стало работать, я прописал zcache_backend_sqlite в конфиге.
Я не знаю откуда взял что sqlite дольше генерируется чем при простом кешировании, у меня результаты были лучше с sqlite на ~3мс чем files.

Цитата

Теперь что касается скорости работы. К чему относится "но при генерации страници в 80 постами одновременно генерация увеличилась в 4 раза и составила ~210мс"? Если к Zebrum Lite, то 210мс в 8 раз больше 25мс и, скорее всего, здесь речь идет о времени создания индекса?
Это относилось к neutrino atomic edition при пагинации страниц по 80 постов на каждой. и речь идет не о создании индекса, а просто полной генерации страницы.

Цитата

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

согласен я сравнивал неправильно, но всеже у этого большого сайта на ntutrino контент занимает 30мб в кодировке windows1251.
Мне больше понравились результаты на движке sat-x там конечно нет облака тегов, нет меток, нет последних статей в виржите, но отображаються последние записи на главной странице как на блогах, там просто страницы разбиты по рубрикам и каждая страница также делиться по заданному количеству символов, там есть форма для отправки коментариев даже работает)).
сектет быстрой генерации страниц там заключается в том что кешируется информация только о построении меню навигации - какая статья относиться к той или иной рубрике, а все остальное парситься из файлов статей. и построение кеша страниц там происходит гораздо быстрее. если парсить постоянно контент с файлов, то тут отпадает проблема при редактировании статей на сайте т.к кеш заново перестраивать не приходиться.

#9 support

support

    Активный участник

  • Главные администраторы
  • PipPipPip
  • 1 140 сообщений

Отправлено 12.03.2010, 17:29

Просмотр сообщенияTruLander (12.03.2010, 17:09) писал:

а в какой кодировке вы использовали текст? ,текст в utf8 в 2 раза больше весит нежели в 1251.
По умолчанию используется UTF-8, в случае теста тексты были латинскими буквами (т.е. один байт на один символ). При желании можно создавать сайты в 1251.

Просмотр сообщенияTruLander (12.03.2010, 17:09) писал:

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

Просмотр сообщенияTruLander (12.03.2010, 17:09) писал:

zcache_backend_factory_sqlite - у меня не стало работать, я прописал zcache_backend_sqlite в конфиге.
Я не знаю откуда взял что sqlite дольше генерируется чем при простом кешировании, у меня результаты были лучше с sqlite на ~3мс чем files.
Скорее всего, неправильно выразился. Если использовать zcache_backend_sqlite (PHP модуль sqlite), то количество страниц на сайте ограничено - лимит на размер единицы кэша ограничен в 1Мб. Если испоользовать zcache_backend_pdosqlite (PHP модуль pdo_sqlite), то при генерации индекса затрачивается значительно больше памяти, чем при использовании файлов (проверка велась на тестовом сайте с 12 тыс. страниц).

Просмотр сообщенияTruLander (12.03.2010, 17:09) писал:

Мне больше понравились результаты на движке sat-x там конечно нет облака тегов, нет меток, нет последних статей в виржите, но отображаються последние записи на главной странице как на блогах, там просто страницы разбиты по рубрикам и каждая страница также делиться по заданному количеству символов, там есть форма для отправки коментариев даже работает)).
сектет быстрой генерации страниц там заключается в том что кешируется информация только о построении меню навигации - какая статья относиться к той или иной рубрике, а все остальное парситься из файлов статей. и построение кеша страниц там происходит гораздо быстрее.
если парсить постоянно контент с файлов, то тут отпадает проблема при редактировании статей на сайте т.к кеш заново перестраивать не приходиться.
Предположим, что к странице добавляется пара тэгов и меняется название пункта меню. Что в этом случае должно произойти? Если оставлять в файле только контент, то ни тэги, ни название пункта изменены не будут. А если это название пункта фигурирует в нескольких списках (меню, тэги, последние записи)? Поэтому было принято решение, что весь контент переносится в индекс - исчезает потребность читать второй файл с содержимым (особенно, если на главной выводятся несколько записей).

На самом деле если считать, что создание кэша происходит без сбоев и не требуется его перестраивать (в идеале это база данных), то можно применять инкрементный индекс - обновлять в индексе только те страницы, которые были изменены/удалены/добавлены. Это позволит значительно уменьшить скорость переиндексации при добавлении страницы или изменении существующей. Тем более, что методы для добавления, изменения и удаления страниц из репозитория реализованы.




Количество пользователей, читающих эту тему: 2

0 пользователей, 2 гостей, 0 скрытых пользователей