Issue Autoupdate breaks my NGINX ... again...

[SpAcEDeViL]

Hy,

tonight plesk installed a automatic update for nginx....
But this update breaks the nginx service... again....

nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/plesk.conf.d/server.conf:31
nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/plesk.conf.d/server.conf:50
nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/plesk.conf.d/webmail.conf:7
nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/plesk.conf.d/webmail.conf:31
nginx: [emerg] unknown directive "pagespeed" in /var/www/vhosts/system/****.de/conf/vhost_nginx.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed

i had recompiled nginx with spdy and pagespeed a time ago... this was now replaced with the automatic update.

is it planed to compile nginx with pagespeed and spdy or is that not a good idea?

 

[IgorG]

At the moment, following modules are compiled for Plesk nginx:

# 2>&1 nginx -V | tr -- - '\n' | grep _module
http_v2_module
http_ssl_module
http_realip_module
http_sub_module
http_dav_module
http_gzip_static_module
http_stub_status_module
module=/usr/share/passenger/ngx_http_passenger_module

As far as I know spdy is not actual now - http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html
Regarding pagespeed, I can say that we are going to consider the possibility of including it to our nginx build. Prior to that, you can compile the pagespeed dynamic module each time by yourself.

 

[IgorG]

And, of course, vote for this feature here - https://plesk.uservoice.com/forums/...ions/4086004-add-google-pagespeed-integration
BTW, pay your attention to @trialotto comment there.

 

[trialotto]

@SpAcEDeViL

Question with respect to

is it planed to compile nginx with pagespeed and spdy or is that not a good idea?

and the question is: for what purpose did or do you intend to use pagespeed?

If I know that, it can be the case that I can point you to some directives, (static or dynamic) modules and/or alternative solutions that are more efficient than pagespeed.

Regards.....

 

[SpAcEDeViL]

Hy,

in my case, i use nginx for static content cache. Faster delivery with pagespeed.
This cache the files eg. under /var/cache/ngx_pagespeed/*siteurl*/

So i dont need a expensive cdn provider.

 

[trialotto]

@SpAcEDeViL

Well, if you only use Nginx for static content delivery (note the difference with static content cache), then you will not need PageSpeed or a CDN.

Moreover, if you "cache" static content, that would be a little bit odd: a static file is a static file, no need for caching.

However, dynamic content that is rendered and, after rendering, is cached as static content, that would be efficient and worthwhile.

Nevertheless, you (still) do not have the need for PageSpeed or any CDN for that matter.

Cache is and can be provided by opcache, at least to some extent. Just use PHP 7.0.x (which PHP version also makes any PHP based site faster)!

Cache can also be more effective by using caching mechanisms like Memcached and Redis Cache and note the following:

- Memcached can be supported as an Apache module, but also is associated with native support in Nginx (!),
- Redis Cache can be supported as an Apache module (and with some difficult tweaks can be entered on the Nginx side),
- it does not make sense to have Nginx (reverse proxy) + Memcached (native) or Redis Cache (custom compilation), when using caching mechanisms for dynamic content (Apache side!)

and, actually, the golden rule is that you, if you want to cache a static version of dynamic content, you should use modules on the Apache side.

By now, we can safely conclude that you can exchange the Nginx PageSpeed module for an Apache PageSpeed module.

Nevertheless, that would not be effective, certainly when taking into account that Apache is already memory hungry and PageSpeed module adds a lot to that!

So, given the fact that you can do a lot on the Nginx side, one can offload some workload on the Apache side.

The only thing left is to add the Redis or Memcached modules for Apache and simply "read" specific pages into and from memory, where Redis and Memcached based cached resides.

Have a look at this post, for the modules: https://talk.plesk.com/threads/redis-module-for-php-7-0-1-and-7-0-2.336648/ (I have to update them, but they should work fine).

In summary, forget about PageSpeed, just

- use Nginx to offload the workload for Apache: serve static content with Nginx and configure directives for headers
- use memory based caching mechnisms: the Redis or Memcached modules for Apache

and that is it.

And, in addition, if you really want to be "sneaky and tweaky" to allow more advanced settings, just

- create a CloudFlare account (note: use a free account)
- create a domain on Plesk (do NOT activate the Plesk CloudFlare extension(s) on this domain!)
- use CloudFlare´s lightning fast DNS and enter the before mentioned domain, with the IP pointing to your Plesk instance (allow the cloud to be orange, as in "active")
- copy js and css to the before mentioned domain (important: do not use the *.min.js and *.min.css files, only use the *.js and *.css files!!!)
- go the CloudFlare account and enable minification, caching, rocket loader (this is the one we need!) and so on

and you have a lot of the more difficult work being executed automatically by CloudFlare.

Actually, you then have two proxies: one Nginx on the Plesk instance, serving static files (note that a similar procedure can be used to get static files like images into the cache of CloudFlare, but that would not make any sense, see earlier made remarks), and a Nginx via CloudFlare, serving js and css (CloudFlare is Nginx based, as are most CDNs).

That is about it.

Hope it helps a bit!

Regards.....