Модуль OpenCart Lightning: кеширование, оптимизация, улучшение SEO и Google PageSpeed [Поддержка]

[SANTEHSERVIS]

СНОВА НЕ РАБОТАЕТ СЕРВЕР Lightning !!!!!! 
Сделайте что нибудь. Это уже стабильно становится. Раз в месяц, второй месяц подряд.

Lightning отключен:

Lightning server communication error

[MaxD]

Да, накатывали обновление, сервер отключался буквально на пару минут.

 

Обновление 3.34:

Ускорение фильтров и поиска в JOURNAL3

Функция контроля доступа:

[dieselhqpro]

Доброго времени суток!

Оплатил модуль, пишет тестовый период окончился 

12 дней до нового теста

Как решить этот вопрос?

отключение-удаление-обновление модификаторов и новая установка-не помогла

Please help!

[dieselhqpro]

Только что, dieselhqpro сказал:

Доброго времени суток!

Оплатил модуль, пишет тестовый период окончился 

12 дней до нового теста

Как решить этот вопрос?

отключение-удаление-обновление модификаторов и новая установка-не помогла

Please help!

оплатил визой 1го мая 2020

Змінено 1 травня 2020 користувачем dieselhqpro

[MaxD]

@dieselhqpro Вы не указали адрес вашего домена при покупке. Скиньте его мне в личку.

[dieselhqpro]

Только что, MaxD сказал:

@dieselhqpro Вы не указали адрес вашего домена при покупке. Скиньте его мне в личку.

а на какой адрес скинуть?

[MaxD]

@dieselhqpro Уже разобрались в личке )

[dieselhqpro]

Только что, MaxD сказал:

@dieselhqpro Скиньте на [email protected]

О, заработало!! Спасибо!!!

[MaxD]

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

Это Warningи о невозможности удалить файл кеша такого вида:

Warning: unlink(httpdocs/storage/cache/cache.catalog.language.1582103414): No such file or directory

Пришлось глубоко покопаться, и выяснилось много интересных вещей. В Lightning есть код для подавления этих сообщений, но он почему-то не всегда срабатывал. Оказывается, в OpenCart 3 зачем-то есть два обработчика ошибок, которые показывают этот Warning. Один, как обычно, контролируется настройками магазина config_error_display и config_error_log. А второй, весьма загадочный - параметрами error_display и error_log, прописаными в system/config/default.php.

 

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

 

Выяснилось, что во всех версиях OpenCart 3 есть несостыковка в кешировании информации о языках:

 

 

В начале проверяется, не записан ли уже кеш по ключу language. Если его нет, данные получаются и записываются по ключу catalog.language !!!

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

 

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

 

Зачем я это тут расписываю? Может кому-то из разработчиков будет интересно и полезно.

 

В Lightning эту проблему я исправил, и поправленая версия 3.36 уже выложена - хотя номер версии не изменился. Просто уже совесть не позволяет через день выкладывать новые версии, а они прут в связи с карантином

[chukcha]

в 3.1. ветке исправлено

[anykey1]

Здравствуйте

При попытке зайти в настройки или уведомления Lighting вижу

Error: Could not make a database link

Это что то у меня не так или на сервере?

 

И щас появилось:

OpenCart Lightning
v. 3.31 ru
Lightning отключен:
Ошибка подключения к серверу Lightning

Змінено 4 травня 2020 користувачем anykey1

[MaxD]

@anykey1 Да, уже исправлено )

[WebExper]

Здравствуйте уважаемые друзья! Многое прочитал об этом модуле и он очень мне понравился,собираюсь купить его! 

Но у меня 1 вопрос.Скачал модуль,установил ,Всё отлично,даже показатели в  google page speed увеличились.

но  при нажатие кнопки настройки в виджете, ничего не работае.

 

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

[MaxD]

@WebExper Рад, что Lightning вам нравится!

Настройки не показываются изза несовпадения адреса сайта в config.php и admin/config.php. Приведите их к одинаковому виду, с www. или без.

[WebExper]

21 минуту назад, MaxD сказал:

@WebExper Рад, что Lightning вам нравится!

Настройки не показываются изза несовпадения адреса сайта в config.php и admin/config.php. Приведите их к одинаковому виду, с www. или без.

 

 

 

Прикрепляю скриншот. можете помочь подсказать что удалить?

 

 

Змінено 4 травня 2020 користувачем WebExper

[MaxD]

@WebExper Поудаляйте потом отсюда скриншоты, отредактировав сообщение. Такое не постят в общем доступе )

 

В файле admin/config.php поубирайте все 4 www.

[WebExper]

@MaxD Благодарю! Сработало !) спасибо вам огромное !

[WebExper]

а я не понял куда вводить эту строчку уважаемый разработчик

[MaxD]

@WebExper Это настраивается в панели управления вашего хостинга. Если не находится, попробуйте связаться с хостером.

[WebExper]

Благодарю вас за оперативные ответы ! я обязательно возьму продукт и напишу вам в личные сообщения.

 

Последний вопрос который меня тревожит это на скриншоте.

[MaxD]

@WebExper Это нормально. При возможности сервер использует всю доступную память для файлового кеша. А Lightning это возможность дает, что очень хорошо.

Пока все работает без сообщений о недостаточном количестве памяти - волноваться неочем.

[snastik]

9 часов назад, MaxD сказал:

@WebExper Это нормально. При возможности сервер использует всю доступную память для файлового кеша. А Lightning это возможность дает, что очень хорошо.

Пока все работает без сообщений о недостаточном количестве памяти - волноваться неочем.

И в тот момент, когда происходит любой аномальный всплеск, или пик нагрузки, или вдруг директ включили.
Происходит что? Происходит "падение сервера".
Все что пишут в умных книжках про резервирование ресурсов, стабильность систем, тройной запас прочности.

Просто пустые слова, потому что ....
Ну так захотелось.
Да конечно - это нормально. В другой солнечной системе, или на Марсе. Оставлять систему без запаса ресурсов.

Скажите, а вы в трезвом уме этот комментарий писали ?

 

[MaxD]

@snastik Вы известный специалист по настойке серверов, хочу с вами свериться - может я что-то неправильно понимаю. Я вижу ситуацию так:

 

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

 

Если серверу нужна память для чего-то еще, он без проблем освобождает часть памяти дискового кеша и использует ее для своих нужд.

 

Вот как это выглядит в  top'е:

 

 

В данном случае у сервера 1 гиг оперативки, из них 498 мегабайт использовано под дисковый кеш.

[snastik]

7 часов назад, MaxD сказал:

@snastik Вы известный специалист по настойке серверов, хочу с вами свериться - может я что-то неправильно понимаю. Я вижу ситуацию так:

 

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

 

Если серверу нужна память для чего-то еще, он без проблем освобождает часть памяти дискового кеша и использует ее для своих нужд.

 

Вот как это выглядит в  top'е:

 

 

В данном случае у сервера 1 гиг оперативки, из них 498 мегабайт использовано под дисковый кеш.

 

 

Я не понимаю. При чем тут дисковый кеш.

Рассказываю на пальцах. Есть сервер у него гигабайт памяти.
Системные службы сервера потребляют пусть 200 мб.

И дальше мы инициализируем поток PHP, который под преобразование картинки отожрал 100мб, под данные из базы еще 20, под json decode encode в этом процессе еще 50. И под инициализацию 20 экземпляров класса controller еще пусть 20.

Итого, на генерацию страницы у нас ушло 210 мб.  Страница генерируется секунду к примеру. И в этот момент у нас четыре банальных потока уже забрали всю память.
Ну это несчастный случай, если у нас допустим сброшен кеш изображений. Если не сброшен - то ладно, 110 мб на поток. Это очень усреднено - но, учитывая, что в большинстве магазинов есть еще пара тройка AJAX запросов это х3. Предположим, за секунду мы получили 3 посетителя, два бота, и вот это ваше... Регенерация кеша (потому что кеш типа по вашему это круто), а быстрые магазины на холодную мы делать не умеем. Ок..

Три посетителя, два бота получаем минимум десяток потоков по 100 мб забрали памяти, пусть у нас гигабайт всего и еще пару свапа... Который очень медленный .

И свап не всегда настроен. Мы получили лежачий сервер с минимальной нагрузгой. А еще там очередь лайтнинга стоит по прегенерации кеша, которая всегда.

 

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

 

Зато покупатель модуля видет ничесе... У нас тут из файлов. Все быстро прочиталось отдалось на фронте как голый html. Ничесе снесли все скрипты в один файл пузомерка гугла подросла.

А в итоге ни для конечного покупателя, ни для поисковых систем, нет эффекта. Сервер висит загружен этими бескончеными тупыми задачами прегенерации, запаса ресурса нет и не предвидеться. И холодные страницы как были, так и есть тупые.

 

А то что в пик нагрузки, ресурсов нам надо хотя бы х3 от среднего. Да кого это волнует. Главное же у нас html из файла быстро считался-отдался.
И пузомерка pagespeed нарисовалась. А в итоге - это как Арбидол. Стоит дорого, а результата ноль.
 

[MaxD]

@snastik Дисковый кеш при том, что в разговор о нем вы подключились. Запас памяти есть, она просто используется под дисковый кеш, пока свободна.

 

Вижу, Lightning вам сильно не нравится, может это как-то связано с тем, что у вас есть свой модуль ускорения магазинов  

Покоментирую некоторые моменты вашего поста.

 

44 минуты назад, snastik сказал:

Итого, на генерацию страницы у нас ушло 210 мб

 

Странные у вас цифры.  У Journal 3 (один из самых тяжелых шаблонов) среднее memory_get_peak_usage() в районе 5-6 Мб. У голого Opencart 3 - всего 2 Мб.

При создание кеша картинок эта цифра выростает на несжатый размер самой большой картинки, что тоже как-то не смертельно - если не заливают 4К-полотна.

 

58 минут назад, snastik сказал:

А еще там очередь лайтнинга стоит по прегенерации кеша, которая всегда

 

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

 

Естественно, Lightning не заменит оптимизацию медленных запросов, и если магазин сам по себе неработоспособен - то и под Lightningом он будет не очень.

Но, за все время работы я не видел ни одного магазина, который бы работал медленнее или падал изза Lightningа.

 

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