ngx_pagespeed — статические ресурсы Gzip

Я пытаюсь найти лучший подход для моей коробки nginx. Моя цель — это, конечно же, максимально возможная производительность и лучшее время загрузки для моих пользователей.

Итак, я проводил нагрузочное тестирование своего nginx и — с помощью maxim-dounin с форумов nginx — обнаружил, что мои проблемы с пропускной способностью заключались в сжатии статических ресурсов на лету.

Мне придется предварительно заархивировать все в процессе сборки, это очень просто - и сделать gzip на лету для динамического контента только с уровнем компа @ 1 или 2, что сэкономит немного процессорного времени и позволит мне обслуживать столько пользователей, сколько возможно с экземпляром aws m1.small ec2.

Но я также намерен использовать ngx_pagespeed для оптимизации этих статических ресурсов, минимизации, объединения и т. д., которые так хорошо делает ngx_pagespeed. Я имею в виду, что с изображениями я могу работать и делать jpgoptim и pngoptim в процессе сборки, но совмещать css/js сложнее.

Я использую эту конфигурацию ngx_pagespeed:

pagespeed on;
pagespeed EnableFilters combine_css,combine_javascript,canonicalize_javascript_libraries,collapse_whitespace,convert_meta_tags,dedup_inlined_images,flatten_css_imports,inline_import_to_link,inline_css,inline_javascript,rewrite_javascript,remove_comments,rewrite_css,rewrite_images,convert_gif_to_png,recompress_png,convert_jpeg_to_progressive,strip_image_color_profile,strip_image_meta_data,insert_image_dimensions;
pagespeed JpegRecompressionQuality 80;
pagespeed FileCacheSizeKb            256000; #256mb
pagespeed FileCacheCleanIntervalMs   3600000;
pagespeed FileCacheInodeLimit        500000;
pagespeed FileCachePath /run/shm/nginx/pagespeed_cache;
pagespeed Statistics on;
pagespeed StatisticsLogging on;
pagespeed LogDir /var/log/pagespeed;
pagespeed LowercaseHtmlNames on;

Любые идеи о том, как ngx_pagespeed работает с nginx gzip_static? Я имею в виду, насколько я понимаю, ngx_pagespeed работает «перед» nginx, поскольку он кэширует все, что оптимизирует в tmpfs. Если сервер получил доступ к уже оптимизированному активу, он серверирует из tmpfs, и я искал gzip-файлы в папке кеша и не мог их найти. Во-первых, ngx_pagespeed выполняет сжатие? Он делает это на лету или кеширует сжатую версию?

Что происходит, когда он получает уже заархивированный ресурс от nginx (gzip_static включен)? Нужно ли распаковывать, а затем снова сжимать после оптимизации?

Как я могу получить лучшее из обоих миров — обслуживание предварительно сжатых статических ресурсов и оптимизация ngx_pagespeed?

Большое спасибо и с наилучшими пожеланиями.


person ddutra    schedule 04.10.2013    source источник
comment
Почему вы используете gzip_static? Если это связано с тем, что затраты ЦП на gzip слишком высоки, то ngx_pagespeed определенно будет слишком дорогим для вашей установки. ngx_pagespeed требует немного больше ресурсов ЦП, чем gzip.   -  person sligocki    schedule 07.10.2013
comment
Спасибо за помощь. ЦП — это ограничение, да, но также и пропускная способность сети машины ec2, которая составляет 30 000 КБ/с, поэтому мне нужно сбалансировать вещи. Я использую gzip_static, чтобы получить лучший уровень сжатия без потери процессора. Я знаю, что скорость страницы увеличивает нагрузку на процессор, но я действительно хотел бы, чтобы мои активы были оптимизированы, объединены, минимизированы, и у меня нет контроля над исходным кодом. Мой вопрос: ngx_pagespeed кэширует мои статические оптимизированные ресурсы в tmpfs. Каждый раз, когда пользователь нажимает на оптимизированный ресурс, ngx_pagespeed сжимает его? Или он хранит сжатый ресурс в кеше?   -  person ddutra    schedule 08.10.2013
comment
Судя по моим тестам, должно быть быстрее. Например, когда пользователь нажимает на такой ресурс, как [/css/A.print.css.pagespeed.cf.54Itr6v-Y8.css], он извлекается из кеша tmpfs и напрямую с сервера. Но пропускная способность не так хороша по сравнению с nginx, обслуживающим статический контент. Итак, мой вопрос немного изменился с тех пор, как я провел некоторое тестирование и прочитал об этом. Что делает ngx_pagespeed, когда [/css/A.print.css.pagespeed.cf.54Itr6v-Y8.css] попадает в цель, а актив находится в кеше? Он служит ему напрямую? Он сжимает и служит? Сохраняет ли он сжатую версию? Имею ли я контроль над этим?   -  person ddutra    schedule 08.10.2013
comment
Мы не кэшируем gzip-версию (хотя мы говорили об этом). Вместо этого несжатые ресурсы хранятся в кеше и сжимаются на лету.   -  person sligocki    schedule 09.10.2013
comment
Слигоцкий - Спасибо. Я влюблен в ngx_pagespeed, он просто работает, но потребление процессора слишком велико для моих серверов. Я не могу себе это позволить. Я считаю, что основная причина, по которой *_pagespeed потребляет так много ресурсов процессора, заключается в его сжатии на лету, верно? Потому что он кэширует оптимизированные активы в памяти и использует их как можно дольше. Это в значительной степени обслуживает статический файл. Можете ли вы поделиться причинами, по которым вы, ребята, решили не хранить сжатую версию в кеше (просто из любопытства). / Я собираюсь попробовать другое решение для процесса минификации. С наилучшими пожеланиями.   -  person ddutra    schedule 09.10.2013
comment
Рад, что тебе нравится, ддутра. Мы будем помнить об этом. Мы не поддерживали предварительное сжатие, потому что не думали, что это является узким местом в производительности, но, возможно, стоит переосмыслить.   -  person sligocki    schedule 24.10.2013
comment
К вашему сведению и всем, кто будет читать это в будущем, я смог достичь своей цели, поместив Varnish перед Nginx. Varnish кэширует сжатые версии ресурсов и страниц. ngx_pagespeed DownstreamCachePurge работает, как и предполагалось, отправляя запросы PURGE на лакировку, когда оптимизация (я думаю, работающая в фоновом режиме) завершена. Спектакль сейчас отличный. С наилучшими пожеланиями.   -  person ddutra    schedule 25.10.2013
comment
А, отличная идея. Вы должны опубликовать это как ответ.   -  person sligocki    schedule 28.10.2013


Ответы (1)


Я смог достичь своей цели, поставив Varnish перед Nginx. Varnish кэширует сжатые версии ресурсов и страниц. Очистка нисходящего кэша ngx_pagespeed (см. документы nxg_pagespeed для получения дополнительной информации) работает так, как предполагается, отправляя запросы PURGE на лакирование, когда оптимизация (я думаю, работающая в фоновом режиме) завершена. Спектакль сейчас отличный.

person ddutra    schedule 28.10.2013