Building a Better Webserver 286
msolnik writes: "The guys over at Aces' Hardware have put up a new article going over the basics, and not-so-basics, of building a new server. This is a very informative, I think everyone should devote 5 minutes and a can of Dr Pepper to this article."
Good article, but... (Score:5, Interesting)
Re:OSDN: Please read this (Score:2, Interesting)
Funny. What was our next closest competitor spent several million dollars on Sun hardware and everything done in Java. We spent less than $40,000 on some dual-proc Intel machines, doing everything with Postgres, Perl, and Apache. The result? Our servers have many times the capacity that theirs do, and they're almost completely out of business.
steve
True (Score:3, Interesting)
Once upon a time, we had 1 web server that did everything, so it needed to be able to do everything. Now everytime we do something new we toss out a new webserver (or 2 or 10 of 'em). And they all basically need to do one thing (webmail, portal, whatnot) and do it well and that's it.
So we've got a whole bunch of Apache servers which a bucket load of apache processes who basically spend all day doing little more than exec'ing the same CGI over and over (and copying the data around a couple of extra times).
I'm pretty much now convinced that would my next step is going to be to franken-meld my cgi with something like mini-httpd [acme.com] so it is a single, persistant, app.
I'm certainly not redoing the whole thing in Java though! :)
ode to SPARCstation 20 (Score:4, Interesting)
I remember using a Sun evaulation model at Rice many years ago... the machine had two 150 MHz HyperSPARC processors (though 4 were avilable for more $$), a wide SCSI + fast ethernet card, two gfx cards for two monitors, and some sort of strange high speed serial card (for some oddball scanner, I think). Not to mention 512 MB of ram, in 1994! The machine was a pretty decent powerhouse and sooo small! I sort of wish the concept would have caught on, given how large modern workstations are in comparison. Heck, back then an SBUS card was about 1/3 the size of a modern 7" PCI card.
Then there's the other end of the spectrum... one department bought a Silicon Graphics Indigo2 Extrme in 1993. The gfx cardset was three full size GIO-64 cards (64 bit @ 100 MHz = about 800 MB/sec), one of which had 8 dedicated ASICs for doing geometry alone. 384 MB of RAM on that beast. Pretty wild stuff for the desktop.
Ahh, technology. I love you!
Great new webserver, but... (Score:2, Interesting)
500 Servlet Exception
java.lang.NullPointerException
at BenchView.SpecData.BuildCache.(BuildCache.java:96
at BenchView.SpecData.BuildCache.getCacheOb(BuildCac
at BenchView.SpecData.BuildCache.getLastModified(Bui
at BenchView.SpecData.BuildCache.getLastModifiedAgo(
at _read__jsp._jspService(/site/sidebar_head.jsp:60)
at com.caucho.jsp.JavaPage.service(JavaPage.java:87)
at com.caucho.jsp.JavaPage.subservice(JavaPage.java:
at com.caucho.jsp.Page.service(Page.java:474)
at com.caucho.server.http.FilterChainPage.doFilter(F
at ToolKit.GZIPFilter.doFilter(GZIPFilter.java:22)
at com.caucho.server.http.FilterChainFilter.doFilter
at com.caucho.server.http.Invocation.service(Invocat
at com.caucho.server.http.CacheInvocation.service(Ca
at com.caucho.server.http.HttpRequest.handleRequest(
at com.caucho.server.http.HttpRequest.handleConnecti
at com.caucho.server.TcpConnection.run(TcpConnection
at java.lang.Thread.run(Thread.java:484)
Resin 2.0.2 (built Mon Aug 27 16:52:49 PDT 2001)
Re:Why Sun? (Score:2, Interesting)
Why did I chose sparc? Well its a tad quieter then a X86 box, smaller, and (and this is the point) it uses up a lot less power. The SS10 ships with a 65 watt ps (at least mine did). Considering you can get these things for less then 25~65 dollars they are a bargain (I paid 25$ for the SS10 and 65$ for the SS20). Anyhoo I kept my SS10 running for 30 minutes on a 300 va ups when the power went out last week - I doubt its drawing more then 25 watts peak. The software is still free since it runs debian linux well (and you can get sloaris for it too for free)
Plus - I have the added advantage that for some reason sun equipment is like a geek's dream - they look kinda cool sitting on the table next to the cable connection. Everyone who has ever come by has to comment on them somehow - either "whats that" - or "wow - you have one of those?". Don't get me wrong - there slow, (the SS10 has a cacheless microsparc in it), but the SS10 seems to keep up with the 4 megabit cable connection okay.
other factors (such as the router) (Score:4, Interesting)
Now, I realize modern hardware (Cisco 3660 and 7x00 series, and pretty much any Juniper) can route several T3s (at 45mbps each direction) worth of data, but older routers and minimally configed routers do exist.
There are MANY bottlenecks in hosting a website. Server daemon, CPU, router, routing and filtering methods, latency and hops between server and internet backbones, overall bandwidth thruput, and much more.
It's not as simple as "lame server, overloaded CPU, should have installed distro version x+1".
Re:What all companies should do (Score:1, Interesting)
Our company has worked similarly, but what we've begun to do recently is test our assumptions. We throw a test load against the server and then watch each component to see how it performs in reality.
I would have liked to see a real comparison between the two machines serving live web content. They don't do that.
Re:New Webserver? - not good (Score:3, Interesting)
Not quite as elegant a solution, but it's nice for preventing your web server from taking all of your bandwidth (if, say, you run it off your cable modem, and wish to continue gaming...).
Java Vs. PHP...multithreaded vs multiprocess? (Score:2, Interesting)
Speed shouldn't be the reason you switch to Java. If anything, I've found that PHP has been faster for simple web applications and page serving (and loads faster to develop applications with), while Java stands out as being more robust and stable.
fork'd childs use to much mem..... (Score:3, Interesting)
This means an Apache web server using keepalives will need to have more child processes running than connections. Depending upon the configuration and the amount of traffic, this can result in a process pool that is significantly larger than the total number of concurrent connections. In fact, many large sites even go so far as to disable keepalives on Apache simply because all the blocked processes consume too much memory.
::end quote::
lets see, anyone here hear of COW (copy on write) Linux uses this idea to save time on fork'd child processes, they get the
The only setback is when a process fork's a child, its current time slice is cut in half with half given to the child, so the main proc will run aground if to many requests come in and the server has more processes to worry about.
-ShadoeLord