100napb

поиск по форуму. есть как бесплатные решения, так и платные. Разница в функционале и.. проверенности, так сказать. Рекламы делать выгоды не имею, но на модуль image compressor от SiteCreator`а хотя бы взглянуть стоит. судя по всему, комментарий у строки $_['cache_engine'] = 'file'; // apc, file, mem or memcached остался еще с прошлых версий. 3я версия ОС умеет редис из коробки. Пруф. Судя по всему, достаточно просто вписать $_['cache_engine'] = 'redis' () в файле system/config/default.php + проверить соседние файлы catalog.php и admin.php, что бы там движок кэша не переопределялся Что касается скорости\производительности, то тут вопрос спорный: все что не file априори быстрее и потому предпочтительнее. Редиска умеет периодически свопить данные из памяти на диск, что как бы хорошо на случай внезапного ребута или рестарта службы\демона - кэш не пропадет целиком, как в случае с мемкэшед или apc. Я бы выбрал имеено ее, тем более, сессии Вы уже там же храните - зачем лишний софт плодить? Тут определенно проблем в клиентской части больше, чем в серверной. Но, в принципе, все очень даже приемлемо, если Вы, конечно, не перфекционист С картинками только однозначно стоит поработать. Ну да тут п1 уже был. Успехов

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

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

смотрите внимательно на фигурные скобочки: прямо перед 22 строкой закрывается блок фунции __construct. Ваш if, идущий сразу за этим, как бы болтается бесхозный, не пойми к какому блоку\функции отнесенный. Очевидно, что-то вырезали или не туда вставили... Ну или фигурную скобочку из 21 строки перенесите в 25ю

это картинка из панели одного украинского хостера, если не ошибаюсь (adm.tools) - отчет о медленных запросах. К слову, вопрос к ТС: много там в этом отчете сообщений\строк с указанием на этот запрос? И... как много у Вас записей в табличке oc_cart ? Медленное удаление может быть по разным причинам: блокировки таблиц, движок таблиц, отсутствие индексов... По факту же, едва ли Вам стоит переживать - этот медленный запрос не должен сколько-нибудь заметным для клиентов, т.к., по сути, убирает корзинки недооформленных заказов для незарегистрированных клиентов. В любом случае, как вариант, попробуйте добавить доп.индекс для таблички. Предварительно замерив скорость выполнения своего запроса в том же phpmyadmin до и после добавления индексов

не во что тыкать. слишком мало информации для конкретики. Если налицо такая яркая зависимость только от кол-ва товаров, то логично предположить, что у Вас не оптимизирован ряд запросов к базе данных, или же есть какой-то модуль\модули, авторы которых не позаботились о том, как их детища будут работать с большим кол-вом товаров. Могу лишь либо предложить обратиться в раздел платных услуг за диагностикой и решением проблемы. Либо попробовать "выловить" ее самостоятельно, например через дебаггер запросов, с помощью которого Вы найдите либо избыточное кол-во запросов в целом, либо просто парочку шибко долгих. p.s.: запрос, что Вы указали, судя по всему, считает топ 10 товаров с наивысшим рейтингом для модуля бестселлеров или что-то подобное. Его запросто можно\нужно закэшировать, т.к. высчитавать это каждый раз смысла мало.

У Вас очень некорректный\размытый вопрос. Давайте его сделаем более понятным и конкретным. Для начала, условно можно разделить скорость работы сайта на две стороны: серверную и клиентскую. Как за пару минут понять, что необходима серверная оптимизация? Открываете главную страничку своего сайта. Желательно проверить так же страницу категории и страницу товара. Нажимаете в браузере F12 и ищите вкладку "сеть\network". На ней Вас интересует время, затраченное на получение html-кода странички. Именно в процессе генерации этого кода выполняются все php-скрипты, работает движок, идут запросы в базу и так далее. Именно здесь работает сервер. Если значение слишком велико, вплоть до нескольких сек, то стоит задуматься о поиске причин, которые дают задержку на сервере. Так же стоит обратить внимание на время DomContentLoaded - оно так же должно быть минимальным. Как за минуту понять, что нужна оптимизация на стороне клиента? Посмотреть на итоговое время загрузки страницы. Дело в том, что после того, как браузер клиента получит необходимые ресурсы для отрисовки страницы, браузеру предстоит, собственное, эту страницу отрисовать: загрузить и наложить CSS-стили, выполнить все js-скрипты, дождаться разрешения всех блокировок и прочее. На это будут уходить драгоценные секунды. Иногда много секунд. Куда смотреть? Там же в браузере, внизу, как на скрине - общее время load. Всякие пузомерки, типа googlepagespeed, так же могут дать ценную информацию и указать причины. А теперь, пожалуйста, задайте вопрос как подобает, если хотите получить вменяемый ответ\совет Цифры, скриншоты и минимальная диагностика приветствуется. На худой конец хотя бы ссылку на пациента оставьте. Что касается "очень интересует кэш", то то же не понятно. Кэш чего\для чего, где, в каком месте? Их много может быть, и все разные )

я такое могу представить только в кошмарном сне про ужасно занудных евреев =\ Что тут скажешь... классно! Вы описываете пути решения проблемы, связанной с нехваткой производительности. И отталкиваетесь от частного примера, который я привел. А топик о том, как попытаться эту производительность измерить в принципе с помощью более конкретной абстракции, нежели кол-во vCPU, нод или прочих гигабайт, и учесть при этом в том числе используемое ПО и его конфигурации. Если Вам тема не нужна\не интересна и кажется бессмысленной, то... я для нее места у Вас то же не найду и заинтересовывать не стану. Я же не маркетингом и не продажами занимаюсь ) Вы уж простите, но это не та полемика, в которой мне хотелось бы участвовать.

Так само-собой. Топик ни чему не призывает Речь лишь о том, что иной раз описание тарифа\услуги не дают необходимой информации, что бы сделать взвешанный и обоснованный выбор. Например, подобрать новую площадку под вырастающий проект, которому текущих мощностей не хватает - тут как раз синтетика и сравнения могут быть полезными еще до получения финального результата, что бы потом внезапно не обнаружить, что на новой площадке не шибко-то и лучше... Во всяком случае, я не умею достоверно "на глазок" определять, без тестов, что вооон на том сервере ресурс\запас производительности будет достаточным под те или иные задачи. Кроме того, даже цифры и синтетические попугаи убеждают большую часть людей намного лучше, чем слова, т.к. какие-никакие, а все-таки пруфы)

ab - наше все )) не спорю - полезно. Спасибо! Но это, на мой взгляд, уже на финишных этапах настройки\шлифовки: так как пока не развернешь проект целиком и не сконфигурируешь окружение, то тестировать как бы с помощью АБ и нечего. Во всяком случае, я его использую только что бы а) оценить нагрузку на веб-сервер и БД во время тестирования с большим кол-во конкурентных потоков и запросов б) оценить количество request per sec. А Вы?

Топик небольшого совета-помощи для тех, кто озадачился сменой или выбором новой хост-площадки. Ну, или для теста разного рода твиков\оптимизаций, типа смены io scheduler'a или конфигурации БД. Зачем это надо? Что бы сколько-нибудь предметно и на цифрах оценить производительность. А не ориентироваться только лишь на отзывы\советы тех или иных серверов\тарифов. Как грится, лучше один раз затестить... Ограничения \ системные требования? У Вас должен быть доступ по ssh к выделенному серверу. Виртуальный хостинг едва ли подойдет. О чем будут примеры ниже? О том, как установить на сервер утилиту sysbench и провести ряд базовых тестов Как оценивать результаты? Только сравнением между собой. До и после. На том сервере и на этом. Строго при одинаковых параметрах запускаемого теста. Результаты sysbench'a зависят от множества факторов и их не стоит измерять одной и той же линейкой Погнали. Установка. для примера пусть будет дистрибутивы rhel \ centos. На текущий момент это версия sysbench-1.0.17-2 yum install sysbench Тест CPU. Вычисляем простые числа с ограничением в cpu-max-prime в 1, 4 или 16 потоков. Запускать на выбор или по очереди. sysbench cpu --cpu-max-prime=10000 --threads=1 --time=60 run sysbench cpu --cpu-max-prime=10000 --threads=4 --time=60 run sysbench cpu --cpu-max-prime=10000 --threads=16 --time=60 run Результаты\на что обратить внимание: Тест дисковой подсистемы. - Подготовим тестовые файлики. В текущей директории будет создана пачка файлов суммарным объемом --file-total-size= Х. Потом за собой удалим. Просто будьте готовы к этому \ вдруг не хватит места sysbench fileio --file-total-size=4G prepare Результаты\на что обратить внимание: - Тест случайного чтения\записи. sysbench fileio --file-total-size=4G --file-test-mode=rndrw --time=60 run Результаты\на что обратить внимание: - удаляем тестовые файлы за собой. sysbench fileio --file-total-size=4G cleanup Тест скорости работы ОЗУ sysbench memory run Результаты\на что обратить внимание: Тест производительности БД (OLTP) Важно сделать оговорку, что результаты одних и тех же тестов могут значительно отличаться не только на разном окружении\железе, но и, прежде всего, при различных конфигурациях сервера БД, его версии и движка таблиц. Впрочем, иной раз интересно посмотреть на разницу в результатах MariaDB vs MySQL или при тех или иных параметрах конфигурации. Просто учтите это. - для начала создадим отдельную базу для тестов с помощью PhpMyAdmin, консоли или что кому удобнее. Я назову базу test и в примерах ниже буду использовать это имя. - подготовим таблички для проведения тестов. Укажем движок (в примерах будет innodb), а так же кол-во строк в таблицах - 1млн. В параметрах --mysql-user=user --mysql-password='password' используйте свои значения sysbench --db-driver=mysql --mysql-user=user --mysql-password='password' --mysql-db=test --mysql_storage_engine=innodb --table_size=1000000 --tables=4 --threads=4 /usr/share/sysbench/oltp_read_write.lua prepare - собственно тест. имеет смысл погонять в разное кол-во потоков. В процессе теста выполняется набор транзакций \ разнообразных запросов: с интервалами, группировками, агрегатными функциями и прочее. Все это, при желании можно настроить, запустив тест с параметром help вместо run и подсмотрев нужные ключики. sysbench --db-driver=mysql --mysql-user=user --mysql-password='password' --mysql-db=test --mysql_storage_engine=innodb --table_size=1000000 --tables=4 --threads=1 --time=60 /usr/share/sysbench/oltp_read_write.lua run Результаты\на что обратить внимание: - удаляем за собой таблички. Можно дропнуть всю тестовую базу. sysbench --db-driver=mysql --mysql-user=user --mysql-password='password' --mysql-db=test --tables=4 /usr/share/sysbench/oltp_read_write.lua cleanup Для самых любопытных https://github.com/akopytov/sysbench загляните после после установки в папку /usr/share/sysbench и посмотрите на доступные\дополнительные тесты. Вопрос на финише: кто как тестирует сервера? Делитесь опытом!

воспользуйтесь инструкцией по установке\настройке шаблона или посмотрите по аналогии, как настроено на демо-сайте шаблона (логин\пароль demo\demo) Там что-то в духе: включить модуль фильтра \проверить что он включен импортировать данные в фильтр как на скрине выше, а затем настроить его по собственному разумению или по аналогии с демосайтом. в макетах (главное меню - дизайн - схемы - макет для "категории") добавить модуль фильтра в левую колонку \ убедиться что он добавлен почистить кэши\обновить модификаторы и проверять. Более чем традиционная схема\порядок действий, многократно описанная в документации. Если не справитесь - попробуйте еще раз. Ну а уж если совсем все тяжело дается и нет времени разбираться, то велкам в раздел платных услуг - кто-то будет это делать за Вас.

вероятно, в настройках шаблона, в разделе "фильтр товаров", необходимо провести импорт производителей. Насколько я помню, фильтр из этой темы\шаблона использует собственные сводные таблицы в БД вместо стандартных. А значит, они могут отличаться и надо их ручками время от времени синхронизировать.

Не переживайте - мускуль сможет использовать все Ваши виртуальные процессорные ядра и для этого не требуется вообще никаких настроек, т.к. он это умеет из коробки. Однако, нет в этой СУБД такой настройки, которая бы позволяла обрабатывать один, даже очень тяжелый запрос, силами более чем одного ядра.

Вам хороший совет дали - удобнее\проще всего (и можно вернуть обратно) воспользоваться коробочным функционалом и сделать временную\акционную цену на все товары. Решается одним нехитрым запросом в базу. Красным выделил то, что Вам нужно изменить: цена, дата начала акции, дата конца акции. Фиолетовым - закомментировано условие, если Вам нужно сделать акцию только для конкретной категории\категорий товаров. в любой момент акцию можно завершить или вовсе удалить, вернув тем самым регулярную стоимость. например так. Красным, опять же, Ваше время начала акции\скидки Как альтернативный вариант, можно зааптейдить основную цену у всех товаров запросом, что Вам предложили выше. Но что бы вернуть "родные" цены на товары, Вам нужно сделать бэкап таблички oc_product. Иначе все данные о "родных" ценах безвозвратно перезапишутся апдейтом. Ну или покупайте модули. Там все прощее\удобнее\понятнее

система - настройки - ваш_магазин - вкладка опции.

стандартная корзина хранится 1 час, вроде бы. ищите в файлике /system/library/cart/cart.php строчки типа красным выделил кусочек, который удаляет корзины старше 2 дней. одновременно с этим стоит убедиться, что время жизни пользовательской сессии как минимум такое же, что и у корзины. Иначе, сессия может "протухнуть" раньше, например, и клиент потеряет привязку к еще живой корзине. Как вариант, время жизни сессии может быть установлено в файле php.ini параметром session.gc_maxlifetime = 172800; или В файле .htaccess php_value session.gc_maxlifetime 172800

скрипт предназначен для поиска клиентов, имеющих X и более заказ(ов) ранее чем N-месяцев назад И НЕ имеющих заказов после этого этих клиентов можно и нужно стимулировать и выводить на новый заказ например - сделать таргетированную расылку по email

Будет больше информации \ возможности Вам помочь, если Вы покажите план выполнения запроса. Что бы видна была информация о существующих\используемых индексах, кол-ве перебранных строк и прочее. Для этого добавьте перед в самом начале запроса слово explain, выполните скрипт повторно, а результаты прикрепите к посту. P.S. на первый взгляд все джоины выполнены по primary ключам, свойственным таблицам опенкарта. Что лишает надежды на то, что бы решить задачу самой малой кровью =\ P.P.S.: тухнелький, но вариант: заменить now() на конкретную дату. без секунд часов и минут + добавить кэширование запроса средствами ОС или mysql. Быстрее не будет, но будет не каждый раз

в архиве с модулем, по пути \catalog\model\catalog\random.php, или уже у себя на хостинге в том же файле, ищите строки. То что красным - добавить. Это проверка товара в наличии. То что фиолетовым - если хватить компетенции, то переписать. Дело в том, что order by rand - это примитивнейший способ случайной сортировки. Очень удобно использовать, но работает медленно, так как всегда делает full scan таблицы. Иными словами, когда товаров у Вас в базе будет около пары тысяч, этот запрос будет выполняться, примерно, 0.5сек. И чем больше товаров - тем "тупее" он будет и тем дольше будет открываться страница, на которой стоит этот модуль.

из коробки так и есть \ было. либо отключать отображение ошибок, либо делать какой-нибудь обрабатываемый exeption

Пожалуй, спасибо и Вам. Как минимум - за обратную связь. Положительные результаты всегда радуют (^.^) И еще в паре-тройке смежных и не очень областей... Успехов!

до после 1(сократил до 2х знаков) после 2 (до целого) формально, mysql не выдаст ошибки при вставке дробного значения в поле с типом целого (или при вставке значения с "излишней" точностью) - сработает приведение типов с нормальным округлением к ближайшему возможному значению

Исключительно ради любопытства... Вы в самом первом посте топика приводили скрин из phpmyadmin'a с кусочком полей таблиц и их значениями. Вас не затруднит сделать еще один, точно такой же скрин? Мне просто интересно, не пошел ли Ваш исполнитель самым прямым путем (сквозь "стены") и не изменил ли тип данных в табличке с decimal на integer, например На скрине просто должна присутствовать дробная часть у значений, типа "100.0000", а не просто "100".