snastik

Можно, дорого!

Да без всяких проблем.

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

htop не идет предустановленным apt-get install htop или yum install htop Если у вас веста - посмотрите графики нагрузки на файловую систему и процессор. Если у вас там есть 100% пики загрузки - мало вероятно, но бывает, что даже на обработку ftp может не хватить ресурсов. Но с большой долей вероятности, если даже у вас проблема с фтп - это косяк хостера. Чтобы долго не искать проблему - попробуйте переехать на аналог к другому хостинг-провайдеру. Если не поможет - то надо искать проблему в системе, по косвенным признакам похоже на затык файловой системы при обработке папок с большим количеством товаров.

Потому что таков регламент, если вас он не устраивает вы можете обратится к администрации форума и запросить возврат средств

Вряд ли с таким подходом вам кто-то поможет.

Это не проблема магазина - это проблема ДНС. Запустите host-tracker и посмотрите доступность магазина из мира.

Обратитесь в саппорт, предварительно возспользовавшись https://mail-tester.com

Смена хостинга на структуру скриптов вашего магазина не влияет. А вот что касается влияния на выдачу. Очень хочется увидеть магазин, которому зеленые попугаи сделали рост трафика. По крайней мере по тем проектам, где мы делали даже 90+ оценку для mobile, именно от роста этой оценки не было ну вот абсолютно никакого толку!

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

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

Приложите подорожник! это даст 1000% гарантии защиты!

Возможно и скорее всего, вас уже взломали. А это просто заметают следы и наводят на ложный след.

Yu Menu - проблема раз. Revolution - проблема два. Старая версия Microdata - проблема три.

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

Завтра вам эта торговая площадка напишет - вот ваш личный кабинет, мы уже сделали - заходите, торгуйте, дайте денег! Если в логе какой-то непримечательный юзерагент последовательно перебирает товары/категории с маленьким таймингом - ну что это может быть еще? DDOS обычно выглядит по другому.

Что и требовалось доказать. Вместо бессмысленных дискуссий с гениями ночного кода, достаточно было всего навсего надо было найти причину. Судя по всему на 99% - это какой-то парсинг от конкурентов. Если есть доступ к конфе nginx настройте правила zone_req_limit, которые, отобьют подобные пакости на раз, в случае если ваши гости используют один-два-двести айпи. А вот если у них много прокси - то это не поможет и необходимо применять иные методы блокировки желающих попарсить.

Простите, я не знаю, что куда у вас относится. Но. У нас здесь не форум любителей теории "а как можно сделать бы". Если бы да кабы. Во рту выросли грибы. У владельцев магазинов и разработчиков нет времени и возможности вдаваться в тонкости специфики mysql, глубоко разбираться в принципах работы оптимизатора mysql, специфике innodb etc.... Человек пришел с конкретной проблемой. Я ему указал на все возможные причины и проблемы, тупиковые ситуации и вероятные возможности решения его проблемы. Вы же как это делают 99% программистов начали разводить какую-то теоретическую теорию, которая абсолютно бесполезна! Поэтому я вас попрошу впредь не вводить людей в заблуждение подобными комментариями, так как они по своей сути абсолютно бесполезны.

Вы сейчас показали себя как супер профессионал! Можно я стану в очередь за решениями? Что значит нет нужды оптимизировать запросы? Как жить человеку в ситуации, если у него паттерн трафика с 50% обращений в фильтры? Не оптимизировать? Да? Что делать если там посадочные? Забить.. пусть люди ждут 10 секунд загрузки? Зачем давать советы в том, в чем вы не разбираетесь? Смотрите логи! Анализируйте юзер агенты, частоту заходов.

Часть запросов которые вы показали - не очень шибко то поддаются оптимизации. Например вот этот... SELECT REPLACE(REPLACE(`text`, SSS, 'SSS SSS') AS `text`, `attribute_id`, COUNT( DISTINCT `tmp`.`product_id` ) AS `total` FROM( SELECT `pa`.`attribute_id`,`p`.`product_id`,`pa`.`text` FROM `df_product` AS `p` INNER JOIN `df_product_attribute` AS `pa` ON `pa`.`product_id` = `p`.`product_id` AND `pa`.`language_id` = NNN INNER JOIN `df_product_to_store` AS `p2s` ON `p2s`.`product_id` = `p`.`product_id` AND `p2s`.`store_id` = NNN INNER JOIN `df_product_to_category` AS `p2c` ON `p2c`.`product_id` = `p`.`product_id` WHERE `p`.`status` = NNN AND `p`.`date_available` <= NOW() AND `p2c`.`category_id` IN(XXX...XXX) ) AS `tmp` GROUP BY `text`, `attribute_id` Связано это с особенностями работы оптимизатора mysql с индексами на JOIN выборках, а также невозможностью быстрой работы mysql с полнотекстовыми данными. Здесь конкретно группировка по текстовому полю значений атрибутов - и это НЕ ОПТИМИЗИРУЕТСЯ простыми методами, типа индексов наставили и полетело. Если у вас подобные всплески происходят нерегулярно - лучше попробуйте найти что их вызывает - это могут быть паразитные боты к примеру, и попробуйте от них избавится.

https://www.mail-tester.com/

У меня есть решение. В личку.

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

У вас не в запросах проблема. А в количестве max_user_connections. Необходимо увеличить этот параметр.

могу только повторить свой предыдущий ответ