What is the Nginx support like with Virtualmin?

12 posts / 0 new
Last post
#1 Sun, 06/03/2012 - 14:54
Brook

What is the Nginx support like with Virtualmin?

Looks like I might have to reload my server, and as I've considered using Nginx - I'm wondering what the Virtualmin support for it is like. Are there any restrictions for this set-up I should be aware of? Is it recommended? Have the developers seen any improvements in using it?

I'll be running some older PHP/Mysql websites, along with my newer Rails/PostgreSQL sites. Won't need awstats etc, just the ability to send/receive emails for each domain.

Tia.

Sun, 06/03/2012 - 15:11
Joe
Joe's picture

It is only recommended if you know you need nginx, and you know why. Most users will not see any significant advantages (performance, or otherwise) to switching from Apache to nginx, and there are some significant capabilities that are absent in nginx, like executing CGI scripts. This lack means several of the Install Scripts won't work with nginx (as they run via CGI). This isn't a huge number of apps, of course, but there are still a few.

nginx support is also considered beta software at this point. Most of the bugs we know about have been fixed, but it will be months or years before the level of testing reaches a point comparable to Apache support. And, since nginx has a far smaller feature set, Virtualmin necessarily can do less with nginx than it can with Apache. And, there is no Webmin module for nginx, as there is for Apache.

Please read the nginx plugin docs here for more: http://www.virtualmin.com/documentation/web/nginx

The important thing to know, I think, is that most users are not going to see a useful performance difference from switching to nginx from Apache. The vast majority of performance issues are found within your applications, rather than the web server. nginx may help in heavily loaded static sites, or in situations where memory is at a premium. It can also help in very high concurrency sites. So, unless you have a really strong nginx preference, I'd stick with Apache. nginx is really great software, but it'll be many years before it's got the level of tool support, experienced administrators to help you, and features of Apache.

--

Check out the forum guidelines!

Sun, 06/03/2012 - 16:11
Brook

Hi Joe,

Thanks for the reply.

I'm looking at Nginx as all my future sites are going to be Rails, and Nginx and Unicorn seem to be the defacto set-up for Rails sites right now.

My server requirements are pretty simple:

Ability to run PHP/MySQL sites
The latest Ruby (and Rails) versions
The latest Postgres
The ability to send/receive email for each domain on the server
Stable/secure etc

I don't need stats, spam filters, email virus checkers, ftp etc

Would Nginx still be a bad choice for me?

Sun, 06/03/2012 - 17:29
Joe
Joe's picture

I'm looking at Nginx as all my future sites are going to be Rails, and Nginx and Unicorn seem to be the defacto set-up for Rails sites right now.

If history is any indicator, the de facto setup for Rails will be something completely different in six months. We've seen at least five different de facto setups for Rails come and go since we added Rails support to Virtualmin. I'd recommend not worrying too much about trends in Rails deployment models, and focus on building great applications. The concurrency and deployment techniques will make far less difference than the app itself.

If you want Virtualmin to manage your Ruby on Rails deployments, it will be using Mongrel (regardless of Apache or nginx), but, of course, you're welcome to configure other backend web server options, like Unicorn.

I don't need stats, spam filters, email virus checkers, ftp etc

None of these have anything to do with the web server choice. They will be identical regardless of whether you use Apache or nginx.

Would Nginx still be a bad choice for me?

Probably, but you seem pretty set on doing it, anyway, so we'll try to help. ;-)

Seriously, though, nginx isn't "bad" or "good" in this context. It's just different, and much more limited in what it can do, than Apache. The things you've mentioned aren't relevant, but I suspect you'll find a few things along the way that Apache would make easier; I don't know what they'll be, but it seems likely.

--

Check out the forum guidelines!

Sun, 06/03/2012 - 17:56
Brook

Hi Joe

Thanks for the reply - I think you talk a lot of sense, I have helped me decide not to with Nginx for now :)

I installed mod_rails (phusion passenger) earlier and uploaded my partly finished rails site and was surprised at how well it handled it, so I really don't think I need the raw power of Nginx and Unicorn just yet - especially as the sites are not 'that' busy. Perhaps when they are, it might be worth a look.

Thanks for taking the time to reply - I'm just off to reply to your other post :)

Mon, 06/04/2012 - 10:01
wocul

I am also particularly interested in this. I do understand that nginx support still isn't as advanced - which is understandable given how long apache has been supported already.

However, I was wondering if there are any plans in place to work on a unified abstraction layer for some of the more common features of different web servers (think listen interfaces, port numbers, virtual hosts, forked processes, max connections per second - things like that).

I am really not thinking in terms of a complete 1:1 mapping here, just the more common, SHARED, settings that are typical for a web server.

If you could come up with such a wrapper/abstraction layer, then other developers could provide custom implementations for certain features, i.e. in the form of modules, that just do one specific thing, only.

I guess a feature to set up virtual hosts, could then be assembled by using some of the more low-level building blocks (set port, set directory).

Basically, I am trying to suggest to approach this in an orchestrated fashion, such that a simple layer is implemented - which can be extended by other VirtualMin users.

Obviously, parsing all these config files is really complex - but handling just specific options would seem to be much easier (as long as there's no dependency chain among features).

For example, it would be simple for me to provide a sed/awk or perl script to get/set (read/write) the port number from an nginx config file. Same goes for document_root and other "simple" config settings.

If we could come up with such an interface, then users could help providing all the required building blocks step by step.

And ultimately, the nice thing here is, that this approach would scale well - even for people who always need to use the latest/greatest technology (think rails folks).

Just wondering, you know....

Thanks

Mon, 06/04/2012 - 20:43 (Reply to #6)
JamieCameron

Virtualmin has two "abstraction" layers that provide webserver independence, which may be useful for you.

  1. All the Virtualmin API commands like modify-web and list-domains can work with both Apache and Nginx transparently. So for example you can run virtualmin modify-web --domain example.com --port 1234 to change the webserver port.

  2. A Virtualmin plugin can implement a series of Perl function to provide webserver functionality. The Nginx support is implemented in this way, but you could in theory add support for another webserver like lighttpd - if you know Perl.

''

Mon, 06/04/2012 - 21:08
wocul

Thanks for the insightful response. Then, it seems, everything that's needed is already in place - so it might be a good idea to document this technique slightly better, so that contributors can get started more easily.

Needless to say, I didn't look at any of the code in question - however, I am delighted to be proven wrong in this case.

Thanks again

Mon, 06/04/2012 - 22:12 (Reply to #8)
JamieCameron

Yeah, currently the API for integration with another webserver isn't well documented, as it is still in flux ... and I'm the only user of it so far.

''

Tue, 06/05/2012 - 16:54
Brook

I decided not to go with Nginx for now - as I'm not lucky enough to have sites that are busy enough to warrant the switch. But I will definitely be keeping an eye on it, or look sooner if I find my Rails site is a bit of a hog and needs it.

Wed, 06/06/2012 - 15:13
pcfreak30

Here is my take. I like the handling of nginx. It decent. I HATE the php cgi script setup. It needs to use FPM as if you run 5 sites on a 4 GB ram server it will eat up 80-90% of it.

I simply have to go and stop the php process and then delete the initd script. I then go and create a php-fpm pool conf for the domain and update the nginx config for it. Reload it all and its running very well. i use ondemand as well for memory.

So for now unless you want virtualmin to handle the bulk while you work around the bugs and bad implementations, just stick to apache....

Wed, 10/24/2012 - 08:09 (Reply to #11)
Doemela

I simply have to go and stop the php process and then delete the initd script.

What files are u talking about? php-fcgi-domain-tk Start Nginx PHP fcgi server for domain.tk <- ? and for the initd script where is that located?

How did u create the php-fpm pool conf for the domainand what did you change in the nginx config?

Regards Doemela

Topic locked