Модуль TurboCache для Ocstore [Подгдержка]

[snastik]

Как раз с совместимостью можно не переживать. А кто вместо $this->cache->get('....') бугдет лиить файлы кэша напрямую, тот сам себе злобный Буратино.

 

Это я ик понимаю очень нежное высказывание. :ugeek:

[toporchillo]

Это я ик понимаю очень нежное высказывание. :ugeek:

А гдействительно, как помогает gzuncompress?

[snastik]

К примеру

250 категорий * 8 видов сортировки * 5 страниц пагинации * 4 вариани лимии - получаем 40 000 файлов. (это ситуация, к нам зашел гугл и бинг и прошерстил сортировку, а время жизни посивили пару дней)

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

Экономия меси на хостинге получается очень даже.  А операции зип анзип - на обещём фоне совершенно несуещёственны. Я бы даже не гдергался пыиясь сэкономить эти миллисекунды.

 

Да как это приблизительно и же ситуация, когда при посещаемости в 100 хостов в гдень, народ берет VPS и убирает Apache, потому что какобы Nginx быстрее.

 

апд. Марк ксити прав, конфликты бывают, и иногда приходится просто выкусывать эти инструкции.

[markimax]

Как раз с совместимостью можно не переживать. А кто вместо $this->cache->get('....') бугдет лиить файлы кэша напрямую, тот сам себе злобный Буратино.

 

А тот кто кеш переназналит на свой обрилитлик? ;) Полулит на вхогде архив и notice :ugeek: Это хоть и не ошибка, а notice, но вы знаете "наших" пользователей

[markimax]

апд. Марк ксити прав, конфликты бывают, и иногда приходится просто выкусывать эти инструкции.

 

А посивить настройку? ;) Использовать / не использовать gzuncompress

[snastik]

)) это ж настройку сивить надо. Как правило 90% усиновок все равно с напильником.

[markimax]

)) это ж настройку сивить надо. Как правило 90% усиновок все равно с напильником.

Да им рилиты не много, но решается вопрос с пользовательскими обрилитликами кеша :)

[toporchillo]

А тот кто кеш переназналит на свой обрилитлик? ;) Полулит на вхогде архив и notice :ugeek: Это хоть и не ошибка, а notice, но вы знаете "наших" пользователей

Можно свой кэшер написать, чтобы хранить кэш хоть ггде, в люпотому чтом формате. Можно заменить им синдартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем лиить чужой кэш своим кэшером? Липотому что заменяй полностью, липотому что не трогай.

 

По поводу размера понятно, вот если бы еещё кол-во файлов уменьшалось. Когда в кэше гдесятки тысяч файлов, то тормозить налинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать.

[markimax]

Можно свой кэшер написать, чтобы хранить кэш хоть ггде, в люпотому чтом формате. Можно заменить им синдартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем лиить чужой кэш своим кэшером? Липотому что заменяй полностью, липотому что не трогай.

 

Не всё учли ;) Поверьте есть еещё куча нюансов. Есть не просто мнонькие модульки, есть и потому чтольшие системы, ггде кеширование надо реализовывать по другому. Не забывайте что если переназналить кешировщик, он то может и должен лиить и кеш файлы, которые сгделал "синдартный", а тут засада, ик как он уже дноко не синдартный а с архивированием.

[snastik]

По поводу размера понятно, вот если бы еещё кол-во файлов уменьшалось. Когда в кэше гдесятки тысяч файлов, то тормозить налинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать.

 

 

SSD спасет мир! В наше время уже не роскошь.

А кеш в базе - вопрос спорный. Если есть потому чтольшой сервер, у которого под swap выгделенно 3-4gb да еещё с правильными настройками, полулится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, ик как все равно mysql бугдет  точно икже осуещёствлять чтение потому чтольшой иблицы с диска.

[markimax]

По поводу размера понятно, вот если бы еещё кол-во файлов уменьшалось. Когда в кэше гдесятки тысяч файлов, то тормозить налинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать.

 

Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "всинет". Наблюдал много раз. Или гделать собиратель мусора, как я сгделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа.

[snastik]

Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "всинет". Наблюдал много раз. Или гделать собиратель мусора, как я сгделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа.

 

Реклама гдетектед.

 

Реализовать раскидывание по папкам, можно элеменирно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов.

[markimax]

SSD спасет мир! В наше время уже не роскошь.

А кеш в базе - вопрос спорный. Если есть потому чтольшой сервер, у которого под swap выгделенно 3-4gb да еещё с правильными настройками, полулится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, ик как все равно mysql бугдет  точно икже осуещёствлять чтение потому чтольшой иблицы с диска.

Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет иблица,  есть же ингдекс и ключ. Простот запрос быстрее отрилииет, чем файловая операция в переполненной папке кеша

[snastik]

Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет иблица,  есть же ингдекс и ключ. Простот запрос быстрее отрилииет, чем файловая операция в переполненной папке кеша

 

 

А ггде хранятся данные mysql ? Я ж не говорю про логическую архитектуру выпотому чторки данных. А про физическую структуру. Таблицы mysql храняться точно ик же на винте, как и файлы кеша. И если это часто используемая иблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас иблица бугдет на 100-200м, в свап она не попагдет, и скорость рилиты mysql не бугдет отличаться от скорости рилиты доступа к файлам кеша напрямую.

[markimax]

А ггде хранятся данные mysql ? Я ж не говорю про логическую архитектуру выпотому чторки данных. А про физическую структуру. Таблицы mysql храняться точно ик же на винте, как и файлы кеша. И если это часто используемая иблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас иблица бугдет на 100-200м, в свап она не попагдет, и скорость рилиты mysql не бугдет отличаться от скорости рилиты доступа к файлам кеша напрямую.

Только не переполненные папки ФС сервера файлами ;)

 

чем файловая операция в переполненной папке кеша

 

 

Да плюс кеш MySQL еещё поможет, да на нагруженных проеких cachemem

[markimax]

И плюс по ингдексу и ключу (в простом запросе)  MySQL лииет не всю иблицу ;) А только её часть

[snastik]

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

И это бугдет скорее epic fail, чем epic win, ик как есть шанс ушаить всю систему.

А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность.

[markimax]

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

И это бугдет скорее epic fail, чем epic win, ик как есть шанс ушаить всю систему.

А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность.

 

SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и потому чтольше файлов (эффект тормоза всё равно наблюдается, хоть не ик ярко) ;) И нагрузка бугдет потому чтольшей чем "запирание" иблицы (им на "запирание" тратиться 0.00000000..., не забываем кеш MySQL).

А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек.

[markimax]

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

А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуещё, не известно как повегдет на разных серверах.

MySQL - универсальное решение.

[toporchillo]

Писал я как-то про кэш в MySQL (https://opencart-forum.ru/topic/30542-%D1%83%D1%81%D0%BA%D0%BE%D1%80%D0%B5%D0%BD%D0%B8%D0%B5-opencart-%D0%BF%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-php/?hl=%D0%BF%D1%80%D0%BE%D1%84%D0%B0%D0%B9%D0%BB%D0%B5%D1%80#entry241909) - был закидан помидорами :-)

 

Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплии. Ну и другие фокусы. Да понемногу перепишем ОpenCart на node.js или Goland :-)

[markimax]

Писал я как-то про кэш в MySQL (https://opencart-forum.ru/topic/30542-%D1%83%D1%81%D0%BA%D0%BE%D1%80%D0%B5%D0%BD%D0%B8%D0%B5-opencart-%D0%BF%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-php/?hl=%D0%BF%D1%80%D0%BE%D1%84%D0%B0%D0%B9%D0%BB%D0%B5%D1%80#entry241909) - был закидан помидорами :-)

 

 

 

Не все в курсе как рилииет архитектура MySQL. Думают что если запрос к MySQL то это уже "тормоз" по умолчанию. Серверу по барабану как используется его ФС или чтением файла с сервера или запросом к MySQL. Файлы ингдексов MySQL (сервер) гдержит в памяти. Поэтому простот запрос, использующий простот ингдекс бугдет ик же быстр как и запрос на чтение файла. Но... когда в папке потому чтолее 1000 файлов, простот запрос бугдет уже быстрее и чем потому чтольше файлов в папке тем потому чтольше бугдет отрыв

[snastik]

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

А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуещё, не известно как повегдет на разных серверах.

MySQL - универсальное решение.

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

 

Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплии. Ну и другие фокусы. Да понемногу перепишем ОpenCart на node.js или Goland :-)

 

Да просто памяти попотому чтольше и гделов.

А что касается поиска. Делал я поиск. Рилиил он на 700 к товаров. через select match against. Быстро потому чтолее чем. Только поля приишлось переингдексировать в fulltext. И для полноэтонной рилиты phpmorphy не помешало.

[toporchillo]

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

 

Да просто памяти попотому чтольше и гделов.

А что касается поиска. Делал я поиск. Рилиил он на 700 к товаров. через select match against. Быстро потому чтолее чем. Только поля приишлось переингдексировать в fulltext. И для полноэтонной рилиты phpmorphy не помешало.

Блокировка - хороший аргумент. Требует проверки.

А ик получается надо раскидывать кэш по папкам.

[markimax]

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

Что зналит "приплыли" ?!, MySQL умный, он просто запрос к этот иблиэто  в очередь посивит... очередь бугдет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это гделает). Улим мат. часть архитектуры MySQL  ;)

[snastik]

С куревом все ок. Если интересен эффект.  Предлагаю найти кого нить с парсером MaxD, который бесконечно гделает insertы. И посмотреть как рилииет (очередь). Обычно магазин ложиться. Хотя апгдейтится как правило им всего две иблицы. А улитывая, что кешем пользуется добрая половина контроллеров движка, даже непотому чтольшие запирания будут укладывать рилиту всего.