Deploying a web server fast-OS/Distro/Tools?

I'm interested in your opinion on this topic. Let's say you want a web server up for development or testing ASAP.

Here are some requirements, but feel free to discuss solutions that don't address all of them.

- Fast to deploy, without requiring to read a manual that is TL;DR
- As little configuration files to edit as possible, and all the configuration files contain commented guidelines and examples. Automation of the menial work would be very appreciable.
- Can be used for standard configurations (Apache+Mysql+Php) but also for less common ones (LightHttpd+FastCGI+Ruby+PostgreSql)
- FTP, SSH and SFTP
- Steps to take are not likely to change much in the next few years.
- Bonus requirement: secure and performant enough to be actually usable for production too.

Windows 2003 (nt5,2)?
- check
- check
- somewhat
- not sure
- check
- check

You can run most this shit on a w32 box without reading a whole lot.. You can use apache and lighthttpd as webserver if you please and iis/6.0(only NT5,2) is actually pretty nice for ftp. Never tried any of the SSH and ruby stuff. Don't take this one too seriously tho, while w32 is easy to config it's not as easy to config correctly without reading a whole lot onto it.. For example the mysql for w32 sucks balls pretty much. Also most unix systems require quite a bit of configing with files and reading loads of manuals too. You might want to give a try FreeBSD or another BSD though, they are a very good platform for server. And also all linux distros are able to act as server to variable extent..

Basically anything you choose you're probably gonna have to scrap the first requirement alltogether cuz manuals is where most info is in.
It's up to personal experience in the end, you gotta try many possibilities and stick with the best compromise you find for urself.

or so I say...

Regarding the manual, I just want to avoid systems that require one that is TL;DR.

Windows as a server sounds like it requires knowing about Windows from an admin perspective, I think it's easier on UNIX for complex things.

I was already considering FreeBSD but I'd like to hear opinions about this.

LightHttpd+FastCGI+Ruby+PostgreSql
A winrar is you. Down with Apache and its insanity!

>Windows as a server sounds like it requires knowing about Windows from an admin perspective

Not neccesarily, win32 is a pretty straightforward to work os even without much previous experience. But if you read the manuals for unix you'll be able to work it faster than windows I do belive.

BSD is a good choise. That's what I'd use if I had a dedicated server.

Down with Apache and its insanity!

In what way is Apache insane?

Also, using Lighttpd and FastCGI when you're using Ruby is fucking retarded. It'll be slow no matter what you do.

>>6
It was some random example of unusual configuration.

In what way is Apache insane?
The config files.

Also, using Lighttpd and FastCGI when you're using Ruby is fucking retarded. It'll be slow no matter what you do.
Explain.

apache config files ain't that bad at all, mine is 134 lines minus virtual host stuff. But I guess a gui would be easier to use than a config file.

>>2

Substitute SSH with Remote Desktop.

>>9
how is a 134 lines config file small?

>>6
http://bougyman.com/miscfiles/RailsonDebian.html
People disagree with that.

>>10

Well RDP ain't the optimal on slower links :|, also a GUI is depending on the experience of the user slower than a CLI/SSH :|

>>9
Screw GUI, how about a syntax that actually makes sense. Like lighttpd's.

>>11
Hmm, I dunno, is it not? Seems rather small to me.. Maybe I'm comparing it to wrong things.. But 300 lines is still pretty short in my opinion. (note : it also includes line breaks and a few comments to sepperate different parts of the config for better human readability so that adds quite a lot. Annnd if I removed the modules I don't 'really' need I could get like 25 lines off of it.)

I'm not gonna argue wether apache config file is any good tho. I personally have no problem making sense of it, but lighttpd isn't an option for me so I haven't really tried alternatives.

I personally have no problem making sense of it

Moar liek "I have spent two days of my life learning the hard way about the weird voodoo and stupid idiosyncrasies  required to get Apache to serve pages that don't start by '500 Internal Server Error'" amirite?

>>8
Simple enough: Ruby is slow. Really slow. They're working on this, but it probably won't become mainstream for at least another year or two.

Most people who use lighttpd and fastcgi are probably after speed. This is premature optimization though, because you can have the world's fastest http daemon, and use fastcgi to keep from constantly recompiling the script, but it'll still be slow. Ruby is the primary bottleneck here.

The proper method is to generate static html through ruby, in which case you probably don't need fastcgi ruby processes sucking up ram that could be used for filesystem caching and http daemons. If your site is too dynamic for that, Ruby simply isn't a good choice for a high-load site.

Them's the facts.

May I suggest LAMP, P = PHP? If you're not after optimum performance, but productivity and "get it working fast", there are many packages that will install everything for you, XAMP I think is one of them, both for Linux and Windows whatever you prefer (I recommend Linux for servers, Windows for workstations to develop on). PHP is very productive, just be sure you're not all new to it and write shit because that's also easy to do.

>>17
I can't disagree with anything you say, however Ruby is plenty fast enough for my purposes and truth be told I don't even care about webserver speed; I switched to lighttpd not because of the fact that it claims to be faster than Apache, but because of the fact that I can actually configure the damn thing.

Oh incidentally I just thought of something I can disagree with you on:
The proper method is to generate static html through ruby
Untrue, a sensible caching policy will give you equivalent performance to static html without need to pregenerate it.

>>18
These packages can work as an integrated development platform, but not as a true separate server for testing purposes. Saying that PHP is productive is very discutable though, there are a lot of cases where it slows down the development of web applications.

>>17
Those performance issues require sites hueg like xbox to be a problem.

Untrue, a sensible caching policy will give you equivalent performance to static html without need to pregenerate it.

Equivalent? Impossible.

Static html can also be considered a form of caching, and I guarantee you it'll be faster. If it's static, the httpd will grab it, check any timestamps, and blast it out. If you're implementing the caching in ruby, the httpd has to call ruby, ruby digs around in the implemented cache, then returns the data, which is blasted out.

Now guess which one is faster? A lot faster?

If you want to use Ruby, go for it (and >>20 is correct regarding size), but pretending you can get certain performance characteristics when you can't won't help you any. Pragmatic programmer is best, amirite?