Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Sign Up

100napb

Пользователи
  • Posts

    416
  • Joined

  • Last visited

Technical support

  • Other
    Базы данных, SQL

Информация

  • Пол
    Мужчина
  • Интересы
    SQL

Recent Profile Visitors

7,690 profile views

100napb's Achievements

Proficient

Proficient (10/14)

  • Dedicated Rare
  • First Post
  • Collaborator
  • Conversation Starter
  • Reacting Well Rare

Recent Badges

138

Reputation

  1. как вариант, при изменении статуса заказа идет некое обращение к сторонним ресурсам каким-нибудь curl'ом (по видео можно предположить, что есть какая-то связь с монобанком). и либо api этого стороннего ресурса тупит, либо какие-проблемы с ним, но из-за этого может тупить на раз. а еще при отправке писем при изменении статуса заказа могло бы, но галочку "уведомить" Вы не ставили... а еще стоит посмотреть раздел "события" в аминке опенкарта - там так же могут быть какие-то триггеры, которые срабатывают при изменении статусов заказов...
  2. безусловно, это отличное решение, особенно для клиентов на мобильных устройствах. Однако без ведома ТС подобное едва ли появится вместе с каким-нибудь модулем или шаблоном и он был бы в курсе ) не знаю как Вы, а я не вижу необходимости и большой разницы между целым рядом размеров. Там половину можно унифицировать и зафиксировать нужные размеры в верстке\стилях: при небольшой разнице в размерах картинки и ее реальных габаритам в макете html даже гугл ругаться не будет в своем пейджспиде. странно... в тройке он вроде как должен быть из коробки. вероятно какой-то модификатор или модуль подменяет собой этот функционал. и, вестимо, спрашивать и искать начать стоит именно с него. нет ничего проще проверить и убедиться - посмотрите "глазами" внутри папки кэша, какие там ресайзы создаются для какой-нибудь выбранной картинки какого-нибудь выбранного товара. и сколько их \ с какими названиями
  3. 1. убедитесь, что у вас качество ресайзов картинок не установлено вручную или модификатором в какие-нибудь волшебные 100% 2. типовые размеры ресайзов должны быть стандартизированы среди всех модулей в магазине, всех блоков и настройках шаблона. Иными словами, у Вас не должно быть десятка уникальных типоразмеров картинок: один для категорий, другой для блока рекомендуемых, третий там для еще какого-то места... в противном случае, для каждого изображения товара будет создан тот самый десяток ресайзов. В большинстве случаев, хватает лишь нескольких типовых размеров 3. + webp (на скрине почему-то размер подозрительно мал)
  4. вероятно, речь не о веб-серверах, а о модуле для них, который призван выполнять ряд различных оптимизаций https://www.modpagespeed.com/ ps: в ряде случаев модуль может быть полезен; но по факту же а) требует тонкой настройки, иначе можно огрести проблем на ровном месте б) редко обновляется в) по итогу выхлоп сомнительный и как серебряную пулю его точно рассматривать не стоит. г) априори требует vps и не годится для виртуального хостинга (ну разве что если сам хостер не встроит его в панель управления и свои веб-сервера (украин.ком?)
  5. там опечатка\ошибка была. в репозитории OCStore она осталась. Из-за этого gc срабатывает при каждом запросе страницы. После исправления работает аналогично коробочному механизму php по очистке протухших сессий и гибко настраивается. На мой взгляд, это лучшее решение детской болячки с сессиями в базе для ОС 3.* на текущий день.
  6. И это тоже. вот действительно годное решение (рабочий механизм gc в конструкторе с учетом настроек окружения/php, ответственных за частоту срабатывания) https://github.com/opencart/opencart/blob/3.0.x.x_Maintenance/upload/system/library/session/db.php
  7. ради того же интереса привяжите все эти товары к одной категории и попробуйте снова посмотреть ttfb. По моим наблюдениям, пока нет жирных категорий с большим количеством товаров, все более-менее терпимо работать может за рядом небольших исключений, которые так же относительно несложно фиксятся. Судя по урлам в вашем примере отсутствуют ЧПУ для всех этих товаров и категорий. В OCStore третьей версии сео_про на порядок шустрее работает чем в двойке, но, тем не менее, при таком количестве товаров именно сео_про будет изрядно тормозить, если включено кэширование урлов (json_decode всего массива с чпу будет дороже, чем простецкий атомарный запрос к бд)
  8. я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет...
  9. Есть мнение, что Опенкарт с его простенькой и стабильной архитектурой априори не гонится за какими-либо трендами . Глобально в нем от версии к версии мало что меняется. Из дискурса современной разработки и даже возможностей свежих версий php он так же выпал. Какое там PSR, DI, autowiring, DRY и прочие модно\трендовые слова. Опенкарт это совсем не про хайп. Староват. Молодым специалистам он все менее интересен: там какая-нибудь лара, джнага или ангулар с реактом заманит скорее, чем дряхлеющий ОС. Иными словами, не растет семимильными шагами аудитория специалистов. Скорее даже редеет... Все это прямо или косвенно объясняет приведенные Вами графики. Тем не менее, он остается относительно простым, недорогим и потому популярным инструментом, способным решать актуальные хотелки и требования екома. Особенно в СНГ. В том числе - благодаря этому форуму. это все давно было и будет. P.S.: есть полно примеров успешных проектов, которые обрасли кастомом, сидят себе еще на 1.5.6 \ 2.3 версиях, в ус не дуют и зарабатывают без оглядки на какие-то там графики трендов опенкарта.
  10. для особо одаренных и настойчивых и twig не помеха, к сожалению. подобное стоит расценивать как своеобразный показатель качества шаблона: увидев методы-аналоги getProduct или imageResize во view, можно сразу начинать грустить
  11. все Вы верно выразились в стартовом посте. Просто куки могут быть разными и там, где сайт перестает узнавать своих посетителей после закрытия браузера всего-лишь используются сессионные куки, которые вместе с закрытием браузера удаляются. Решение банальное: а) необходимо в настройках вашей версии php изменить session.cookie_lifetime = 3600 * Nчасов б) если не ошибаюсь, для 2.3 нужно в /system/library/session.php в районе 50й строчки сделать так в) так же стоит обратить внимание на параметры session.gc_probability, session.gc_divisor, session.gc_maxlifetime и учесть, что длинные сессии будут давать определенную нагрузку на хранилище в момент работы сборщика мусора (механизма удаления "протухших" сессий).
  12. на всякий случай. 1) после изменения $_['cache_engine'] = '?'; в upload/system/config/default.php стоит так же где-то (в config.php?) прописать константы со своими значениями вот тут чуть больше инфы 2) большое значение имеет версия php-расширения для взаимодействия с сервером редиски. например, для php 5.6 максимально возможной является версия модуля\расширения redis 4.3.0 если мне не изменяет память, класс redis, которые идет из коробки в опенкарте, так же с более новыми версиями php-redis расширений не дружит, так как там ряд методов стал depricated \ переименовался. проверьте версию модуля. если что - установите нужную через pecl.
  13. все что стоит знать о квери кэше на сегодняшний день ко всему прочему, кэширование атомарных запросов - плохая практика, чреватая скорыми последствиями. Впрочем, первые плоды Вы уже пожинаете - и это только верхушка айсберга ненужных приключений и проблем, связанных с инвалидацией этого кэша. нет, нельзя. Но если очень хочется есть кактус, то в select clouse избранных запросов стоит добавить директиву SQL_NO_CACHE; или зайти с обратной стороны: включить квери кэш в режим работы только для ряда запросов, помеченных директивой SQL_CACHE. хорошей практикой будет обычное кэширование на уровне приложения: хоть в файлы, хоть в редис. средствами опенкарта это делается довольно просто. что-то вроде
  14. у Вас используется несколько модулей доставки, каждый из которых отправляет запросы на сторонние сервера для расчета стоимости. Разумеется, это требует времени. Ради беглого теста попробуйте отключить в админке опенкарта все эти модули и проверьте, как изменится скорость открытия страницы чекаута; затем включайте по одному и поймите, какой из модулей дает наибольшую задержку. Ну а дальше, когда Вы более-менее установите проблему, ищите решение \ исполнителя.
  15. для больших городов список пвз слишком длинный и не помещается в лимиты, установленные для колонки с данными в бд. просто "расширьте" эти лимиты, изменив тип данных для колонки. например так
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.