Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Building a Better Webserver

michael posted more than 12 years ago | from the slashdot-will-beat-a-path-to-your-door dept.

Hardware 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."

cancel ×

286 comments

Sorry! There are no comments related to the filter you selected.

Building a Better Squicker... (-1)

Trolligula (527461) | more than 12 years ago | (#2621401)

A JonKatz story...

CmdrTaco lay naked on the padded table. My power had
numbed him, body and mind; he was totally pliable. Still, the
straps were there for good measure.

I lifted his long brown hair, held it for a moment, then cut it
off with the shears. When there was nothing left but stubble, I
lathered his head with foam. Carefully, I shaved his scalp clean.

When I washed his head, he looked beautiful. I stripped, then
rubbed my cock and balls all over his smooth head. He sighed
gently. "Open your mouth and suck," I suggested, moving my
scrotum over his face. He complied, licking and sucking my aching
testicles. I pulled away with a smacking sound. He licked his
lips, eyes still closed.

I massaged those big, beautiful balls of his for a moment, then
reached for the scalpel. Rubbing my crotch once more against his
shaved head, I stepped back.

I licked a circle around his cranium, then moved up to lick his
eyelids and nose. Giving him a quick kiss (and feeling his tongue
greet me), I straightened and brought the knife down.

Cutting carefully, I opened the flesh around his skull. Soon, a
flap of skin hung down like hair. I gently lifted the top flap,
placing it over his eyes. I rubbed my penis against his bare
skull, feeling the coolness of the bone.

I picked up the saw. The small circular blade whined as I turned
it on, then went down in pitch as I pressed it against his skull.
Holding his head in place with one hand, I cut a large circle out
of the top of his head. I made sure to curve the sides inward
slightly.

With gentle, slow movements, I removed the section of skull.
Covering his exposed brain with gauze, I used the miniature sander
to smooth the sharp edges of bone. Dusting him off and removing
the gauze, I was ready.

He had been moaning quietly, and one of his hands was in his
crotch. I was hard as a rock. Remembering my anatomy lessons,
I slid the scalpel into his brain.

Holding my breath, I cut out a cylindrical portion of gray matter
above the so-called "pleasure center." Fortunately, the removed
area was not needed for life support. I popped the core into my
mouth, chewing and sucking out the tasty juices.

Setting the scalpel aside, I moved up to his head. My jutting cock
thrust against the small hole in his exposed brain. I slid into
him, very slowly.

He jerked. My penis must have pressed against a muscular control
area. God, he felt good! As his body twitched and spasmed, I
pressed my cock deeper into his brain. Every tremor was
transmitted to me as ecstasy.

As the head of my penis pushed further into his cerebral membranes,
his movement quieted. I felt the squishy top of his cortex, warm
and wet, press against my scrotum. Smooth bone touched my thighs.
Then I hit bottom.

He screamed. At first I was afraid I had hit the pain center by
mistake, but his movements proved me wrong. One hand was stroking
his cock, fingers working overtime. The other, wriggled free of
the restraints, pinched and pulled his steel-hard nipples further
than I would have believed possible. His body shook in an endless
orgasm, and his head would have whipped back and forth had my hands
not held it steady.

The sensations! Cock buried in the head of CmdrTaco, making him
come steadily, groin pressed tight against his naked brain, as his
tremors shook the tight cavity of his mental anus!

Grabbing his chin with both hands, I began to thrust. Pulling
partially out triggered involuntary spasms; pressing in caused
orgasms. My thighs slid into the depressions I had carved for
them, my crotch pressing hard against his juicy membranes. As he
twitched and jerked, I fucked his brain like there was no tomorrow.

I slammed into him one final time, sinking to the hilt in his slick
gray tissues. As he came and came, I spurted my come directly into
the pleasure center of his being. The pressure on that ultimate
G-spot sent him into convulsions; his body arched off the table,
breaking one of the straps. My fingers sank into the flesh of his
chin as I sought to hold his head tight against my crotch.

As my penis softened, he went limp. Picking up the low-pressure
water hose, I carefully washed the semen out of his channel.
Ripping his brain loose with my hands, I stuffed it into my face.
His body twitched once, then was still.

Re:Building a Better Squicker... (0)

Anonymous Coward | more than 12 years ago | (#2621419)

That was beautiful, man.

Re:Building a Better Squicker... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2621452)

truly classic suckdot.borg

How quick (0)

Anonymous Coward | more than 12 years ago | (#2621403)

Is quick enough ?

good read (0)

Anonymous Coward | more than 12 years ago | (#2621415)

good read

5 min and a can of soda (0)

Anonymous Coward | more than 12 years ago | (#2621427)

No posts yet. Looks like most are taking the advice.

Re:5 min and a can of soda (0)

Anonymous Coward | more than 12 years ago | (#2621574)

I had to dash off to the can, Dr. Pepper gives me the runs. Caffeine and prune juice, what a great idea!

What all companies should do (4, Insightful)

Delrin (98403) | more than 12 years ago | (#2621429)

But don't.
Actually a very interesting article, to be honest, in my 1 year of building webserver applications. I haven't gone through a process like this once. Usually we make a rough guess about how the application has performed (or more usually underperformed on existing servers, and just scale a percentile. As you can imagine, this is hardly realistic. Thanks for the read!

New Webserver? (3, Troll)

Archie Binnie (174447) | more than 12 years ago | (#2621431)

Lets see exactly how long their lovely new webserver stands up to a slashdoting... :)

(Maybe they just sent this so they could test it? Plan.)

Re:New Webserver? (-1)

Fecal Troll Matter (445929) | more than 12 years ago | (#2621479)

Let's see exactly how long your lovely karma whoring account stands up to mounds of my vomit.

Re:New Webserver? (1)

Archie Binnie (174447) | more than 12 years ago | (#2621552)

That's funny, I only have the one account. And I only say something when I have anything mildly interesting to mention. So.. well, I think it's a case of karma evny doctor...

Re:New Webserver? (1)

Iamthefallen (523816) | more than 12 years ago | (#2621528)

*bork* Looks like they should have gotten a bigger machine afterall, got halfway through it here...

Re:New Webserver? (1)

Iamthefallen (523816) | more than 12 years ago | (#2621597)

doh, I wish I learned how to copy and paste properly

Regarding load on their server [aceshardware.com]
Here you can see how the total number of threads varies with the workload throughout the day. The maximum number of concurrent threads shown here is 117. The average is around 90 to 100 until later on in the day when the thread count drops down into the 80s and then finally around 75 by midnight. Resident memory size for the web application (the entire Java process) remained at 260 MB for the entire day. In fact, it has never really grown far beyond this size. The size remains relatively static because the caches are a fixed size and the applications do not grow over time (i.e. no memory leaks). The database acquires a fixed amount of memory upon initialization, and it is configured to use 512 MB. Currently, the server reports a total of roughly 1 GB of free, unallocated memory. So, we have quite a bit of room to grow with our new system.

I really wanna see todays numbers...

Re:New Webserver? - not good (2)

victim (30647) | more than 12 years ago | (#2621529)

It is 15 minutes after the article post and the site is dead. I got to the part about calculating how much RAM was required per visitor and multiplying by the expected number of visitors.

Maybe they need to adjust their constants. :-)

It is those d*mn modem users that drive up the RAM use. They stay connected longer on their GET and tie up resources longer.

Re:New Webserver? - not good (2)

1010011010 (53039) | more than 12 years ago | (#2621584)

I'm thinking that their "better webserver" isn't so hot, considering the "connection refused" messages I'm getting.

Re:New Webserver? - not good (5, Informative)

john@iastate.edu (113202) | more than 12 years ago | (#2621662)

Well, lots of big iron gets crushed by the slashdot effect too. This thing is running on a piddly little Sun, after all. And it was very responsive early.

One thing that does seem to work against the onslaught is a throttling webserver [acme.com] . If you haven't got the bandwidth etc to serve a sudden onslaught of requests, probably the best thing to do is to just start 503'ing -- at least people get a quick message 'come back later' instead of just dead air.

Re:New Webserver? (0)

Anonymous Coward | more than 12 years ago | (#2621565)

It didn't, but what does one expect from a server bogging itself down with .jsp pages?

about 'that' long (0)

Anonymous Coward | more than 12 years ago | (#2621589)

Well, they seem to be slashdotted, now. Great webserver. *snicker*. Oh man.

Re:New Webserver? (1)

mummers (253129) | more than 12 years ago | (#2621592)

Unfortunately it doesn't seem to have stood up long enough to read the article. I suppose I'd better put my can back in the fridge...

Sigh, and I was hoping I could use it to justify a quad Xeon server with 4GB of RAM as the next web app's server on our 8 user LAN....

Re:New Webserver? ooh, ooh, it's up again!!! (1)

mummers (253129) | more than 12 years ago | (#2621610)

Aha! Realtime load dependant hardware upgrades! That's gotta be the plan!

Now let's just see...

Re:New Webserver? (2)

Cylix (55374) | more than 12 years ago | (#2621616)

We showed them...

Looks like they might to revisit their approach to building a better webserver.

It is hard to say if we have maxed their bandwidth or maybe given the server a real life lesson in load.

I suspect the article might get a rewrite ;)

Unfortunately I wasn't able to get past the first page, but me thinks the next article would introduce additional server's and some load balancing.

[Slashdot Seal Of Death]

Re:New Webserver? (1)

ivanandre (265129) | more than 12 years ago | (#2621682)

its already slashdotted...

sweet and bitter irony, isnt it?

Re:New Webserver? (1)

pimpinmonk (238443) | more than 12 years ago | (#2621683)

No, I don't think they are that intelligent. Their server uses java server pages!

http://www.aceshardware.com/read.jsp?id=45000240

No, I haven't seen it yet, it's totally slashdotted. ;o)

Legal Question: @# (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2621434)

What is the opinion of Ace Hardware's lawyers
on the similarity of www.aceshardware.com to
www.acehardware.com?

People want to know.

Best webserver to generate traffic (4, Funny)

Typingsux (65623) | more than 12 years ago | (#2621439)

Get IIS and no code red patch.
Instant traffic to your site, no advertising!

Re:Best webserver to generate traffic (2, Informative)

czardonic (526710) | more than 12 years ago | (#2621598)

You'd get the traffic to your site no matter what server you run. Code Red would just pump up traffic from your site.

Re:Best webserver to generate traffic (1)

josquint (193951) | more than 12 years ago | (#2621707)

LOL

But, Officer, I swear i didnt write code red as a virus, just a web server load tester!

looks good so far... (1, Redundant)

turbine216 (458014) | more than 12 years ago | (#2621449)

going on 5 minutes after the initial posting, and still no slashdotting...

Seems to me that these guys might be onto something here...or maybe they just really know what they're talking about...

Re:looks good so far... (2)

Griim (8798) | more than 12 years ago | (#2621570)

It's 5:06pm EST, and it's already slowing down from when I started reading it. Had one page fail to load, but then it recovered upon reloading.

Re:looks good so far... (0)

Anonymous Coward | more than 12 years ago | (#2621648)

It is about 5:22pm EST and I don't have any access. Let the SLASHDOT begin

Quick page, good read (1)

guinness_duck (231583) | more than 12 years ago | (#2621450)

Well it did load quickly.

It was a good read and I wish we could do something vaguely similar with our web servers here. Not that we get the server load to demand such improvements at the moment, but I figure it's best to spend the money early on, get a good setup going that can handle high volumes, that way you're not caught with your pants down when things take off for you. It's unfortunate bean counters never think this way.

Of course I don't think I'll be taking this approach at home - even if it would be fun to have a Sun Blade sitting in the living room purring along answering the 1 or 2 web hits we get a day.

Re:Quick page, good read (5, Insightful)

DavidJA (323792) | more than 12 years ago | (#2621545)

but I figure it's best to spend the money early on, get a good setup going that can handle high volumes

Throwing money at the problem is exactly the WRONG approch. You need to start by spending time PLANNING and RESEARCHING the best way to do things.

For example, if you are setting up a dynamic site like ./, which is serving 100 pages/second. It obviously needs to be dynamic, so you need a database to store all the comments in.

There are two ways to do this, one is to serve content straight out of the database, but this means that for every page you serve up, there needs to be a database query. (the database queries are the expensive part in terms of time it takes to serve a page). The other way would be to serve the articals as static pages which are generated every minute or so by a process on the database and pushed down to the web server, which serves these up as static pages.

The advantage of this is that insted of 100 database queries per minute, you end up with, maybe 10 queries per minute to populate the static pages. Sure, you site is no longer 100% dynamic, but it is a whole lot faster, and you have saved thousands of dollars to boot!

This is just one small off-the-top-of-my-head example of where PLANNING sould become way before spending any money.

Re:Quick page, good read (5, Insightful)

NerveGas (168686) | more than 12 years ago | (#2621703)

<but I figure it's best to spend the money early on, get a good setup going that can handle high volumes>

Actually, that's a terribly wasteful way to go. If you work on an easily-scalable infrastructure, then you can pretty much purchase capacity as it's needed, which not only frees up capital for a longer time, you end up spending a lot less, as the price of computers is always dropping, and the performance is always going up.

steve

Why? (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#2621451)

from the slashdot-will-beat-a-path-to-your-door dept
Why would I want you bunch of turds, rejects and losers at my house? I live in a good area, you'd lower the property values.

OSDN: Please read this (-1, Flamebait)

NineNine (235196) | more than 12 years ago | (#2621459)

Considering Slashdot is one of the slowest sites on the Net, and crashes frequently, I think that the Slashdot owners should really read this.
I think the part about Java/Resin is the most crucial. Anybody can throw hardware at a problem, but their programming methodolgy makes tremendous sense (ie: dump this Apache/CGI garbage in favor of real multithreading). Also, they don't mention the database they use, but I'd be willing to bet good money that it's NOT MYSQL!

Re:OSDN: Please read this (1)

fatboy (6851) | more than 12 years ago | (#2621515)

Considering Slashdot is one of the slowest sites on the Net, and crashes frequently, I think that the Slashdot owners should really read this.

aceshardware.com _JUST_ fell over. I guess it couldnt keep up with /.

Re:OSDN: Please read this (0)

Anonymous Coward | more than 12 years ago | (#2621546)

While I can hardly argue with the MySQL bit, but if you think a site this big does (or possibly could) run via CGI, you're incredibly inexperienced.

Weblogic, complete with native performance pack (since the stock java one-thread-per-connection model could never scale) is still slower than a well tuned Apache server..

Apache is fairly slow, but Java is slower. What it comes down to is that Apache is always fast enough to saturate whatever bandwidth you have. If you have a large amount of bandwidth, you've already clustered for relability.

If you're worried about truely high performance on a single CPU (by far the most common case for webservers) an event driven single process model will destroy both a multithreaded and a multiprocess model.

Optimizing your webserver for SMP machines is stupid, since webserving is trivially paralellizable, and clustering gets you better reliability and is usually cheaper in these days of inexpensive 1U servers...

Re:OSDN: Please read this (2, Interesting)

NerveGas (168686) | more than 12 years ago | (#2621550)

<I think the part about Java/Resin is the most crucial. Anybody can throw hardware at a problem, but their programming methodolgy makes tremendous sense (ie: dump this Apache/CGI garbage in favor of real multithreading)>

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

Re:OSDN: Please read this (4, Informative)

trb (8509) | more than 12 years ago | (#2621558)

"Real multithreading" is really no panacea. See the notes from John Ousterhout's talk, Why Threads Are A Bad Idea (for most purposes). [softpanorama.org]

"Real Multithreading" considered harmful (2)

john@iastate.edu (113202) | more than 12 years ago | (#2621632)

True -- often it's simpler to 'roll your own' multithreading with select/poll/etc.

It's pretty easy to just do:

for (;;) {
n = select(...);
perConnStructPtr = getPerConnPtrByFd(anActiveFd);
...
}

after all.

Re:OSDN: Please read this (0)

Anonymous Coward | more than 12 years ago | (#2621634)

I read through those slides, and the biggest drawback to threads given was that people are too dumb to use them properly. While I certainly agree with that sentiment, it doesn't make using threads bad in and of itself.

I also disagree with the assertion that concurrent execution is an exceptional case rather than a typical case. It may be exceptional in terms of individual steps being performed, but it's been my experience that it's a common occurence on an application level. Simplistic GUIs work well with event-driven approaches. Most tasks could be 90% handled by event-driven approaches. But a lot of operations have some subtasks that would be better handled by concurrent execution.

Re:OSDN: Please read this (3, Informative)

Lumpish Scholar (17107) | more than 12 years ago | (#2621692)

Ousterhout says threads are bad for apparent concurrency but good for taking advantage of multiple processors, and for building scalable servers.

In other words, with the right hardware architecture, threads could be very useful for sites such as Ace's Hardware (though they happened to go with a uniprocessor) and Slashdot.

Java threads are also easier to program than C and C++ threads, though not easy. (Manual memory management is hard; thread programming is hard; manual memory management in a threaded program is very hard. I'm not speaking hypothetically on the last point; I've really envied Java programmers the last few weeks.)-:

True (3, Interesting)

john@iastate.edu (113202) | more than 12 years ago | (#2621573)

Apache is cool and all, but I wonder if it is still the right tool for a lot of sites -- it has every feature under the sun, but it seems to me that more and more sites are getting more and more specialized and thus needing less and less of these features.

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! :)

Re:True (0)

Anonymous Coward | more than 12 years ago | (#2621677)

If you're just doing it for fun and some experience, go make your bastard half-breed.

But if you're just interested in better performance you could get 95% of the way there just by switching to fast-cgi.

And if you want absolute balls to the wall performance, rewrite as a user-space TUX module (writing kernel space modules gets you next to no speedup, and its much harder to debug).

Re:True (1)

john@iastate.edu (113202) | more than 12 years ago | (#2621732)

If you're just doing it for fun and some experience, go make your bastard half-breed.

I wouldn't say an application that directly implements the HTTP protocol but isn't a general purpose web-server is a half-breed. SWAT is one well-known example.

But if you're just interested in better performance you could get 95% of the way there just by switching to fast-cgi.

A reasonable course of action for a general-purpose web-server, but when you've got a CGI that is doing everything anyway, I don't see the value in keeping the first tier.

And if you want absolute balls to the wall performance, rewrite as a user-space TUX module...

That's an incorrect platform assumption...

Re:OSDN: Please read this (1)

Eloquence (144160) | more than 12 years ago | (#2621590)

Considering Slashdot is one of the slowest sites on the Net,

Actually Slashdot is usually one of the fastest site on the Net for me. I frequently use it to test if my DSL connection works properly. Their scripts/database often get hosed at high loads, though, I wonder what the bottleneck is. But Java as a replacement? Puhleeaze..

Re:OSDN: Please read this (2, Informative)

dmelomed (148666) | more than 12 years ago | (#2621626)

Bah, speak for yourself. Java relies on the virtual machine, so that's your bottleneck (as in beer and performance). With proper software (like the new version of Apache still in beta) and tuning, or other threaded servers like aolserver or Xitami and PHP or modperl instead of Java I bet my money _that_ configuration will scale better.

Also, don't confuse the CGI protocol with short-lived CGI binaries. Slashdot uses modperl, whcih is NOT a short-lived process, but Apache is still a forking server in the 1.3.x branch.

Offtopic XBox server (2, Funny)

SilentChris (452960) | more than 12 years ago | (#2621466)

Offtopic somewhat, but some people are halfway there to upgrading the XBox to a decent Linux server.

Note this article [icrontic.com] for information on connecting USB keyboards and mice, what shorting the debug pins does on the keyboard, and replacing that measly ATA33 hard drive cable with an ATA100 (surprise, surprise: it actually increased performance :) ).

Re:Offtopic XBox server (1, Offtopic)

SilentChris (452960) | more than 12 years ago | (#2621485)

Uh, that's meant to say shorting the debug pins on the *motherboard*. Although, if you find a keyboard with debug pins, let me know. I'd be curious to see what happens...

*Congratulations screen: you can now type in Swedish Chef! Bork, Bork, Bork!

Re:Offtopic XBox server (0)

Anonymous Coward | more than 12 years ago | (#2621609)

The ATA33 hard drive cable...connected to the SCSI Hard drive? I'd like some of what you're smoking, please.

Quick Guide to Building a Web Server (1, Troll)

jd (1658) | more than 12 years ago | (#2621478)

  • 1. Start off with deciding what you want on it.
  • 2. Delete, destroy, burn, remove, obliterate anything and everything that isn't on that list.
  • 3. Since the information is likely already on the Internet already, save yourself the time and effort, and burn the list, too.
  • 4. If you insist on going ahead, the order of precidence is: Speed of response, usability, readability, quality, accuracy, honesty, believability. People will believe anything that's delivered to them quickly. Just ask the Afghans.
  • 5. Trust nobody and nothing. Distribute widely. Keep your laser handy. Alpha Complex will be completed shortly. Please wait.

For nails, hammers and light bulbs maybe, but (0)

Anonymous Coward | more than 12 years ago | (#2621481)

is a hardware store really the right place to shop for a server?

talking about better web server. (2, Funny)

2Bits (167227) | more than 12 years ago | (#2621487)

If you have a slashdot-proof server, that's a better web server.

What a load of ...you know. (0)

Anonymous Coward | more than 12 years ago | (#2621488)

They should have used Zope.

Good article, but... (5, Interesting)

Computer! (412422) | more than 12 years ago | (#2621493)

Microsoft [microsoft.com] has written several white papers [microsoft.com] of this sort already. Of course, they're Microsoft, so that means I can kiss my +2 bonus goodbye. Seriously, though.

Re:Good article, but... (0)

Anonymous Coward | more than 12 years ago | (#2621578)

The topic of the article is "How to Build a Better Web Server". The pages you link to describe how to setup a web server using IIS. You're OffTopic.

Why not get the server version - Netra X1? (2, Informative)

msolnik (536110) | more than 12 years ago | (#2621496)

Why would they go with the desktop version when they want a rackmount server? You can get the Netra X1 for 50$ less and it comes with the exact same hardware but in rackmount case. Check it here [sun.com] .

Re:Why not get the server version - Netra X1? (1)

Penis_Envy (62993) | more than 12 years ago | (#2621735)

The main reason why I did not get the X1 is that it does not have an optical (cdrom/dvdrom) drive. Yes, jumpstart rules, but it's more of a pain that popping a cd/dvd into the drive and booting off that.

/.ed (0)

Anonymous Coward | more than 12 years ago | (#2621506)

Already /.ed. Next.......

/.ed (0, Redundant)

terradyn (242947) | more than 12 years ago | (#2621516)

Well, it looks like the new server was unable to handle the load from us. It's not responding at all...

Re:/.ed (0)

Anonymous Coward | more than 12 years ago | (#2621615)

Hmm... The 5 minutes is to wait for their new super fast server to respond?

Re:/.ed (0)

Anonymous Coward | more than 12 years ago | (#2621726)

That's right, because its connection is saturated. Doesn't matter what kind of webserver is running, if there's not enough bandwidth.

I usually... (2, Funny)

nll8802 (536577) | more than 12 years ago | (#2621522)

I usually get a decent speed processor PIII 800, a really fast scsi drive or raid (Depending on the site), 512MB of ram ( Or more depending on the site ), and a copy of Slackware.

Re:I usually... (1)

NerveGas (168686) | more than 12 years ago | (#2621643)

Meself, I never hesitate to use multi-processor machines. While the increase in capacity is always nice, it's the increase in responsiveness under load that really makes them shine.

steve

A can of Dr Pepper ? (-1, Offtopic)

Rontudju (72873) | more than 12 years ago | (#2621533)

i don't think so.
nothing, nothing in the world could make me drink dr pepper ever again.

A man with a bad experience

Am I the only one... (2, Funny)

Schwamm (513960) | more than 12 years ago | (#2621536)

who couldn't figure out at first why Ace Hardware [acehardware.com] put up information about a new webserver?

Re:Am I the only one... (0)

Anonymous Coward | more than 12 years ago | (#2621568)

Yes, you are.

Learn to read, then come back.

Re:Am I the only one... (1)

MrDolby (303452) | more than 12 years ago | (#2621601)

Yep if you read the article they explain why on the first page. (or maybe it was the second page)

Re:Am I the only one... (1)

Schwamm (513960) | more than 12 years ago | (#2621625)

Maybe you should check my link. ;-)

Update (2, Redundant)

Karma 50 (538274) | more than 12 years ago | (#2621542)

It would be interesting to see an update from them tomorrow with the same graphs as on the Servers in Practice [aceshardware.com] page with today's data.

Their site is slowing down under the /. load.

Suprise, Suprise! (0, Redundant)

Poppageorgio (461121) | more than 12 years ago | (#2621543)

Hmm.... New server huh? Can't connnect, so apparantly it can't take being slashdotted....

Re:Suprise, Suprise! (0)

Anonymous Coward | more than 12 years ago | (#2621740)

Has nothing to do with the server, you ignorant sack of puss. The /. effect saturates the server's internet connection.

Down already? (2, Funny)

ParisTG (106686) | more than 12 years ago | (#2621551)

Should we really be taking advice on building a web server from someone who's server crashes under /.s load?

Re:Down already? (0)

Anonymous Coward | more than 12 years ago | (#2621716)

It didn't crash, you idiot. Bandwidth is saturated. The /. effect isn't about knocking out a machine, it's about saturating its connection.

Devote my time? (2)

Arethan (223197) | more than 12 years ago | (#2621554)

"I think everyone should devote 5 minutes and a can of Dr Pepper to this article."
5 minutes my ass. Now that me and 250,000 other people are all trying to access their server within the same 15 minute timeframe, it's going to be a good 5 minute wait per page. Lol!

the Ultimate Webserver is... (4, Insightful)

GCP (122438) | more than 12 years ago | (#2621556)

...the one with a lot of mirrors.

good but... they discounted x86 to fast (2, Informative)

azephrahel (193559) | more than 12 years ago | (#2621567)

It really feels like they only made a token gesture towards using an x86 box. To be honest my next box will probably be a sunblade too (but hey, I'm gonna use it for a desktop ;) Mind you this was a really good article, but I think they should have said that they were just more comfortable with sparc and that was that. There was another good article on a similar subject not long ago, on Anandtech's new server [anandtech.com] . For that article they benchmarked different configs (mobo, proc, etc) then did a price performace.. as far as I recall. And they chose AMD ;)

Re:good but... they discounted x86 to fast (1)

NerveGas (168686) | more than 12 years ago | (#2621633)

If you compare the straight performance of an X86 CPU to a different architecture, it can come out very good, average, or very poor, depending on what you're doing with it. However, when you compare the cost vs. performance, they really do start to shine. I, myself, pitted a $13,000 quad-Xeon against a $25,000 dual-Alpha for database work, and the Xeon handily bested the Alpha. Had the work been pure number crunching, though, the results probably would have been backwards.

A lot of the extra money that you spend on "big iron" hardware is spend getting tremendous amounts of I/O to the various CPU's. For something like a database server, where your app pretty much has to run on a single machine, that's great. For something as simple as web-serving, which is extremely easy to cluster, you're wasting your money. Ten $2,000 Intel-based machines will deal out far more than one $20,000 Sun/IBM/Alpha.

In fact, when one company was doing an embedded solution based on the Strong-ARM chips, just for fun, they used ten of them to dish out over a million web pages per *minute* - and that was with StrongARMs.

steve

Just a can (3, Funny)

VFVTHUNTER (66253) | more than 12 years ago | (#2621572)

of Dr. Pepper? I expect to go through a whole case waiting for the slashdot effect to wear off...

New Webserver For 21st Century Goes Down (1)

SloppyElvis (450156) | more than 12 years ago | (#2621583)

I was enjoying the article until it /.'ed, and I couldn't get anymore pages to load.

Therein, a stress test to the folks at Ace's Hardware.

What have we learned? (2, Funny)

Defiler (1693) | more than 12 years ago | (#2621587)

The moral of this story:
If your website is dynamically generated from a database, and your name isn't Amazon.com, don't let Slashdot link to you.
A single $999 box isn't going to stand up to Slashdot, unless every page is static.

Re:What have we learned? (1)

indigo78 (464058) | more than 12 years ago | (#2621693)

My (around) $999 box at University has been slashdotted (on FTP, not on HTTP) and it hasn't been able to stand for more than 3 hours. The effect passed in a couple of days. The network administrator just went to my desk asking why it had served around 20Gb of data in less than 24 hours... Maybe linking your site to Slashdot is a good crash-test benchmark...

building a web server??? (2, Troll)

Mudhiker (15850) | more than 12 years ago | (#2621604)

I'd call this buying a web server rather than building one...

A can of Dr. Pepper (0)

Anonymous Coward | more than 12 years ago | (#2621605)

Sounds like blatant advertising to me!

Dr. Pepper [drpepper.com] 's website. Check it out, yOU!

While you're at it, why not purchase a Dell [dell.com] computer?

Slashdotted (1)

ptrourke (529610) | more than 12 years ago | (#2621606)

/.ed Well, so much for THAT idea . . .

Dr. Pepper (0)

CrazyDwarf (529428) | more than 12 years ago | (#2621608)

I devoted a can of Dr. Pepper to this article... had to replace my keyboard. I guess that wasn't a good idea, huh?

argh, server performance vs BANDWIDTH (4, Insightful)

green pizza (159161) | more than 12 years ago | (#2621623)

Is it just me, or do most folks confuse these two. If a popular website only has a 9 Mbps pipe to the Internet, it doesn't matter how many Crays they have running their webserver farm, they're only going to be able to churn out 9 Mbps (minus overhead). Granted that the converse is possible... gobs of bandwidth, but a slow server... but I would imagine that bandwidth is the limiting factor of at least 99% of websites.

Compression for dialup connections??? (4, Informative)

Lumpish Scholar (17107) | more than 12 years ago | (#2621637)

Consider a user with a typical analog modem that has an average maximum downstream throughput of, say, 5 KB/s. If this user is trying to download the general message board index page, about 200 KB in size (rather small by today's standards), it will require a solid 40 seconds to complete this single download.... To maximize the efficiency of the network itself, we can compress the output stream and thus, compress the site. HTML is often very repetitive, so it's not impossible to reach a very high compression ratio. The 200 KB request mentioned above required 40 seconds of sustained transfer on a 5 KB/s link. If that 200 KB request can be compressed to 15 KB, it will require only 3 seconds of transfer time.

Except that 56 Kbps modems get 5 KBps thoughput by compressing the data! If the client and server compress, the modems won't be able to; the net effect is lots of extra work on the server side, and probably no increased throughput for the modem user.

The server might or might not see a decrease in latency, and in the number of sockets needed simultaneously; it depends on how much it can "stuff" the intermediate "pipes". The server will see an overall decrease in bandwidth needed to serve all the pages.

Ironically, broadband customers (who presumably don't have any compression between their clients and Internet servers) will see pages load faster. (And the poor cable modem providers from the previous story will be happy.)

Re:Compression for dialup connections??? (3, Informative)

Betcour (50623) | more than 12 years ago | (#2621737)

I am affraid you are wrong, the modems get 5 KB/s of raw data, not counting compression. I can download zipped files at over 5 KB/s with a dialup modem...

mod_gzip is your friend.

How disappointing (1)

borud (127730) | more than 12 years ago | (#2621652)

the title lead me to believe that it might be an
article discussing how to design better webserver
software -- something which would have been
very interesting since it has been ages since I
saw a fresh take on that.


instead: another article on piecing together hardware. *sigh*

Re:How disappointing (1)

mummers (253129) | more than 12 years ago | (#2621671)

Sigh, just more Sun drenched propaganda.

What a waste of a good can of sugary gut-rot.

Yep its slashdotted. (0)

Anonymous Coward | more than 12 years ago | (#2621656)

Yep I can't get to the site, its slashdotted. Hmm, I wonder if some people try to get sites posted just to have them taken down. It would be kind of like a poor mans DOS attack.

Why Sun? (3, Insightful)

hughk (248126) | more than 12 years ago | (#2621658)

Having a quick dig through the article at the far from lightning speed that a /.ed site runs at, I am still no absolutely clear why they stuck with SPARC architecture.


SPARCs come from Sun, everybody makes a PC - so guess which is cheaper? We see some reasons why they went for the Blade (a nice machine, but rather more expensive than a couple of PCs).


Please get this right, I'm no x86 fan, but I love the competition going through the line from the processors, chip-sets, mother-boards, etc. This has got to ensure that unless you really want the 2GHz Pentium 4, you have plenty of choice.


As for reliability, I don't know the Blade, but the SPARC 20s used to give some headaches over their internal construction. It always seemed a little complicated with the daughter boards and they seemed to lose contact after machines were moved around.

aha... (0)

Anonymous Coward | more than 12 years ago | (#2621673)

Now I see why Ace's crapped out while I was reading the article --- I witnessed the /. effect live. In fact, I was a victim of it. Boo hiss.

ode to SPARCstation 20 (4, Interesting)

green pizza (159161) | more than 12 years ago | (#2621688)

The SPARCstation 20 was one heck of a great machine back in the day, especially for its size (a low profile pizzabox). The design was a lot like it's older brother (the SPARCstation 10 from 1992)... that is, two MBUS slots (for up to 4 CPUs) and 4 SBUS slots (Sun Expansion cards, 25 MHz x 64 bit = ~ 200 MB/sec each, but 400 MB/sec bus total).

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!

better server :)? (1, Flamebait)

sintetika (467283) | more than 12 years ago | (#2621689)

500 Servlet Exception
java.lang.NullPointerException
at com.caucho.server.http.Application.getAttribute(Ap plication.java:2779)
at AcesHardware.tags.DiscussionTag.doStartTag(Discuss ionTag.java:47)
at _site._sidebar_0articles__jsp._jspService(/site/si debar_articles.jsp:17)
at com.caucho.jsp.JavaPage.service(JavaPage.java:87)
at com.caucho.jsp.JavaPage.subservice(JavaPage.java:8 1)
at com.caucho.jsp.Page.service(Page.java:474)
at com.caucho.server.http.FilterChainPage.doFilter(Fi lterChainPage.java:166)
at com.caucho.server.http.Invocation.service(Invocati on.java:277)
at com.caucho.server.http.CacheInvocation.service(Cac heInvocation.java:129)
at com.caucho.server.http.QRequestDispatcher.include( QRequestDispatcher.java:338)
at com.caucho.server.http.QRequestDispatcher.include( QRequestDispatcher.java:247)
at com.caucho.jsp.QPageContext.include(QPageContext.j ava:467)
at _read__jsp._jspService(_read__jsp.java:84)
at com.caucho.jsp.JavaPage.service(JavaPage.java:87)
at com.caucho.jsp.JavaPage.subservice(JavaPage.java:8 1)
at com.caucho.jsp.Page.service(Page.java:474)
at com.caucho.server.http.FilterChainPage.doFilter(Fi lterChainPage.java:166)
at ToolKit.GZIPFilter.doFilter(GZIPFilter.java:22)
at com.caucho.server.http.FilterChainFilter.doFilter( FilterChainFilter.java:87)
at com.caucho.server.http.Invocation.service(Invocati on.java:277)
at com.caucho.server.http.CacheInvocation.service(Cac heInvocation.java:129)
at com.caucho.server.http.HttpRequest.handleRequest(H ttpRequest.java:216)
at com.caucho.server.http.HttpRequest.handleConnectio n(HttpRequest.java:158)
at com.caucho.server.TcpConnection.run(TcpConnection. java:140)
at java.lang.Thread.run(Thread.java:484)

null pointer exception! (0)

icejai (214906) | more than 12 years ago | (#2621702)

Looks like their article was their server's achille's heel....

very ironic.

Uh oh... (2)

Fesh (112953) | more than 12 years ago | (#2621714)

Ace's Hardware? Why do I see a nasty trademark violation in some poor webmaster's future?

*sigh* Probably because we've seen enough of it in the past...

Dont care about integrated video? (1)

josquint (193951) | more than 12 years ago | (#2621725)

Of course, the integrated video and sound is not very important to us, as the system runs headless mounted in a rack.

Just a thought, but video would be really handy for the install, i'm guessing!

So... anyway, in short it looks like they took a workstation and dropped a shitload of ram into it... big deal

an open letter to Michael (-1)

mark knopfler 69 (535609) | more than 12 years ago | (#2621730)

Hi faggot,

If you suck less cock, your stomach ulcers might go away.

Your friend,
Mark Knopfler
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>