[ale] Compaq Reliant web server

Jeff Hubbs Jhubbs at niit.com
Thu Jul 12 10:43:35 EDT 2001



John 
-
<SPAN 
class=538232713-12072001> 
The 
strongly-held opinion I have formed over the years is that no multi-processor 
box should be bought without all CPU sockets fully populated.  You're 
paying extra (especially if you go with "name" vendors like Compaq) just to have 
even a 2-CPU system, but every day that it goes with one or more CPU slots empty 
represents lost value, i.e., you are not getting any returned "power" for the 
money you spent.  The "you can always add CPUs later" argument is always 
trotted out but in practice, that's often not possible without also replacing 
the original CPU(s) simply because duplicates are no longer available.  
Even at that, I've encountered people whose newly-SMPed machine never worked 
quite right again until two CPUs of the same speed, stepping, and 
revision were used.  The oringinal CPU(s) displaced then go on to represent 
unreturned value unless and until more money is spent to put a machine around 
them.  
<SPAN 
class=538232713-12072001> 
What 
Joe Knapka said about the 32MB P/133 isn't a joke.  For 2000 hits/day = 
43.2 seconds/hit, a 486DX would do unless it's too slow for you to do admin-type 
things like tar/zip a bunch of files.  It surprises me about how 
miscalibrated people can be about how much machine it takes to do a given 
thing.  A few months ago, I was testing out a Web server configuration 
using Rational SiteLoad, and for the heck of it I aimed it at a P/200 running 
Zope, with a user script that just pulled out a lot of static content (no 
DB).  The 512MB PIII/667 that I was running SIteLoad on started to get in 
to the weeds (and therefore into the range of invalidating the test) at about 40 
simultaneous simulated users, but the target Zope box seemed like it was only 
just starting to feel it - and that's without recompiling the kernel, the 
modules, and python for 586.
<SPAN 
class=538232713-12072001> 
This 
is why I value "junk" machines so much; they give the Linux/*BSD person great 
power.
<SPAN 
class=538232713-12072001> 
I 
would say that if they are going to even remotely consider a "dualie," they 
ought to use it as a killer file or DB server.  I'm starting to realize 
that a fast file server on a good network is one of the coolest things an 
organization can have.
<SPAN 
class=538232713-12072001> 
- 
Jeff
<SPAN 
class=538232713-12072001> 
<SPAN 
class=538232713-12072001> 
<SPAN 
class=538232713-12072001> 
<FONT face=Arial 
color=#0000ff>  -----Original 
Message-----From: Armsby John-G16665 
[mailto:John.Armsby at motorola.com]Sent: Wednesday, July 11, 2001 5:17 
PMTo: 'ale at ale.org'Subject: [ale] Compaq Reliant web 
server

  The IT group here is junking an HP box with my web 
  stuff.  I told them I did not want to port to NT, that I preferred to 
  stay with Unix.  I suggested Linux as an alternative on an Intel 
  box.  They accept the idea.  Hooray!  
  They are suggesting a Compact Reliant series server 
  which comes with a RED HAT CD.  They want to know if I need dual 
  processors.  Frankly the box is only getting about 2,000 hits in a 24 
  hour period.  The current HP 9000 workstation has 256 meg of ram and a 
  single 200 megahertz processor.  TOP is usually less than .1 except when 
  I try to tar several thousand files over several days and then it jumps to 
  1.03 or so.  There is no discernable on the WEB server.
  My question is: Am I correct in assuming that an 
  out of the box installation of Mandrake 8.0/Red Hat 7.0 or equivalent will not 
  by default see two processors?  Don't I have to do a kernel recompile and 
  select multi processor?  
  John 



___________________NOTICE____________________________ 


This electronic mail transmission contains confidential information intended only for the person(s) named.  Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you received this transmission in error, please notify the sender by reply e-mail and then destroy the message.  Opinions, conclusions, and other information in this message that do not relate to the official business of NIIT shall be understood to be neither given nor endorsed by NIIT. When addressed to NIIT clients, any information contained in this e-mail is subject to the terms and conditions in the governing client contract.




More information about the Ale mailing list