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

[snastik]

Ну вот вот это я нафик поубивал. И заменил на одиночные. Работает как часы. При этом реально быстрее

Хотя вот тут статья на хабре, которая говорит об обратном. Из того что я дочитался, все зависит от выбора Mysql, и в нашем случае одинарные индексы получаются эффективнее.

[markimax]

  В 17.06.2014 в 10:01, snastik сказав:

Ну вот вот это я нафик поубивал. И заменил на одиночные. Работает как часы. При этом реально быстрее

Хотя вот тут статья на хабре, которая говорит об обратном. Из того что я дочитался, все зависит от выбора Mysql, и в нашем случае одинарные индексы получаются эффективнее.

 

А в своем модуле сделал? ;)

 

Проверить на index, если многоколоночный - убить. И создать отдельные.

[snastik]

Да в проекте это у меня уже давно, но, слишком много логики надо писать, проверять очень много индексов надо будет.

Вот кстати подробное разъянснение.

 

  Цитата

 

Составные индексы следует использовать, если запрос включет условие на несколько полей. Например, если запрос WHERE city='Moscow' and age='33', то можно сделать составной ключ KEY(city, age). При этом, можно всегда делать where запрос по левой части составного ключа (в данном случае WHERE city='Moscow'). Если Вам нужно делать запрос отдельно по age, то данный составной ключ в этом не поможет, нужен отдельный ключ на поле age или составной ключ, в котором поле age - первое.

Первичный ключ - уникален, поэтому составной ключ может иметь смысл только есть запросы с указанием диапазона, например WHERE id > 1000 and age < 70. Такие случаи бывают нечасто. Если в приведенном в начале примере создать ключ KEY(id, city, age), то работает он не будет для запроса WHERE city='Moscow' and age='33'. 

Индекс на поле VARCHAR вполне имеет смысл. Причем можно построить индекс по подстроке длиной n символов, если поле VARCHAR длинной. Наприме KEY(description(20));

[markimax]

  В 17.06.2014 в 10:08, snastik сказав:

Да в проекте это у меня уже давно, но, слишком много логики надо писать, проверять очень много индексов надо будет.

Вот кстати подробное разъянснение.

Вот и мне придется всё перепроверить в логике установки и обновления. Но у меня в принципе там "проверки" такого плана есть, осталось Ctrl-C -> Ctrl-V :)

SHOW KEYS (INDEX) в руки ;)

[snastik]

Самая лучшая проверка - это мой профайлер и магазин в котором хотя бы 100-200 статей, сразу красненьким все подсветит.

И потом красненькие запросы в EXPLAIN

[SepProf]

Добрый день, хотим купить модуль. Форма заказа и оплаты виснет. Форум блокирует пользователей Онлайм, поэтому заходим на форум ч/з Анонимайзер, вероятно поэтому невозможно провести оплату. Что делать???

[krissm8]

Чем ваш модуль лучше этого или этого? Не считая преимущества в цене и русской поддержки. Не могу определиться, какой выбрать.

[snastik]

1 ый который вы привели - отлично работает в связке с моим. Его специфика в том, что он кеширует всю страницу.

 

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

 

А в связке с Turbocache , у вас уменьшается сразу время первой генерации (так как сразу уже построены деревья категорий для меню и данные для модулей).

 

Т.е. вы снизите 15 секунд до <секунды.

А потом с использованием модуля от JAY6390, будете просто как из пулемета выстреливать страницы которые были в кеше.

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

По хорошему, если провести оптимизацию базы и прикрутить Turbocache - то необходимость в Pagecache отпадает.

 

Со вторым я не сталкивался, но судя из описания он влияет не столько на генерацию динамического контента, сколько на вывод статики. Я бы не стал покупать такое дополнение так как. Для Apache и NGINX есть mod_google_pagespeed, который делает это все намного проще. Да и зачастую для оптимизации под оценку page speed, нужно перерабатывать шаблон. И не всякая конфигурация сервера будет корректно работать с этим дополнением. Так что вместо него я бы рекомендовал руки.

[fjeka]

  В 28.06.2014 в 17:17, snastik сказав:

1 ый который вы привели - отлично работает в связке с моим. Его специфика в том, что он кеширует всю страницу.

Стоит ли ждать версию Turbocache с полным кешированием ?

[snastik]

Я же написал в предыдущем посте, что как правило в 90% случаев нет смысла кешировать HTML. Так как снижение скорости загрузки с 300-400 мс до 50 - это баловство. Пока что таких планов нет на ближайшее будущее.

[fjeka]

Turbocache хороший модуль, но у него кешируются только жестко прописанные в нем модули, а у меня постоянно появляются новые модули которые тоже хотелось бы кешировать. Разобраться как их добавить в кеш Turbocache так и не получилось. Поэтому и хотелось бы более универсалное решение. Данный модуль http://www.opencart.com/index.php?route=extension/extension/info&extension_id=3477&path=21&filter_search=seo&page=10 стоит 75$ Готов за подождать и за такие же деньги купить Turbocache с полным кешированием.

[flint911]

Добрый день, я видел проблема уже поднималась, но ответа на нее нет
После установке при переходе на категории выводит 

Parse error: syntax error, unexpected T_VARIABLE, expecting ')' in /home3/u150626/xxxxx/www/vqmod/vqcache/vq2-catalog_controller_product_category.php on line 222

 

Подскажите плз как решить проблему?

[snastik]

Пишите в личку фтп.

Эта проблема изза внесения изменений в код - нужно править привязки Vqmod

[VadimMest]

Добрый день.

 

Для магазина с 50 000 наименований (канцтовары) хочу купить ваш модуль TurboCaсhe

Вопрос: Будет ли работать на  MijoShop (Обертка для работы OpenCart на сайте Joomla)

Сколько будет стоить установка и настройка?

 

 

 

 

 

 

[snastik]

Прикрутим и на mijo - для 50 к товаров еще нужны доп оптимизации - пишите в скайп ocshop.support

[serval4]

Здравствуйте. У меня несколько магазинов. Есть привязка к домену или можно использовать на несколько сайтов?

[snastik]

Нет и нет.

[budulev]

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

[fjeka]

Нашел такой модуль для ускорения загрузки http://www.opencart.com/index.php?route=extension/extension/info&extension_id=6204&filter_search=javascript

Будет ли он работать совместно с Turbocache ? Есть ли в нем смысл?

[snastik]

Вы нашли модуль для увеличения оценки GOOGLE PAGESPEED, за 90 долларов я вам руками все настрою, точно также и даже лучше, мало того, в большинстве случаев при использовании nginx данный модуль бесполезен, да и выжать из него полностью заявленные опции практически невозможно, так как автоматическое реструктурирование порядка загрузки js ни к чему хорошему не привиодит.

А так работать будет.

Как то работать будет.

[markimax]

  В 28.06.2014 в 17:17, snastik сказав:

1 ый который вы привели - отлично работает в связке с моим. Его специфика в том, что он кеширует всю страницу.

 

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

 

А в связке с Turbocache , у вас уменьшается сразу время первой генерации (так как сразу уже построены деревья категорий для меню и данные для модулей).

 

Т.е. вы снизите 15 секунд до <секунды.

А потом с использованием модуля от JAY6390, будете просто как из пулемета выстреливать страницы которые были в кеше.

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

По хорошему, если провести оптимизацию базы и прикрутить Turbocache - то необходимость в Pagecache отпадает.

 

Со вторым я не сталкивался, но судя из описания он влияет не столько на генерацию динамического контента, сколько на вывод статики. Я бы не стал покупать такое дополнение так как. Для Apache и NGINX есть mod_google_pagespeed, который делает это все намного проще. Да и зачастую для оптимизации под оценку page speed, нужно перерабатывать шаблон. И не всякая конфигурация сервера будет корректно работать с этим дополнением. Так что вместо него я бы рекомендовал руки.

 

 

Немного не в тему, но я про "развод" за 80$ модулем Opencart Page Cache

http://www.opencart.com/index.php?route=extension/extension/info&extension_id=3477&path=21&filter_search=seo&page=10

Тестировалось много раз firebug -ом (время "ожидания", т.е. то которое тратит сервер на генерацию страницы, сами можете проверить)

 

Демо модуля

http://ocdemo.com/pagecache/

И самое интересное - там слева внизу есть кнопка удалить кеш

Так  вот время генерации страницы сервером без кеша - 0.108 сек с кешем 0.09 сек т.е. разница на том сервере всего то 0.018 секунды!

Т.е. разницы никакой.

А вот то что они пишут

Without Caching: 0.61742496490479      With Caching: 0.0024340152740479

Это "развод" (на заборе сами знаете что можно написать)

Вот же развод так развод... пишут 0.6 сек без кеша (у меня главная моего демо модуля с кучей наворотов (20 виджетов на главной) 0.2 сек, на обычном сервере, как может быть на пустом 0.6 !?), хотя реально 0.108 сек (да и как может быть больше на "пустом" сайте?!)

Не может быть генерация 0.002 сек. (это надо чтобы сайт был один на всех серверах дата центра) так как opencart только загружает все контролеры и управляет ими через FW simfony  ~0.05 сек на быстром сервере, на других ~0.1 сек

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

Поверьте я скорость проверял много раз opencart-a

Так что это полный развод за 80$

Если нормальный сервер и нормальные скрипты, толку от него - ноль

 

Пользуйтесь Turbocache - здесь реальное ускорение

 

P.S. Автор - заточи Turbocache под модуль, пользователи (а их тысячи уже кто купил 5 PRO, и  кто перешел с 4 Commercial на 5 PRO) постоянно меня просят... ;)

Змінено 25 серпня 2014 користувачем markimax

[snastik]

Марк, спасибо за промо, ты полностью прав в анализе. Но я не могу сказать что pagecache  не имеет место быть. На высоконагруженном проекте даже при супероптимизированной базе, запросах и быстром сервере время генерации 500-700 мс, при формировании контента движком и отдача за 50-70 мс готового html из кеша будет не лишними, и позволят надолго оттянуть вопрос переезда на новый сервер.

 

Но, так как зачастую народ хочет решить все вопросы уменьшения скорости генерации одной заплаткой, может создаться впечатление что за цену в $90 они получат ну практически баллистическую ракету и еще оценку googlepagespeed 90+.

 

Ведь по большому счету, то как формируется итоговый html движком, понимают немногие. И еще меньше людей понимают концепцию кеширования как таковую. И несмотря на то, что я подробно обьяснил принцип работы turbocache для большинства - это как квантовая физика, что то слышал, а что это такое - фиг его знает.

 

И как показывает практика, идеальный магазин получается по итогам нескольких процедур:

1 - оптимизация базы и mysql сервера. Тут однозначного рецепта нет. Недостаточно запустить скрипт, который найдет все поля _id  и поставит им индексы. Зачастую приходится сидеть с EXPLAIN и профайлером полдня, для того чтобы найти все засады. Особенно если стоит много дополнительного функционала. (недавно сталкивался с магазином, в котором казалось бы простой запрос, убивал сервер на полторы минуты, так как время жизни скрипта было увеличено и запрос осуществлял какой то хитрый выбор  хитов продаж, и в связи с отсутствием индексов в таблицах order все умирало, а профайлер ничего не показывал, так как апач убивал соединение по таймауту).

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

3 - желателен перенос хранилища кеша с физического диска в память memcache, memcached.

4 - модуль pagecache, если бы не стоил невменямых денег, тоже имеет место быть использованным.

5 - кеширование сжатие и оптимизация изображений. Собственно те процедуры, которые требует Google PageSpeed Insight. В какой то мере они влияют на скорость загрузки сайта, но зачастую эти показатели путают со скоростью генерации контента html. Но в конечном итоге прирост от больших показателей будет виден либо на слабых компьютерах либо на медленном интернете, так как практически все требования, заявленные гуглом, касаются уменьшения физического размера данных контента (сжатие, объединение и минификация css, js и изображений), и оптимизации структуры страниц и работы сервера (объединениеперенос скриптов из шапки в конец контента html и настройка кеширования и сжатия статики на клиенте).

Реализуется этот пункт по разному. Если есть хотя бы VPS, можно поставить на апач mod_google_pagespeed, подкрутить его и забыть, что у вас были эти проблемы. Если дешевый шаред хостинг. То нужно танцевать с бубном, теоретически можно купить на офсайте тоже недешевый модуль (80 зеленых по моему), который частично решает эти вопросы. Но, если стоит NGINX, все равно надо настраивать конфиг, равно как и для apache можно просто подредактировать htaccess, чуть понизить качество jpg и получить сразу оценку 75. А дальше за каждый балл уже надо бороться с большим напильником, вручную пережмая изображения шаблонов минифицируя скрипты и перекраивая структуру шаблонов, для переноса всех скриптов как можно ниже.

 

В итоге, если провести все 5 процедур, мы получаем  систему, способную быстро генерировать первичный контент без кешей. Создаем готовые части контента, которые разгрузят базу данных для генерации новых страниц. Оптимизируем скорость работы хранилища и исключаем проблемы связанные с потенциальными тормозами от большого количества файлов кеша, или прожорливых соседей на сервере. И разгружаем канал пользователям с плохим интернетом.

 

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

 

Есть еще методы по оптимизации работы js скриптов, совсем в тяжелых случаях можно и мультиланг и мультистор вырезать и реплику базы прикрутить, но это уже совсем частные случаи. В 99% для построения быстрой системы на 20-50к товаров с посещаемостью до 20 000 хостов достаточно тех методов, что я описал выше, и обычного vps с 2гб мозгов и какими нить 2,5ghz заявленным процессором.

[snastik]

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

[markimax]

  В 25.08.2014 в 22:17, snastik сказав:

...

 

Согласен полностью.

Да на супер высоконагруженных - выигрыш будет, так как рассерилизовать массив кеша страниц будет быстрее расчета, замечу не оптимизированного контроллера. (хотя во многих случаях хватает и memcache- a)

Но если чуть оптимизировать - толку от модуля Opencart Page cache ноль.

 

У Turbocache совсем другая архитектура, которая реально кеширует узкие места

[markimax]

  В 25.08.2014 в 22:25, snastik сказав:

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

 

Все равно там есть нюансы.

Может быть много виджетов, может быть много категорий товаров из которых берутся отзывы (а там очень будет монстрообразный запрос (хотя я его и кещирую, но лучше два кеша чем один :) ), если много категорий товаров).

Не забывай, что модуль не только новости выводит, но и сильно работает с отзывами для товаров, формами, голосовалками, обратной связью... и это все взаимосвязано и унифицировано