100napb

как например

если с ходу, то: а) банальный INSERT ~ 1000 записей - это 1000х инсертов или один инсерт вида insert into table_name (id, val) values(1,1),(1,2),(1,3),… ? б) установленный уровень фиксации транзаций (innodb_flush_log_at_trx_commit 2) накладывает серьезные ограничения на скорость изменения данных; если нет жестких требований, обусловливающих необходимость именно такого уровня, то смело ставьте 0. Если у Вас не кассовое \ банковское ПО, конечно в) у Вас включен bin log (настроена репликация)? если нет, то убедитесь, что он не включен г) при установленном размере innodb_buffer_pool_size в 1гиг рекомендуется в общем случае использовать innodb_log_file_size = 128m и innodb_log_buffer_size = 32m д) почитайте за возможные значения innodb_flush_method и их отличия. е) зачем трогать довольно тонкие механизмы вроде innodb_max_dirty_pages_pct_* ? из коробки вроде иные значения. оставьте их - дефолтные. ж) mysqltuner говорит что-то внятное?

Сервер я Вам принес, но доступов вам не отдам (с) Рег.ру дичь же

Вам бы озаботиться более насущными проблемами\рекомендациями того же пейджспида: Сократите время ответа сервера (время до получения первого байта). Ведь для большинства страниц сайта у Вас TTFB (время ответа сервера) около 2сек, а иногда и больше. Две драгоценные секунды браузеры клиентов просто ждут ответа и НИЧЕГО не делают. Скорость ответа сервера, как правило, можно здорово уменьшить путем серверных оптимизаций (запросы к базе, кэширование, поиск и устранения разного рода узких мест в настройка\коде и прочее-прочее) Что же касается конкретно Вашего вопроса по скорости выполнения скриптов... как вариант, можете попробовать в скрипте подключения яндекс-метрики отключить какой-нибудь неиспользуемый функционал. Хотя бы тот же веб-визор убрать.

Journal3? Судя по прикрепленному скрину, больше всех жадным до ресурсов оказывается встроенный в тему SuperCache. Кэшировщик. Могу предположить, что у Вас достаточно часто обновляются товары на сайте, из-за чего кэш автоматически полностью очищается и, как результат, возникают всплески нагрузки на работу без кэша\его формирование. Уточните пожалуйста: сколько файлов у Вас в папке кэша? обычно это system/storage/cache (уточню, что в ОС3 папка system скорее всего вынесена за пределы корневой директории сайта - если сразу не найдете). Интересуют файлы, имеющие префикс journal3. как часто обновляются товары? у Вас виртуальный общий хостинг или собственный vps ? какие права стоят на папку с кэшем?

предположительно, стоит обратить внимание хостера вот на эту ссылку. смотреть ближе к концу отчета.

читать, заменяя слово "Wix" на "nethouse"

в phpMyAdmin'e выполните следующий скрипт

спасибо большое. приятно. Модуль нужен был для конкретного проекта в том виде, в каком есть сейчас. Разовая поделка больше для себя, не более. Едва ли у меня дойдут руки его менять или адаптировать под 3. Код модуля открытый и, в принципе, изменить его несложно, если прям приспичит - там все просто.

Спасибо большое за отклик и пример. Больше всего надеялся именно на Ваш ответ.

Уважаемые, а есть у кого-нибудь опыт\результаты по скорости выполнения запроса из getProducts, если основным хранилищем данных для него будет Sphinx, а не mysql ? А то я тут еще ускорил и стало интересно, а насколько сфинкс круче. Если не сложно, укажите исходное количество товаров для выборки(товаров в категории) и время получения результата с хотя бы "нативной" сортировкой по sort_order и name

и не говорите. все понимают, что это фантастическая дичь, но рили грустно, что никто не удивится, если вдруг... =\

можно. самый простой и костыльный вариант - изменить формат хранения\типа данных для колонки price прямо в бд. вот так. Все имеющиеся записи цены в таблице округлятся автоматически. Но важно понимать, что в таком случае Вы вообще не сможете хранить в базе дробное значение цены, т.к. оно будет постоянно округляться Бэкап таблицы oc_product ОБЯЗАТЕЛЕН! Альтернативный вариант - использовать механизм триггеров самой БД. Триггеры срабатывают сразу же по событию добавления\изменения строк в таблице oc_products и будут округлять цену до нужной точности. вариант более сложный, но зато тип данных и формат колонки прайс останется неизменным + триггеры можно гибко настроить. Текст ниже рабочий, но он больше для примера. Без глубокого понимания сути не советую этот вариант. В любом случае, не забудьте заменить выделенные цветом значения на свои. Бэкап таблицы oc_product ОБЯЗАТЕЛЕН!

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

потянет, конечно. но не так)

увы, не нет такой волшебной кнопки в панели управления сервером или админке опенкарта типа "ускорить \ снизить нагрузку". Потому что задача эта практически всегда комплексная, тем более, если речь идет о рабочем магазине с 50к+ товаров и индивидуальным набором модулей\внешним видом и функционалом. Если хотите устроить себе увлекательное приключение по поиску проблемных мест, то начните с анализа логов системы и опенкарта, мониторинга нагрузки от конкретных служб\демонов, прикрутите какой-нибудь дебаггер к опенкарту в конце-концов или тот же слоу-лог включите\настройте для базы данных. И спрашивайте совета\подсказки уже по конкретным найденным проблемам - вероятность толкового ответа от комьюнити возрастет многократно. Или же, как советовали выше - доверьте это специалистам. P.S.: график нагрузки на цпу от 4-5 декабря выглядит более-менее. Это пограничная дата. Может быть вспомните, что в это время у Вас появились новые товары, Вы удалили кэш картинок, поставили какой-нибудь модуль новый или что-то такое изменили?

TL;DR> больше всех оказались виноваты рукожопы специалисты которые исполняли в парсинг некоторое время назад; модуль фильтра от @vier особо ни причем и просто оказался крайним сначала думаешь, что 60.000 товаров и id-шник категории 765572703 нелепо смотрятся вместе на одном магазине. потом узнаешь, что крайнее значение product_id в магазине что-то вроде 2147491496. затем тормозные без видимых причин запросы, связанные с фильтром, перестают вызывать удивление, ведь приходит понимание, что счётчик и id-шники товаров уже немножко больше чем диапазон типа данных int(11), который из коробки был определен для каждой продуктовой таблицы или как-то связанных с ней через product_id. по факту, основной причиной медленной работы был оверхед на приведение типов данных при джоине таблиц фильтра, которые каноничные int(11), с таблицами товаров\категорий\итп магазина, которые умельцы расширили до bigint(22). К слову, и то не везде расширили, а скорее всего только там, где ругался парсер, а на остальное забили... в общем, фильтру внезапно посыпались все шишки, а его запросы во всех слоу-статистиках незаслуженно возглавили топы. Просто за то что он в этой базе оказался самым "обычным" да, был еще небольшой букет в виде супер-модулей (типа такого; который стабильно генерирует кудрявый sql с невменяемым временем выполнения при значимом количестве товаров), отсутствия минимального кэширования основных элементов и чего-то там еще. Что бы лучше представить картинку в целом и до чего может довести парсинг от умельцев (не с форума, кстати), стоит заценить спойлер. В общем, работы еще много. И магазину нужна помощь от толковых ребят. Но проблем с тем, что запросики от фильтра висят-исполняются сотнями секунд в базе, копятся как снежный ком и вешают все блокировками так, что бы хостеру хотелось рестартить сервер бд каждые 2мин - такого больше нет.

эм.. какая ошибка? UPDATE oc_product SET isbn = ''; должно работать: без всяких условий для всех товаров... может быть ошибка в том, что при копировании кода с форума в текст подмешиваются непечатные символы? известная бага... попробуйте набрать код вручную - всего одна строчка

очевидно у Вас стоит какой-либо модификатор или даже модуль+модификатор, который как-то дополняет\модифицирует получаемую информацию о товарах в категориях\карточке. И делает это криво. Во всяком случае запрос похож на коробочный, но с некоторыми правками. ищите нужный (косячный) модификатор либо в списке модификаторов в админке ОС, либо смотрите xml-ки в папке /system/ Поискать так же можно по содержимому модификатора - например, по слову 'skidka'

по-быстрому проверить можно тут же, в инструментах Яндекс.Вебмастера https://webmaster.yandex.ru/tools/server-response/ просто вписываете url для проверки и получаете результат. На всякий случай. Для тех кто забредет в эту тему со схожей проблемой: тормозит модуль Random Product как бесплатный хотфикс - замените функцию внутри файла /catalog/model/catalog/random.php на ту, что под спойлером. работает на порядок быстрее: в пределах 0.1сек для 100к товаров. Не лучшее, но вполне-себе решение.

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

можно, конечно. например так:

.

вот, по-быстрому сваял на коленке небольшой фикс, что бы не использовать order by rand(). должно работать на порядок быстрее. Сделайте бэкап оригинального файла (/catalog/model/catalog/random.php)и попробуйте заменить его файлом с правками. Так же в этом модуле автором было предусмотрено кэширование результатов (если не надо, что бы после каждого обновления страницы выдавался случайный результат; стандартный кэш опенкарта 1 час). Для того что бы "включить" кэширование внутри файла можете раскомментировать ~72 строчку а так же ~130 random.php