Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

Recommended Posts

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

Надіслати
Поділитися на інших сайтах

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

 

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

Надіслати
Поділитися на інших сайтах

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

 

 

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

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

Надіслати
Поділитися на інших сайтах

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

 

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

Надіслати
Поділитися на інших сайтах

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

 

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

 

 

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

 

 

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

Надіслати
Поділитися на інших сайтах

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

 

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

 

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

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

Надіслати
Поділитися на інших сайтах

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

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

Надіслати
Поділитися на інших сайтах

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

Надіслати
Поділитися на інших сайтах

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

 

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

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

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

 

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

 

А в opencart- ENGINE=MyISAM

Надіслати
Поділитися на інших сайтах

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

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

Надіслати
Поділитися на інших сайтах

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

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

 

Будет но .

 

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

 

 

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

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

 

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

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

 

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

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

 

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

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

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

 

 

 

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

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

 

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

Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.