Good point. It probably makes a lot of sense to have a separate apache server to blast out images and style sheets.
I was, however, under the impression that the vast majority of the cost of a website is paying for bandwidth, so it doesn't make a whole lot of difference (cost wise) if the webserver runs half as fast. In fact, if you can save a $80,000/year admin by consolidating all your servers into ten identical boxes each serving everything, then perhaps it's cost effective, even if you have to pony up an additional $40,000 for hardware up front.
Anyway, it's surely not the answer for everyone, but probably something to consider. At work we're currently in the opposite end of the regime (and at my last job too). We're moving code from VB to C# and Java, so we're consolidating all of the disparate systems running god only knows what custom hack onto a few boxes running java and C#. We save both ways, more standard config means less to admin, more efficiency means less to pay for. If we were moving from native to Java the equation might be a little different, but it might still be worth it.
I do hear that tomcat is 1/5 the speed of apache serving static content, so if you're overloading your hardware already and static content is a big part of the mix, it's not for you.
First of all, I am a bit of a web admin. I write software all day, run my own website on my machine, and many of my past jobs were writing asp (shudder) and cgi of various sorts.
Basically I've always found that people get into trouble when they run webservers with excessive complexity. On a modern webserver, serving just about anything, the actual performance of the webserver software doesn't mean much, all the time is taken with DB interaction and custom code (cgi, jsp, etc..). I would therefore suggest that you try to simplify a bit.
I've tried jboss and tomcat and don't have any complaints. They work very well, and (at least from what I've heard) are very secure. No buffer overflows to be found, for obvious reasons. In addition, the portabiliity is nice.
Because of this you might consider trying to run tomcat without apache. The SSL in tomcat works fine, and it's easy enough to set it up so that it will serve both secure and non secure pages. This simplifies everything by placing the entire webserver (except for the cgi) in a single process. I've never really tried the cgi through tomcat, but I'm told it works so you might want to try it at some point. Not sure about PHP, and of course do a lot of testing and investigation before rolling this out into production (as if that even needed to be said).
If this works for you, you've eliminated all the OS/architecturre dependencies at once. In addition it'll help by cutting out one piece of software (apache), and might help security.
First of all, I am a physicist (BA in Physics, if that qualifies). Second of all, one of my professors (Yamura was I think his name, he's at Columbia, teaches physics 2900) was a bit of an expert in the field of superconductors, judging by the fact that there are graphs named after him. Here's basically what I understand from his short lecture on his current research.
Basically there are normal and abnormal superconductors (they actually have technical names, but I forget them). Normal superconductors are things like lead and mercury. Any material, if sufficiently cooled will eventually have its electrons form up cooper pairs and become a superconductor. These are not very useful because they need to be so cold.
The second group is entirely different. If you look on the graphs it's very clear that there are two lines. The normal superconductors fall on one line, and the abnormal (high temperature) superconductors fall on the other. Basically, it seems that the theory to explain the high temperature superconductors isn't really complete yet. They seem to function through a fundamentally different mechanism, so it's not clear that really understanding cooper pairs well will give us any help with them.
It seems that scientists always have to try to envision a use for their breakthroughs though, so I can't fault them for trying.
Anyway, that is my two cents.
-Tyler
This is not obvious at all. It was a windows crash that caused the great north eastern power outage, and that killed about half a dozen people.
I think that software crashes must be responsible for at least a hundred deaths a year, and that's probably a very conservative estimate.
-Tyler
OK, I"m sure I'll get flamed for this.
Most of the world's software should be written in managed code, end of story. For instance, Tomcat/Jetty/Jboss is also a web server, works very well, and to the best of my knowledge has never had a significant exploit. It's also easier to configure, and runs on basically any machine in existence (anything with a JVM).
Various servers and standard tools should almost always be managed code because it automatically hardens them against attack, reduces development time, eases porting, and basically makes them better behaved when bugs are encountered.
Windows lusers are quick to claim that windows gets more attacks because it has more users, that's BS. Apache has 2/3 of the websites, and gets fewer attacks than IIS. Similarly people will be quick to claim that there are no real java apps out there, etc... That is also BS. Virtually every proprietary app in business is java, there are various email programs, servers, a web browser or two, etc... No browser has ever been exploited through java, at least that I've ever heard, even though most of them do support java.
There is a reason why apache has fewer exploits than IIS, and java has fewer exploits than non-java, and it has nothing to do with marketshare. Java was just designed to be secure by default, and it shows.
Basically, whenever I see discussions about security, that is never brought up, and it should be. Face it, apache is no speed champ, and java is fairly fast anyway, performance just doesn't matter for (most) web servers. Basically, everytime I see an OSS project that isn't written in Java (and is therefore only available for a few platforms, buggy, and hard to compile/use) I ask myself "Why, god why do they do this...."
OSS has a lot to learn from businesses. Good businesses write their software in Java (and not bad businesses write in.Net:-)), and it doesn't really matter what it's for.
-Tyler
tjw19@columbia.edu
Slashdot Mirror
Good point. It probably makes a lot of sense to have a separate apache server to blast out images and style sheets.
I was, however, under the impression that the vast majority of the cost of a website is paying for bandwidth, so it doesn't make a whole lot of difference (cost wise) if the webserver runs half as fast. In fact, if you can save a $80,000/year admin by consolidating all your servers into ten identical boxes each serving everything, then perhaps it's cost effective, even if you have to pony up an additional $40,000 for hardware up front.
Anyway, it's surely not the answer for everyone, but probably something to consider. At work we're currently in the opposite end of the regime (and at my last job too). We're moving code from VB to C# and Java, so we're consolidating all of the disparate systems running god only knows what custom hack onto a few boxes running java and C#. We save both ways, more standard config means less to admin, more efficiency means less to pay for. If we were moving from native to Java the equation might be a little different, but it might still be worth it.
I do hear that tomcat is 1/5 the speed of apache serving static content, so if you're overloading your hardware already and static content is a big part of the mix, it's not for you.
First of all, I am a bit of a web admin. I write software all day, run my own website on my machine, and many of my past jobs were writing asp (shudder) and cgi of various sorts.
Basically I've always found that people get into trouble when they run webservers with excessive complexity. On a modern webserver, serving just about anything, the actual performance of the webserver software doesn't mean much, all the time is taken with DB interaction and custom code (cgi, jsp, etc..). I would therefore suggest that you try to simplify a bit.
I've tried jboss and tomcat and don't have any complaints. They work very well, and (at least from what I've heard) are very secure. No buffer overflows to be found, for obvious reasons. In addition, the portabiliity is nice.
Because of this you might consider trying to run tomcat without apache. The SSL in tomcat works fine, and it's easy enough to set it up so that it will serve both secure and non secure pages. This simplifies everything by placing the entire webserver (except for the cgi) in a single process. I've never really tried the cgi through tomcat, but I'm told it works so you might want to try it at some point. Not sure about PHP, and of course do a lot of testing and investigation before rolling this out into production (as if that even needed to be said).
If this works for you, you've eliminated all the OS/architecturre dependencies at once. In addition it'll help by cutting out one piece of software (apache), and might help security.
First of all, I am a physicist (BA in Physics, if that qualifies). Second of all, one of my professors (Yamura was I think his name, he's at Columbia, teaches physics 2900) was a bit of an expert in the field of superconductors, judging by the fact that there are graphs named after him. Here's basically what I understand from his short lecture on his current research. Basically there are normal and abnormal superconductors (they actually have technical names, but I forget them). Normal superconductors are things like lead and mercury. Any material, if sufficiently cooled will eventually have its electrons form up cooper pairs and become a superconductor. These are not very useful because they need to be so cold. The second group is entirely different. If you look on the graphs it's very clear that there are two lines. The normal superconductors fall on one line, and the abnormal (high temperature) superconductors fall on the other. Basically, it seems that the theory to explain the high temperature superconductors isn't really complete yet. They seem to function through a fundamentally different mechanism, so it's not clear that really understanding cooper pairs well will give us any help with them. It seems that scientists always have to try to envision a use for their breakthroughs though, so I can't fault them for trying. Anyway, that is my two cents. -Tyler
This is not obvious at all. It was a windows crash that caused the great north eastern power outage, and that killed about half a dozen people. I think that software crashes must be responsible for at least a hundred deaths a year, and that's probably a very conservative estimate. -Tyler
OK, I"m sure I'll get flamed for this. Most of the world's software should be written in managed code, end of story. For instance, Tomcat/Jetty/Jboss is also a web server, works very well, and to the best of my knowledge has never had a significant exploit. It's also easier to configure, and runs on basically any machine in existence (anything with a JVM). Various servers and standard tools should almost always be managed code because it automatically hardens them against attack, reduces development time, eases porting, and basically makes them better behaved when bugs are encountered. Windows lusers are quick to claim that windows gets more attacks because it has more users, that's BS. Apache has 2/3 of the websites, and gets fewer attacks than IIS. Similarly people will be quick to claim that there are no real java apps out there, etc... That is also BS. Virtually every proprietary app in business is java, there are various email programs, servers, a web browser or two, etc... No browser has ever been exploited through java, at least that I've ever heard, even though most of them do support java. There is a reason why apache has fewer exploits than IIS, and java has fewer exploits than non-java, and it has nothing to do with marketshare. Java was just designed to be secure by default, and it shows. Basically, whenever I see discussions about security, that is never brought up, and it should be. Face it, apache is no speed champ, and java is fairly fast anyway, performance just doesn't matter for (most) web servers. Basically, everytime I see an OSS project that isn't written in Java (and is therefore only available for a few platforms, buggy, and hard to compile/use) I ask myself "Why, god why do they do this...." OSS has a lot to learn from businesses. Good businesses write their software in Java (and not bad businesses write in .Net :-)), and it doesn't really matter what it's for.
-Tyler
tjw19@columbia.edu