Перейти к содержанию
  • записей
    6
  • комментариев
    18
  • просмотра
    1 504

О блоге

Коротко о главном!

Записи в этом блоге

 

Как сделать нагруженный скрипт, не отъедая память у клиентов и не покупая сервер как в Пентагоне.

Господа, все мы сталкиваемся с ситуацией, когда необходимо сформировать большой набор данных, сайтмап, yandex-market фид, и любая подобная задача, требует всегда очень много ресурсов. 
Большинство авторов таких дополнений слыхом не слыхивали ни про CLI-PHP, ни про возможность органично выделять ресурсы исключительно под собственные скрипты, не затрагивая общие настройки сервера. Про то, как делать CLI скрипты, я расскажу позднее, а сейчас поговорим про лимиты памяти, и почему нельзя пахабно относиться к ресурсам серверов клиентов.   Приведу пример, который произошел буквально на днях. Обратились ко мне старые друзья с просьбой посмотреть, почему падает магазин. Да они добавили 30 региональных поддоменов, увеличилась нагрузка, но это не повод, чтобы 4гб памяти и 4гб SWAP забивались за 10 минут.
Смотрим в настройки php_memory_limit 1gb. Система работает в связке nginx+php-fmp, и менеджер fpm резирвирует под каждый поток гиг памяти. Но нам то надо максимум 256МБ, для генерации любой страницы. Ок меняем настройки, немножко вносим тюнинг в конфиг php-fpm, все заработало, ресурсов хватает запас есть. Но из-за нехватки памяти отвалилась генерация YML, от одного известного автора.  И Яндекс-маркет блочит магазин. Новый год, продажи стоят.
Что делать?   Писать автору, скорее всего бесполезно. Я думаю, что любой автор сказал - увеличивайте ресурсы сервера, у вас нехватка памяти, вы сами виноваты, у вас большой магазин. 
Я даже уверен, что 99% авторов дополнений  так бы сделали.   Но послушайте. Ну есть же возможность задавать настройки "на лету" прямо из выполняемого скрипта. И просто достаточно было добавить в код генерации яндекс-фида одну строку:   ini_set("memory_limit",-1);   И все.. Для всех скриптов, которые приходят на web-сервер у нас 256мб лимит, и наших 4 гигабайт хватает с головой обслужить весь входящий трафик и ботов. 
И без вопросов у нас генерится YML, которому мы разрешили использовать память безлимитно.   Простейшая же задача как 2+2. Но продав более 1000 копий своего дополнения, автор даже не задумывался о подобных проблемах. 
Не будьте как автор!   И еще. Не стесняйтесь вместо формирования каких то супермассивов, сразу писать все в файл. Вместо какого нить  $thisoutYML->addItem($item), ведь очень просто делать $thisYmlSaveItemTofile($item).
  Ну и практически все фиды можно отдавать в .gz экономя место и время.

Yoda

Yoda

Улучшаем GooglePageSpeed | ImageCompressor своими руками за пять минут и общие советы по приведению изображений в порядок.

Как говорит народная мудрость - не все то золото, что блестит. В нашем деле, я бы сказал, не каждый шаблон продающий, который продающий. Но мы не про шаблоны, а про оптимизацию изображений.   Как вы все уже знаете, Гугл обновил алгоритм оценки скорости работы сайтов и начал учитывать  массу новых факторов, и повысил требование к старым.
Одним из наиболее важных критериев оценки является размер, количество и вес изображений.
Одним из способов облегчить этот процесс является технология 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 на мобайл-устройствах.

Yoda

Yoda

 

Оптимизация подсчета товаров Hello Toporchillo

Помнится мне в версиях 1.5.x появилась фича от Toporchillo  с модификацией запросов подсчета товаров при помощи SQL_CALC_FOUND_ROWS.
А я тогда говорил, что это бред! И правильно использовать второй полноценный запрос для getTotalProducts.
В 1.5 совсем плохо было с индексами и на небольших базах это возможно имело смысл. Но когда сейчас каждый второй магазин от 10 000 товаров, FULLSCAN всех таблиц участвующих в выборке товаров  в категории и механизм FOUND_ROWS скорее вреден чем полезен и вот вам подтверждение с официального блога Percona   https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/   Учиться, учиться и еще раз учиться! (c)

Yoda

Yoda

 

Убираем дублированные слеши в адресах страниц

Все мы хорошо знакомы с боленями опенкарта и дублями.
Но немногие заморачиваются с их устраненением.

Очень часто криворукие писатели дополнений не утруждают себя проверять код  и в вашем магазине появляются ссылки вида http://vash_magazin//////какой_то_адрес/?id=какой то айди   Убрать повторяющиеся слеши очень просто.
Достаточно добавить в .htaccess после rewrite base   вот такой код: RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s/{2,} [NC] RewriteRule ^(.*) $1 [R=301,L]  

Yoda

Yoda

 

iforum.ua

Кто будет iforum.ua ?  Перекличка. Есть вероятность 50/50, что я там буду, и если кто хочет получить от меня в рыло, или полезные советы - велкам!

Yoda

Yoda

 

Засвет пароля от mysql

А знаете вы, что в классе Mysqli, при включенных ошибках и отсутствии коннкета к базе светится пароль базы?
А знаете вы что Даниэль сказал, что это не баг а фича ? https://github.com/opencart/opencart/issues/5027

Yoda

Yoda

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.