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

[markimax]

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

 

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

[snastik]

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

[markimax]

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

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

[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 - универсальное решение.

[markimax]

Писал я как-то про кэш в MySQL (https://opencartforum.com/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 не помешало.

[markimax]

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

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

[snastik]

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

[markimax]

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

 

Насколько я помню у вас "один" кеш (запись)  содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п.

Но не в этом суть :)

И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html

 

В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций.

 

А в opencart- ENGINE=MyISAM

[snastik]

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

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

[markimax]

Не ссорьтесь, мальчики. Используем INSERT DELAYED

При обычном INSERT блокировка будет

 

Будет но .

 

В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций.

 

 

Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :)

К тому же всегда можно сделать отложенный insert

[markimax]

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

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

Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов.

Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого!

[snastik]

Не ссорьтесь, мальчики. Используем INSERT DELAYED

При обычном INSERT блокировка будет

Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock

 

Пробовали, знаем. Все бы было хорошо, если бы было так просто.

Отрубаются моментом все last id.

 

Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates.

Но проблемы не снимает.

 

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

[markimax]

SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID.

Если дисковый кэш, то разделяем по подпапкам.

Иначе MySQL. Оба случая требуют трудозатрат.

 

Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит.

 

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

[snastik]

SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID.

Если дисковый кэш, то разделяем по подпапкам.

Иначе MySQL. Оба случая требуют трудозатрат.

 

Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит.

 

Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает.

Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20].

А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить.

 

 

 

Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов.

Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого!

 

Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет.