Yoda

Вы меня, простите, но тут есть масса нюансов. Во первых 4x quemu - это может быть очень много, а может быть ни о чем. Все зависит от физического типа процессора. Во вторых необходимо внимательно посмотреть логи и отследить тип страниц, по которым эти самые боты ходят. В третьих, по возможности исключить или заменить "талантливые" модули, которые могут создавать на голом месте дикую нагрузку В четвертых, отказаться от генерации любых фидов-выгрузок через web-интерфейс. Ну а дальше теми или иными средствами исключать все бутылочные горлышки. К сожалению 100к товаров - это много. И просто взять и поставить волшебную таблетку на подобный проект не выйдет.

Нет не подгорает. Это не технический вопрос, а холивар.

Да кстати, если вам не нужен рф-айпи, то DO втопку. https://www.hetzner.com/cloud-ru 3 евры - ядро, 2 гига/20 гиг – это практически бесплатно. А ну еще -19%VAT.

Вы меня простите, я сарказм включу, но ваш вопрос звучит так. Приходите вы к проктологу, и говорите: доктор, у меня зубы болят, поставьте пломбу пожалуйста. Человек пришел с банальной проблемой, ему просто необходимо рабочее окружение для развертывания web-ресурса. Там нет ни слова о каких либо нестандартных реализациях. Мой опыт и специализация, позволяют мне утверждать, что ISP достаточно для его задач выше крыше. А также то, что подобное решение, заведомо избавляет от любых прямых или косвенных зависимостей бизнеса, от лишнего звена в виде системных администраторов, коих вменяемых днем с огнем не найдешь. Вы же рассказываете про какие то кастомные решения с транспортом почты. Вобщем это как теплое с мягким путать.

Пожалуйста, уточните, что лишнего для полноценной работы магазина в этих терминах? И есть ли в этом списке хотя бы один не критичный пункт. Также к вашему сведению, все задачи из этого списка пятая панель решает в один клик. И еще, уточните, что такого критичного не может сделать панель. К тому же, я выше писал, что панель закрывает 99% рутинных серверных манипуляций. Да даже если и не полный ноль, быть подвязанным под какого-то лохматого специалиста из-за 4 евро в месяц. Ну реально надо быть волшебным на всю голову.

Установка ISP, в случае, если человек умеет пользоваться putty - утилитарна как 2+2. Есть определенные моменты, которые могут потребовать некоторых услуг специалистов, но они не сравнимы с общими настройками, и самое главное с дальнейшим саппортом. Что касается вашего личного опыта. Давайте рассмотрим простую ситуацию: У вас 5 сайтов, вам необходимо под них иметь три разных версии php, автообновляемые let's encrypt сертификаты, 40 почтовых ящиков, регулярные бекапы, по 10 cron заданий, пару десятков ftp-пользователей, управление доменными зонами прямо на сервере ну и например автоматическую генерацию и выгрузку в dns зону dkim-записей. Если подобный огород будет поднимать наемный linux-администратор, и у вас нет навыков писать чуть больше чем apt-get, это 10-15 часов работы по 20-30 долларов минимум за настройку, и потом за каждый любой чих. Так что 40 евро и нормальный визуальный интерфейс для всей рутины, или же платить и каяться.

Я вам, как человек измученный нарзаном, немножко вангану. После того как вы найдете исполнителя, который вам это сделает, вы столкнетесь с еще кучей мелких и крупных проблем. За которые вам придется платить, платить и еще раз платить. Вместо этого, поставьте ISP-панель, заплатите 40 евро за год и забудьте о 99% серверных манипуляций. https://doc.ispsystem.ru/index.php/Установка_и_обновление_ISPmanager

Возможно вам проще будет понять это, поставив вопрос не с точки зрения "ставим запреты", а от противного. А какие собственно боты вам нужны? У вас есть трафик с BING, или Mail.ru. Ну и дальше просится логичный ответ, что надо разрешать посещения только тем ботам, которые нужны именно вам, и по возможности блокировать всех остальных.

У вас может быть любое количество причин: от очень большого количества дескрипторов сессий, до кривых рук системных администраторов. Также у вас фактически не 2000 товаров а для поискового бота 2000*100 = 200 000, что само по себе достаточно много. К тому же "мы добавили ядра" - а вы систему научили эти ядра правильно использовать? Еще. Если посмотреть на ваш график, то явно видно, что у вас существуют некие циклические повторяющиеся процессы, которые скорее всего вызваны какой нибудь генерацией тяжелых скриптов планировщиком. И скорее всего некорректно реализованным планировщиком. И напоследок, кроме Яндекса есть еще масса "полезных ботов". Поэтому ваша ситуация это совершенно не проблема, вам достаточно проанализировать паттерн трафика, отследить что создает пики, устранить причину, убрав узкие места и распределив по возможности нагрузку и закрыть все возможные узкие места, создав 60-70% запаса ресурсов от пика, для того чтобы подобная ситуация не повторилась. Если специалисты по свопам не помогут, стукните в начале следующей недели, возможно будет время посмотреть вашу беду.

US ip - да, нужен. http2 - не может уменьшить время загрузки де факто, так как он не об этом, а про доставку контента клиенту. Если честно ни разу не втыкал http2 на голом апач - не подскажу. В ситуации с nginx, есть определенные нюансы, связанные с версией установленной в системе openssl. Ip, чем ближе локально к пользователям, тем лучше. Что касается apache. Мое мнение - он должен маздай как класс. И даже если вы используете его, ставьте на фронт nginx, за счет этого намного проще решать целый ворох проблем, в том числе и http2. Ну а в целом, что касается уменьшения время ответа сервера. Это же сродни искусству.

Можно, но как показывает практика, всегда лучше работать в окружении, приближенном к максимально боевым условиям. Я бы рекомендовал поставить какую нить vestucp, если жалко 4 евро в месяц на isp панель.

Вопроса два. 1. Чем амазон отличается от любого другого поставщика вычислительной площадки (ну кроме того, что это облако). 2. Openserver зачем? LAMP LEMP не подходит?

jpegoptim не умеет сжимать! Это программное решение создано для выкидывания мусора из файлов. За счет этого получается уменьшить вес файла. На маленьких (порядка 1К) файлах вы можете увидеть результат существенный, т. к. мусор в виде дополнительной информации (какой фотокамерой снято, когда, каким редактором обработано и т.д. и т. п.) занимает объем, сопоставимый с полезной информацией. На средних и больших файлах выигрыш получается смешной в единицы или доли процентов. Чем больше файл, то тем меньше выигрыш. Компрессор умеет выкидывать мусор (также как jpegoptim) без стороннего софта и без включения сжатия (mozjpeg). Это в нем по умолчанию включено. Я не знаю с какой целью вы вводите людей в заблуждение, сознательно или нет! Надеюсь что вы это делаете по неграмотности, а не от неуемной жажды наживы на несведущих пользователях, но, если вы обратитесь к документации Jpegoptim, там можно обнаружить вот такой текст: Подскажите, в каком месте здесь нет сжатия? По поводу WEBP. К сожалению, у вас нет своего магазина, вы не знаете что такое цена клика, бюджет на рекламы, зарплаты сотрудников, зато вы знаете как удачно порождать мифы и продавать воздух. Так вот.... Не миф, а ФАКТ 1. Использование эскпериментальной необкатанной и не поддерживаемой большинством бразуеров и дополнений технологий и попытка навязать оную, является моральным преступлением по отношению к владельцам магазинов, да и всем тем кто ведется на ваше СУПЕР пупер рекламное сжатие. ФАКТ 2. Вы верно сказали, что mozilla - добавит поддержку в течении двух месяцев, а что там Safari? А сколько у людей трафика с apple устройств может быть? Опять я надеюсь это вы по незнанию, а не ради наживы а там и трава не расти.

Уберите пожалуйста наныр из комментария. Ваш путь вы можете узнать двумя способами, либо посмотреть в php_info(); Либо сделать просто скрипт <? $dir = dirname(__FILE__); echo($dir.'/image/');

Вот спасибо вам на добром слове. Это вы круто на флексах без бутстрапа. Лайк!

Не все так плачевно, как вы описываете. Работу того же мегафильтра можно привести в стандарты гугла. Просто необходимы определенные доработки механики фильтра. А именно, снос всех скриптов в футер, и либо отложенная инициализация рендернига dom-элементов фильтра, либо же его инициализация по нажатию кнопки. Равно как и весь остальной контент можно совершенно спокойно подгружать по мере прокрутки. Если внимательно проанализировать требования Гугла, то там нет ничего критичного и все логично. И основной посыл - как можно быстрее отобразите первый экран пользователю, а дальше делайте что хотите.

Как говорит народная мудрость - не все то золото, что блестит. В нашем деле, я бы сказал, не каждый шаблон продающий, который продающий. Но мы не про шаблоны, а про оптимизацию изображений. Как вы все уже знаете, Гугл обновил алгоритм оценки скорости работы сайтов и начал учитывать массу новых факторов, и повысил требование к старым. Одним из наиболее важных критериев оценки является размер, количество и вес изображений. Одним из способов облегчить этот процесс является технология LazyLoad - это просто и утилитарно, благо есть прекрасная библиотека на гитхабе для этой реализации, а если вам нужен lazyload в каруселях, то owl-карусель умеет это с пеленок. Также, необходимо обратить внимание, что картинки должны соответствовать физическому размеру на экране, поэтому как раньше отдать баннер шириной 1920 точек на экран мобильника с физическим размером в 480 точек не получится. Точнее отобразить то вы можете, но Гуглу это не нравится, и правильным вариантом будет использование либо библиотеки mobile_detect, которая будет определять тип устройства и в зависимости от типа вы уже сможете включить в верстку мобильной версии уменьшенное изображение, либо использование Responsive Image разметки и атрибута srcset и опять же изначальной подготовки нескольких превью под разные типы экрана. Lazy - это хорошо, но что делать с физическим размером изображений, ведь увеличение сжатия картинок в стандартной библиотеке opencart существенно снижает качество изображений. Выхода два. Либо покупать какой нибудь ОООЧЕНЬ ПОЛЕЗНЫЙ МОДУЛЬ, от которого будет больше вреда чем пользы, так как все подобные модули работают "на лету", тем самым тратят ценнейшие ресурсы для генерации страницы. Либо же все сделать своими руками за 10 минут, при условии, что у вас на хостинге установлены библиотеки jpegoptim и optipng. Если таковые не установлены, поинтересуйтесь, может ли хостер вам их установить, а если у вас свой VPS, то самостоятельно они устанавливаются из консоли в два счета. Установка для Debian/Ubuntu sudo apt-get install jpegoptim sudo apt-get install optipng Для RH/Centos yum install jpegoptim yum install optipng После этого необходимо запустить консольные команды, которые сожмут все существующие изображение в кеше. Путь к папке с изображениями вы можете увидеть в config.php файле. find {полный путь к вашей папке с изображениями}cache/ -type f -iname "*.jpg" -exec jpegoptim --strip-all --max=80 -P --all-progressive {} \; find {полный путь к вашей папке с изображениями}cache/ -type f -iname "*.png" -exec optipng -o7 -preserve -strip all {} \; И после этого уже добавить в cron команды для выполнения в ночное время с периодичностью раз в день и разницей во времени в пару часов. find {полный путь к вашей папке с изображениями}cache/ -type f -mtime -1 -iname "*.jpg" -exec jpegoptim --strip-all --max=80 -P --all-progressive {} \; find {полный путь к вашей папке с изображениями}cache/ -type f -mtime -1 -iname "*.png" -exec optipng -o7 -preserve -strip all {} \; В итоге мы получим абсолютно бесплатно качественную оптимизацию изображений, которую будет выполнять не скрипт php, а сервер, которая никак не будет влиять на время генерации страниц и создавать излишнюю нагрузку на систему в рабочее пиковое время.\ И да, если вы не понимаете что здесь написано и как это сделать - отправьте ссылку на этот пост администратору вашего хостинга-сервера, для людей с минимальной квалификацией здесь более чем избыточная инструкция. Также, если возвращаться к требованиям гугла, не забываем, что теперь увеличено время жизни кеша для картинок и статического контета и рекомендуется его сделать не минимальным в неделю а либо год либо вообщем max. И напоследок развеем еще один миф про Webp стандарт изображений. В нескольких ветках с пеной у рта, определенные люди рассказывают что это круто и вот тут будет поддержка. Webp - это может быть и круто, но использование его в магазине на сегодня - это не очень. И тому есть очень важная причина. Кроме хрома, нормально, этот стандарт не поддерживают другие бразуеры! До момента нормальной нативной поддержки может пройти еще очень много времени. Структура модулей и кеширования модулей магазина такова, что зачастую невозможно даже определяя поддержку браузера этого типа изображений отдать корректно контент без риска показать покупателю пустые страницы без изображений. Оптимизации изображений вышеприведенными в статье методами на 100% достаточно, для того чтобы выполнить требования гугла. Рисковать внедрением экспериментальных технологий, пусть и шибко разрекламированных - это так же как пытаться лечить смертельные болезни экспериментальынми средствами, может помочь, а может и убить. На этом на сегодня все, и да пребудут с вами зеленые попугаи! Небольшой апдейт. Тут пошли вопросы в личку типа: "и что, у нас будет все хорошо после этого"? Нет - сразу не будет - приведение в порядок изображений - это лишь малая часть, манипуляций, которые необходимо внедрить для получения высокой оценки PageSpeed на мобайл-устройствах.

Скажите, а почему 5, а не 2, или 500 рублей... Вот честно скажите. Вы же знаете объем работы приблизительно... Вы права думаете что специалист который может реализовать ваши хотелки будет три дня за пятерочку ковыряться, серьезно?

И что дальше... Что это меняет. Никто вам не мешает взять и привести в порядок под новые требования ваш адовый комбайн. Нет ни единого невыполнимого требования гугла в нынешних реалиях. Просто правила изменились, взять за три копейки и поставить тетрис 1000 в одном - уже не взлетает.

Поменяйте тут $_['cache_type'] = 'file'; // apc, file or mem на mem

К сожалению вы наступаете на те же грабли, что и все. WP или Opencart - это генераторы контента. Что вы наваяете, то и будет. А теперь давайте по пунктам, что вы там написали. 1. WEBP - не мастхев, пока, так как браузеры не поддерживают и вкрутить поддержку можно, но аккуратно. На оценку нового PageSpeed - не влияют. Если у вас нормально сжатый Jpeg. Ну и от Png надо максимально отказаться 2. PHP7 дает прирост производительности 10-30% и только на работе скриптов PHP, запросы в базу, никуда не деваются. 3. Кеширование всего. Это то еще счастье, зачастую на больших проектах от кеширования всего - наоборот надо отказываться, применяя иные стратегии оптимизиации. 4. Нормальное сео - это опустим. И теперь самое главное. Основное требование и идеология нового механизма оценки PageSpeed заключается в двух принципах. Страницы должны как можно меньше весить, и как можно быстрее отображать первичный контент пользователю. Попробую привести на пальцах примеры. Многие любят вывалить на главную страницу по 5-7 наборов (хиты продаж, рекомендуемые, статьи) и по 20-30 товаров в этих наборах. Это большой объем DOM-элементов, который пока мобильник отрендерит с тугим своим процессором, рак на горе свиснет. От того необходимо отказываться, а выводить на первый рендер экрана минимум элементов и дальше если необходимо подгружать весь контент скриптами, по мере взаимодействия пользователя с контентом. Второй пример. Это меню. Многие привыкли, просто немного видоизменить дизайн и сделать меню мобайл, а многие шаблонопейсатели еще и выводят клон дерева меню, создавая избыточное количество элементов на странице - проблема та же, чем больше элементов, тем дольше они рендерятся, а чем больше у вас скриптов, которые используют какие нибудь общие селекторы типа (div) тем дольше происходит обработка событий JS, и соответственно пользователь видит контент. Третий пример. Не буду тыкать пальцем, но практически все шаблоны типа тетрис 9999 в 1, в блоки товаров выводят кучу хлама, какие то спрятанные кнопки быстрого просмотра, дополнительные события на наведение мыши на изображения, никто не озадачивается разными размерами изображений под разные разрешения. Вот это вот все, теперь, если хотите хорошую оценку гугла, надо забыть. И подходить намного ответственнее к структуре страниц, которые уйдут на мобильные устройства. Ну и как-то никто не запрещает эксперементировать, отключать те или иные элементы страниц и сравнивать результаты.

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

Вам надо задать этот вопрос хостингу и узнать у них конфигруацию сервера memcache.

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

Не надо натягивать шар на глобус и делать пиар на недостоверных фактах. 1 Гугл как любил так и любит нормальный jpeg. 2. Webp имеет смысл внедрять с умом. Так как шаг влево шаг вправо и вы отдали пустой магазин без изображений клиенту. 3. Компрессор не мастхев от слова совсем. Так как оптимизация изображений по крону настраивается за десять минут и появляется более правильным решением чем тратить драгоценное ресурсы для сжатия "на лету. Я бы сказал что это не мастхев, а костыль для кривых хостингов, ещё и очень тррмознутый костыль. Дальше могу продолжать очень долго. Но работу над ошибками делайте сами.