Какие необходимы ресурсы или проблема всё таки в настройках?


#21

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

Насколько?
Зависит от скорости реализации в розничных точках. Определяется расчетно-эмпирически.

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

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


#22

У меня например (еще с тех пор, когда модуль обмена был не настолько хорош, чтобы им пользоваться) была написана обработка в 1с и свой мод в my_changes, обработка его вызывает и передает файл с товарами, и мод разносит по базе количества, цены и некоторые характеристики (размеры для доставки, вес итп) - прямо в таблички. Но так как организационно в итоге расхождения стали возможны только в четырех случаях (новая поставка, изменение цен, возвраты, списание брака) - то и запуск обработки происходит уже давно не автоматически, а вручную при наступлении такой ситуации. Да и работает такой вариант гораздо быстрее.


#23

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


#24

Сложно перечислить. А если получится это грамотно описать, то это надо будет не на форум, а разработчику отправить для оценки, чтобы нормально переделали. Там просто уйма мест с “гениальными” решениями. Частично в следствии того что делалось итерационно, по частям, адекватными разработчиками, но не от в полной мере адекватного заказчика. Частично сам накостылил в коде. Есть и несколько коробочных багов и недоработок. Есть особенности самого сайта, не в полной мере соответствующие способу реализации и архитектуре выбранного решения. Есть наслоение из некоторого множества редко используемых модулей CS-Cart, не дружащих много с чем. Уйма всего, на самом деле. Но главным рукожопом во всём этом я считаю себя, пытаюсь потихоньку исправляться.


#25

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


#26

Основное что может в принципе убивать вам сайт это частые обмены с 1с, нужно настроить такой обмен в режиме обращения в случае изменений, либо же уменьшить такие запросы до более адекватного количества. Правильно коментировали выше что в случае изменеий в товрах происходит сброс кеширования, при большом количестве товаров это большой стрес для сайта, у некоторых клиентов разница в нагрузке на момент импорта увеличивается в десятки раз. Синтетические тесты которые вы проводили не являются корректными так как проходят в режиме когда не происходят изменения в системе, можно сказать только в режиме чтения. Множество клиентов падки на установку полностраничного кеширования, и это конечно в теории должно снять проблему, но кеш скрывает все проблемы которые возникают на сайте и в результате его наличие компенсируется медленными запросами к товарам у которых вышел ттл кеша, а если его ещё и скинуть то все успешно падает. Так же вы ограничиваете работу ряда динамических модулей, в общем вариант так себе и перечислять все возможные проблемы нету смысла. Конвертация в InnoDB действительно в ряде случаев улучшает производительность за счёт отсутсвия блокировок, но база более строго относится к наличию индексов, то есть да, можно, но аккуратно, так же InnoDB нуждается в более тонкой настройке, так же она подразумевает загрузку таблиц в оперативную память, нужно делать на это расчёт, все что не в оперативке будет работать медленее чем на MyISAM.

Предоставляем настроенные сервера, с нужными параметрами как железа так и софта. Все настроено, реализовано множество систем которые уменьшают нагрузку на сайт и ускоряют выдачу поисковикам https://zahid.host/ru/services/cscart/


#27

если вы записываете напрямую в БД, то как потом эти изменения отображаются на закешированных страницах?


#28

Всем привет, хотелось бы подвести итоги, проделали кучу работ и тестов:

  1. Увеличили ресурсы сервера в 2 раза - не помогло
  2. Перенастраивали LEMP по разным рекомендациям - не помогло
  3. Провели оптимизацию по размеру ресурсов (картинки, стили, скрипты и т.п.) - не помогло
  4. Протестировали сайт на других VDS у других хостинг провайдеров - не помогло, у одного результат был чуть лучше, но незначительно.
  5. Отчаявшись, методом исключения отключали модули и замеряли показатели GTMetrix - помогло

Подробнее о 5 пункте, дополнительных модулей довольно много, но на производительность влияют в нашем случае 3и, а именно: Google recaptcha, Google Marketing Tools и самописный для Callibri. Причём Google recaptcha и Google Marketing Tools вообще по жёсткому, Callibri по факту только подключает скрипт сервиса добавляет ID`шники для форм быстрого заказа и тормоза даёт именно внешний скрипт, но в сравнении с Google recaptcha и Google Marketing Tools не такие большие.
В общем если отключить все три, то показатели GTMetrix возрастают с E до B, TTFB c 1.2с до 686мс и полная загрузка с 10.1с до 2.6 Ну и визуально сайт начинает летать.

У кого нибудь есть идеи по данной проблеме? Что можно подкрутить?


#29

в консоли, наберите пожалуйста lscpu
покажите на каком процессоре ваш сервер


#30

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 8
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel® Xeon® Silver 4114 CPU @ 2.20GHz
Stepping: 4
CPU MHz: 2194.842
BogoMIPS: 4389.68
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
L3 cache: 16384K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cm ov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_ tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse 3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave a vx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx 512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveop t xsavec xgetbv1 arat pku ospke md_clear


#31

Слабоват процессор CPU MHz: 2194.842
Скорость работы CS-Cart зависит также от версии PHP, свежее-быстрее