markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 апд. Марк кстати прав, конфликты бывают, и иногда приходится просто выкусывать эти инструкции. А поставить настройку? ;) Использовать / не использовать gzuncompress Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 )) это ж настройку ставить надо. Как правило 90% установок все равно с напильником. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 )) это ж настройку ставить надо. Как правило 90% установок все равно с напильником. Да там работы не много, но решается вопрос с пользовательскими обработчиками кеша :) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Можно свой кэшер написать, чтобы хранить кэш хоть где, в любом формате. Можно заменить им стандартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем читать чужой кэш своим кэшером? Либо заменяй полностью, либо не трогай. Не всё учли ;) Поверьте есть еще куча нюансов. Есть не просто маленькие модульки, есть и большие системы, где кеширование надо реализовывать по другому. Не забывайте что если переназначить кешировщик, он то может и должен читать и кеш файлы, которые сделал "стандартный", а тут засада, так как он уже далеко не стандартный а с архивированием. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 )) это ж настройку ставить надо. Как правило 90% установок все равно с напильником. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 )) это ж настройку ставить надо. Как правило 90% установок все равно с напильником. Да там работы не много, но решается вопрос с пользовательскими обработчиками кеша :) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Можно свой кэшер написать, чтобы хранить кэш хоть где, в любом формате. Можно заменить им стандартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем читать чужой кэш своим кэшером? Либо заменяй полностью, либо не трогай. Не всё учли ;) Поверьте есть еще куча нюансов. Есть не просто маленькие модульки, есть и большие системы, где кеширование надо реализовывать по другому. Не забывайте что если переназначить кешировщик, он то может и должен читать и кеш файлы, которые сделал "стандартный", а тут засада, так как он уже далеко не стандартный а с архивированием. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 )) это ж настройку ставить надо. Как правило 90% установок все равно с напильником. Да там работы не много, но решается вопрос с пользовательскими обработчиками кеша :) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Можно свой кэшер написать, чтобы хранить кэш хоть где, в любом формате. Можно заменить им стандартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем читать чужой кэш своим кэшером? Либо заменяй полностью, либо не трогай. Не всё учли ;) Поверьте есть еще куча нюансов. Есть не просто маленькие модульки, есть и большие системы, где кеширование надо реализовывать по другому. Не забывайте что если переназначить кешировщик, он то может и должен читать и кеш файлы, которые сделал "стандартный", а тут засада, так как он уже далеко не стандартный а с архивированием. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Можно свой кэшер написать, чтобы хранить кэш хоть где, в любом формате. Можно заменить им стандартный system/library/cache.php, или использовать параллельно со своими данными. Но зачем читать чужой кэш своим кэшером? Либо заменяй полностью, либо не трогай. Не всё учли ;) Поверьте есть еще куча нюансов. Есть не просто маленькие модульки, есть и большие системы, где кеширование надо реализовывать по другому. Не забывайте что если переназначить кешировщик, он то может и должен читать и кеш файлы, которые сделал "стандартный", а тут засада, так как он уже далеко не стандартный а с архивированием. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 По поводу размера понятно, вот если бы еще кол-во файлов уменьшалось. Когда в кэше десятки тысяч файлов, то тормозить начинает люто. Из-за банального поиска файла в заполненной директории. Кэш в MySQL уже быстрее получается. Большой кэш уже надо структурировать? например по папкам раскидывать. Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Совершенно верно. Надо раскидывать по папкам. Иначе на 1000 файлов, файловая система сервера просто "встанет". Наблюдал много раз. Или делать собиратель мусора, как я сделал у себя при кешировании ajax виджетов, просто через какое-то время 10-20 минут, удаляются все файлы кеша этого ключа. Реклама детектед. Реализовать раскидывание по папкам, можно элементарно, через первые два символа md5 ключа. Но опять же - актуально только для sas винтов. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD спасет мир! В наше время уже не роскошь. А кеш в базе - вопрос спорный. Если есть большой сервер, у которого под swap выделенно 3-4gb да еще с правильными настройками, получится отличное решение. А если шаред-хост - те же тестикулы, только в профиль, так как все равно mysql будет точно также осуществлять чтение большой таблицы с диска. Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Да нет как раз :) MySQL -лю при простом запросе (select val from table where var=queryval ) по барабану какой размер имеет таблица, есть же индекс и ключ. Простой запрос быстрее отработает, чем файловая операция в переполненной папке кеша А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 А где хранятся данные mysql ? Я ж не говорю про логическую архитектуру выборки данных. А про физическую структуру. Таблицы mysql храняться точно так же на винте, как и файлы кеша. И если это часто используемая таблица, linux перемещает ее в swap, и ее чтение производится из RAM, получается быстро. Но если у нас таблица будет на 100-200м, в свап она не попадет, и скорость работы mysql не будет отличаться от скорости работы доступа к файлам кеша напрямую. Только не переполненные папки ФС сервера файлами ;) чем файловая операция в переполненной папке кеша Да плюс кеш MySQL еще поможет, да на нагруженных проектах cachemem Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 И плюс по индексу и ключу (в простом запросе) MySQL читает не всю таблицу ;) А только её часть Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это все хорошо. Только вот если использовать таблицу mysql, при любой попытке записи в нее данных, она будет запираться, и все прелести индексов, неполных чтений файлов сходят на нет. И это будет скорее epic fail, чем epic win, так как есть шанс ушатать всю систему. А кеш мем, опять же - в реалиях ssd совершенно утратил свою актуальность. SSD (сам сижу на SSD и мои клиенты на моем сервере) не поможет когда в папке 1000 и больше файлов (эффект тормоза всё равно наблюдается, хоть не так ярко) ;) И нагрузка будет большей чем "запирание" таблицы (там на "запирание" тратиться 0.00000000..., не забываем кеш MySQL). А на переполненную папку файлами кеша с SSD 0.2-.0.3 cек. А на обычном винте 1-10 сек. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Писал я как-то про кэш в 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 Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Это же будут самый легкие запросы для MySQL. Он их любит. Он читает только индекс-файл, и по нему часть файла-таблицы А вот ФС сервера (особенно переполненная папка файлами) - это как гадание на кофейной гуще, не известно как поведет на разных серверах. MySQL - универсальное решение. Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Короче, пора тестировать тяжелую арлиттерию: Redis для кэша. Lucene или Sphinx для поиска и автокомплита. Ну и другие фокусы. Так понемногу перепишем ОpenCart на node.js или Goland :-) Да просто памяти побольше и делов. А что касается поиска. Делал я поиск. Работал он на 700 к товаров. через select match against. Быстро более чем. Только поля приишлось переиндексировать в fulltext. И для полноценной работы phpmorphy не помешало. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Читать то он читает - не вопрос.. А вот при записи таблица заааааблооокирована ) и усе. приплыли. Если вешать на одну таблицу весь кеш. Будет приблизительно такой же эффект, как у магазинов во время работы парсера. И на больших размерах кеша - по сути тот же эффект как от файлового в целом. Что значит "приплыли" ?!, MySQL умный, он просто запрос к этой таблице в очередь поставит... очередь будет 0.0000... никто и не заметит (оптимизатор MySLQ очень хорошо это делает). Учим мат. часть архитектуры MySQL ;) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 С куревом все ок. Если интересен эффект. Предлагаю найти кого нить с парсером MaxD, который бесконечно делает insertы. И посмотреть как работает (очередь). Обычно магазин ложиться. Хотя апдейтится как правило там всего две таблицы. А учитывая, что кешем пользуется добрая половина контроллеров движка, даже небольшие запирания будут укладывать работу всего. Насколько я помню у вас "один" кеш (запись) содержит кучу "страниц". И в MySQL можно сделать отложенную очередь на запись и т.п. Но не в этом суть :) И все таки курим мат. часть: http://www.mysql.ru/docs/man/Internal_locking.html В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. А в opencart- ENGINE=MyISAM Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Будет но . В MySQL все блокировки, кроме блокировок таблиц типов InnoDB и BDB, не создают тупиковых ситуаций. Если бы блокировка была бы такое тормозной... все бы сайты просто были тормозами. В MySQL отличный встроенный оптимизатор. Так что не заморачивайтесь. :) К тому же всегда можно сделать отложенный insert Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha × Уже зарегистрированы? Войти Регистрация Раздел покупок Назад Приобретенные дополнения Ваши счета Список желаний Альтернативные контакты Форум Новости ocStore Назад Официальный сайт Демо ocStore 3.0.3.2 Демо ocStore 2.3.0.2.4 Скачать ocStore Документация История версий ocStore Блоги Модули Шаблоны Назад Бесплатные шаблоны Платные шаблоны Где покупать модули? Услуги FAQ OpenCart.Pro Назад Демо Купить Сравнение × Создать... Важная информация На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности. Я принимаю
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 Так вопрос не в тупиковых ситуациях. А в тормозах вызванных блокировкой таблицы во время операции записи, которых так или иначе будет очень много на таблицу кеша! Я просто не понимаю зачем танцевать с бубном хоть убей, если ssd хостинг стоит копейки и обычный файловый кеш даже с 20кило файлов в папке не вызывает никаких проблем. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка] Покупцям Оплата розширень фізичними особами Оплата розширень юридичними особами Політика повернень Розробникам Регламент розміщення розширень Регламент продажу та підтримки розширень Віртуальний обліковий запис автора Політика просування оголошень API каталогу розширень Вирішення спорів щодо авторських прав Корисна інформація Публічна оферта Політика повернень Політика конфіденційності Платіжна політика Політика передачі особистих даних Політика прозорості Останні розширення Deals – адаптивный универсальный шаблон Автор: octemplates Динамичесткая инфострока в шапке + позиция в макете для opencart\ocstore 2x, 3x Автор: Lito911 Единицы Измерения Товара Автор: RoS Opencart Product Search by Image Автор: slavoglo Простой массовый редактор цен. Fast Price Edit Автор: Sha
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 Не ссорьтесь, мальчики. Используем INSERT DELAYED При обычном INSERT блокировка будет Таблицы таки блокируются. "Тупиковая ситуация" - это deadlock Пробовали, знаем. Все бы было хорошо, если бы было так просто. Отрубаются моментом все last id. Если есть доступ в конфиг mysql, чуть помогает директива low-priority-updates. Но проблемы не снимает. Ну и то что мы сейчас обсуждаем, в условиях нормального железа, яйца выеденного не стоит (за исключением больших регулярных объемов парсинга, но тут нужно допиливать парсеры и производить обновление данных core-таблицах порциями из промежуточных таблиц. Ни MaxD ни Usergio, так и не вняли моим аппеляциям на этот счет к сожалению) Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу. Последние темы Последние дополнения Последние новости Вся активность Главная Поддержка и ответы на вопросы Модули и дополнения Кэширование, сжатие, ускорение Модуль TurboCache для Ocstore [Поддержка]
markimax Опубликовано: 22 декабря 2014 Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. SSD - маркетинг чистой воды, разницы особой от рейда и ssd у хостера я не заметил. На серверах столько памяти, (как сказал хостер в приватной беседе), что все папки к которым частое обращение сервер отправляет в оперативную память. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0 Перейти к списку тем Похожие публикации YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 0 комментариев 8 335 просмотров Seriusis 12 ноября 2020 [Поддержка] YouTube lazy load & popup - вставка видео с youtube, vimeo, галерея видео, оптимизация page speed страниц из видео 1 2 Автор: Seriusis, 12 ноября 2020 youtube lazy load (и ещё 9) Теги: youtube lazy load iframe video видео на странице оптимизация pagespeed page speed галерея видео vimeo видео в карточке 41 ответ 4 105 просмотров cherednychenkoom 24 февраля BOOST - ускоритель OpenCart + AJAX загрузка модулей Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 0 комментариев 20 323 просмотра sv2109 23 июля 2015 Модуль BOOST - ускоритель OpenCart + AJAX загрузка модулей [Поддержка] 1 2 3 4 5 Автор: sv2109, 23 июля 2015 ускоритель кеширование (и ещё 2) Теги: ускоритель кеширование скорость ускорение 105 ответов 17 384 просмотра sv2109 26 апреля 2023 Модуль Jet Cache SE - кеширование, pagespeed, оптимизация для магазинов [Поддержка] 1 2 3 4 74 Автор: markimax, 15 марта 2017 cache seo cms (и ещё 10) Теги: cache seo cms кеширование кеш страниц кеш контроллеров кеш моделей скорость jet cache оптимизация запросы тормозит pagespeed 1 843 ответа 228 127 просмотров G_S_V 19 июля 2023 Сейчас на странице 0 пользователей Нет пользователей, просматривающих эту страницу.
snastik Опубликовано: 22 декабря 2014 Автор Поделиться Опубликовано: 22 декабря 2014 SSD-хостинг во многих случаях - хитрый маркетинговый ход. Реальный хостинг - обычный RAID. Если дисковый кэш, то разделяем по подпапкам. Иначе MySQL. Оба случая требуют трудозатрат. Ну и кэш seo_pro ИМХО лучше в памяти хранить и с unserialize SEO_PRO какая-то шляпа выходит. Есть нормальные хостинги. И даже если SAS диски стоят - уже спасает. Кеш сео про, вреден на овер 20к товаров, так как считывание и перебор массива в 15-20 мб, медленнее чем 150 мелких запросов в базу [Проверено раз 20]. А эта проблема с unlink, ну собаку ему. Возникает настолько редко и некритично, что я бы не стал ни разу заморачиваться. Главное ошибки на морде выключить. Когда файлов больше 1000 в папке даже SSD не спасает :) Файловая система - узкое горлышко серверов. Я видел когда в папке кеша было 10`000 файлов - и на SSD сайт грузился по 20 секунд, из-за этого! Маркетинговый ssd видимо был. У меня у пары пациентов за полдня боты нагоняют по 1.5Гб кеша, и все неплохо живет. Ссылка на комментарий Поделиться на других сайтах Больше способов поделиться... Назад 1 2 3 4 5 6 7 8 9 Вперёд Страница 6 из 9 Создайте аккаунт или войдите в него для комментирования Вы должны быть пользователем, чтобы оставить комментарий Создать аккаунт Зарегистрируйтесь для получения аккаунта. Это просто! Зарегистрировать аккаунт Войти Уже зарегистрированы? Войдите здесь. Войти сейчас Поделиться Больше способов поделиться... Подписчики 0
Рекомендованные сообщения