snastik

Замечательные специалисты. Правды нет ни в одном ни во втором утверждении. Все зависит от структуры таблицы и количества индексов, и даже иногда, как это странно не будет звучать от того что у вас mariadb или mysql. На нагруженных проектах как одна из мер решить вопрос быстрого апдейта - это отключение/включение механзима индексов на время импорта. Что касается вопроса ТСа - то проблемы могут быть в чем угодно. В отсутсвии индексов, в некорректной конфигурации mysql сервера, в нехватке ресурса процессора, в плохом коде (откуда правда там взяться хорошему). И эти проблемы существуют почти у всех. Так как разработчик не тестируют свои решения на большом объеме данных. На демо заработало и ок. Тот же costas в своем модуле использовал не совсем корректные механизмы обработки данных, которые приходят из CSV, из-за чего на большой базе, в миллион товаров импорт экстремально замедлялся. В любом случае любую проблему необходимо первично диагностировать. А в данном случае все советы сводятся к попыткам тыкнуть пальцем в небо.

1. нужен 2. заморочек не много. 3. нет линейного прироста производительности. Если у вас одна страница прибавила +100 мс, то и все остальные прибавят лишь 100, в процентном соотношении производительность не вырастет!

Я не понимаю. При чем тут дисковый кеш. Рассказываю на пальцах. Есть сервер у него гигабайт памяти. Системные службы сервера потребляют пусть 200 мб. И дальше мы инициализируем поток PHP, который под преобразование картинки отожрал 100мб, под данные из базы еще 20, под json decode encode в этом процессе еще 50. И под инициализацию 20 экземпляров класса controller еще пусть 20. Итого, на генерацию страницы у нас ушло 210 мб. Страница генерируется секунду к примеру. И в этот момент у нас четыре банальных потока уже забрали всю память. Ну это несчастный случай, если у нас допустим сброшен кеш изображений. Если не сброшен - то ладно, 110 мб на поток. Это очень усреднено - но, учитывая, что в большинстве магазинов есть еще пара тройка AJAX запросов это х3. Предположим, за секунду мы получили 3 посетителя, два бота, и вот это ваше... Регенерация кеша (потому что кеш типа по вашему это круто), а быстрые магазины на холодную мы делать не умеем. Ок.. Три посетителя, два бота получаем минимум десяток потоков по 100 мб забрали памяти, пусть у нас гигабайт всего и еще пару свапа... Который очень медленный . И свап не всегда настроен. Мы получили лежачий сервер с минимальной нагрузгой. А еще там очередь лайтнинга стоит по прегенерации кеша, которая всегда. В итоге получаем лежачий падающий сервер, абсолютно дикую нагрузку при измененеях минимальных на товаре при сброса глоб кеша. И вместо хоть какого-то минимального эффекта, полную пессимизацию от поисковых систем, потому что они ходят на холодные страницы, которых нет в кеше - и они становятся еще тупеее... Зато покупатель модуля видет ничесе... У нас тут из файлов. Все быстро прочиталось отдалось на фронте как голый html. Ничесе снесли все скрипты в один файл пузомерка гугла подросла. А в итоге ни для конечного покупателя, ни для поисковых систем, нет эффекта. Сервер висит загружен этими бескончеными тупыми задачами прегенерации, запаса ресурса нет и не предвидеться. И холодные страницы как были, так и есть тупые. А то что в пик нагрузки, ресурсов нам надо хотя бы х3 от среднего. Да кого это волнует. Главное же у нас html из файла быстро считался-отдался. И пузомерка pagespeed нарисовалась. А в итоге - это как Арбидол. Стоит дорого, а результата ноль.

И в тот момент, когда происходит любой аномальный всплеск, или пик нагрузки, или вдруг директ включили. Происходит что? Происходит "падение сервера". Все что пишут в умных книжках про резервирование ресурсов, стабильность систем, тройной запас прочности. Просто пустые слова, потому что .... Ну так захотелось. Да конечно - это нормально. В другой солнечной системе, или на Марсе. Оставлять систему без запаса ресурсов. Скажите, а вы в трезвом уме этот комментарий писали ?

Это достаточно неоднозначный совет. Для того чтобы стартовать достаточно 2-3-4 модулей и начали продавать. Не получилось, бросили!

1. напишите мне в личку номер заказа и домен 2. вам нужно опубликовать модуль витрина категорий

Это однозначно фильтр. И фильтр плохой! Меняйте его хотя бы на мегафильтрпро или на ocfilter

ну вот там даже сказано что надо сделать, написать админу на форуме поддержки указать домен и номер заказа и получить ключ

Использовать сайтмап, который работает через php-cli а не через web.

Не занимайтесь голословием - это не профдеформация - это опыт. Ваш подход - типичный случай эгоцентричного пожирания времени разрабочтиков, неграмотным менеджером среднего звена с отсутсвием полномочий в принятии решений. Вместо конкретного подхода, вам зачем-то надо познакомится, огласить план и так далее.. Вы определитесь, вам шашечки или ехать? Нужен быстрый магазин или познакомиться? Возможно вам анализы еще какие-то понадобятся? Сразу определитесь со списком. Кровь, сахар, моча? А также давайте по честному.... Рейт $40-60 в час готовы оплачивать? Ваша задача - это минимум 10 часов. И мало того, ни один вменяемый разработчик с вами не свяжется без полной предоплаты. Не потому что с вами, - а потому что вменямые специалисты в принципе не работают без полной предоплаты.

Это прекрасно. ждем от вас план действий и сроки реализации И уходим на фриланс искать подешевле! LOL!

Все решается.

.htaccess неплохо было бы сделать.

Воу воу, не надо так нервничать. Все по другому и проще. Только ТСу ваша теория ни к чему, если он задает такие вопросы.

Интересно, а как вы увидите профайлером нагрузку, если у вас не выполняется до конца скрипт?

Видимо надо смотреть, что у вас с запросами.

1. В каком именно файле у вас происходит нехватка памяти? 2. Посещаемость людьми или ботами ни о чем ? 3. Просто приведу пример: сео про + его кеш на 170к товаров используют зеркальный массив keyword<>query. При формировании объекта с набором ссылок на ваш объем это уже может быть очень много, плюс возможно большие картинки и так далее и так далее. 4. ну и 1 гиг 1ядро на такой объем это смешно.

Простите, а что такое отличный показатель конверсии и где его показывают ?

Чтобы мне было понятно с кем я веду дискуссию, позвольте поинтересоваться вашей экспертизой и достижениями. Я напримр владелец нескольких магазинов, которые скоро разменяют первый десяток с общим объемом трафика более 20 тысяч уникальных посетителей в день и шестизначным маркетинговым бюджетом. А кто вы, чтобы со мной спорить ?

Ну это же не всем понятно. Это очень тонкий вопрос, требующий расстановки по местам понимания.

Скажите пожалуйста, есть Google - у него есть понятный инструмент, который понятным образом показывает показатели метрик произодительности? Какое отношение gtmetrix имеет к оценкам гугл ? А также, где можно узнать, как показатели gtmetrix и pagespeed от гугла влияют на позиции в Яндексе. Покажите официальную документацию документацию пожалуйста. Если таковой нет - то просто не лейте людям в уши глупости. Спасибо.

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

Извините, каким образом, если вы не понимаете что такое twig?

ocmod.log очистите

Причин может быть десятки.