荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Lg (创造人生的传奇), 信区: Linux
标 题: Linux and NT as Web Server on the Test Bed
发信站: BBS 荔园晨风站 (Tue Jun 29 14:39:15 1999), 站内信件
Linux and NT as Web Server on the Test Bed
Server benchmarks comparing Linux and NT are in. Mostly,
however, they try to make
headlines by breaking records in unrealistic benchmark
scenarios. In c't's test lab, a
comparison between NT/IIS and the freeware duo
Linux/Apache focussed on
practice-oriented tasks.
Linux and Apache are becoming more and more popular.
According to Netcraft, the freeware
duo ranges at the top of the web server platform
popularity scale. However, after the initial
CeBIT Linux hype, some horror news has caused uncertainty
in the freeware community:
Mindcraft [1] published a study claiming that Micosoft NT
with Internet Information Server was
3.7 times faster than free competitors Linux with Apache.
However, it very soon became clear that Microsoft had
financed the report which also trashed
the file server performance of Linux/Samba. In addition,
hardly any Linux, Samba or Apache
optimizing had been done at Mindcraft while Microsoft
technicians struggled to squeeze NT for
maximum performance.
To clarify Mindcraft's results a Siemens Primergy 870 web
server was set up in the c't lab. The
system was equipped with four Pentium II Xeon CPUs (450
MHz), 2 GBytes RAM and two
network boards (Intel EtherPro 100). As is ususal with
setups of this kind - the system costs
about DM 100,000, after all - we also included a RAID
controller (Mylex DAC 960).
Siemens's Primergy 870 works with
S.u.S.E. Linux 6.1 and
Windows NT 4.0. There were no problems
except one harddisk
failure.
(Click on thumbnail for enlarged view)
Here's where it started to show that the aim wouldn't be
to imitate Mindcraft's test setup. In their
test, all of the data was stored on a RAID-0 volume,
which while promising optimum data rates
is also considerably more failure-prone. Unlike other
RAID levels, RAID-0 doesn't store any
redundant information, scrapping the whole volume when a
single disk fails. No responsible
system admin who likes his or her job would run a
production server with a RAID-0 only
configuration.
We decided on a RAID-5 configuration which promises a
good compromise between stability
and performance, and our tests proved us right. After
rebooting, one of the four hard disks
refused to start up but the system carried on regardless:
The RAID controller calculated the
missing information from additional parity bits.
After the disk had resumed its job the following day (the
hickup's cause could not be
established), the controller rebuilt it and everything
was the way it was before. The system
remained operable at all times and we only had to discard
a few sets of test results when the
system was too busy rebuilding the RAID volumes.
Centre Court
Siemens delivered its quadruple Primergy server with NT
4.0, Service Pack 3 and S.u.S.E.
Linux 6.1 already installed. We updated NT with Service
Pack 4 and upgraded Linux to the
latest kernel version 2.2.9. A quick test using the
pre-installed 2.2.5 clearly fell short especially
in SMP mode.
As NT web server we used Internet Information Server 4
from the current Option Pack. Linux
was equipped with a freshly translated Apache 1.3.6. Find
operating system and web server
optimizations in the respective boxes. Both servers
obtained their data from an 8-GByte partition
living on a RAID-5 volume. The log files went into a
separate partition on the same volume.
Unlike for the Mindcraft test, which required the server
to produce its pages through four
100-MBit interfaces we decided on a more realistic
scenario. How many web servers actually
serve four of these network interfaces? The majority of
web servers make do with a 10-MBit
interface and even in intranet one 100-MBit board should
be sufficient. This was the
configuration we chose for our tests. To get an
impression of maximum load behaviour anyway,
we made the server prove it can handle two Fast Ethernet
connections.
As clients we used eight or sixteen 486 and higher PCs
respectively, operating under Linux and
hooked up to the server with a switched 10-MBit
connection. Each of these clients operated up
to 64 instances of a program loop making HTTP GET
requests and accepting, evaluating and
logging the server's response. This test program's source
code can be downloaded from [2]. All
in all, up to 1024 clients made parallel HTTP requests
this way.
Serve
In our first test, the computer had to serve a static
HTML page of 4 or 8 KBytes. This meant
clients all used the same URL for their tests. When
comparing the results using one, two and four
CPUs there was the first disappointment. The additional
CPUs didn't make a difference with
either of the operating systems. The difference was way
below 10%, with Linux frequently even
doing worse than with one CPU. Find the details in the
box 'Optimizing Linux and Apache'.
As shown in the test using two network interfaces, this
result can - at least for NT - not be
traced back to dissatisfactory scaleability but simply to
the test environment being fully utilized,
the network working to its full capacity and the clients
being saturated.
Here, all systems supply one static HTML page
with one CPU. Test with
several processors have similar results. MacOS
X results are provided
for information only.
(Click on thumbnail for enlarged view)
Initially, NT refused a large number of connection
requests from 128 clients upwards. This
behaviour was caused by ListenBackLog being to small.
This is the queue the TCP stack uses
for connection requests while the port is busy with
something else. After having set the relevant
parameter to 200 in the Registry, the refusals
disappeared.
For every request, 4KB files are randomly
selected from a set of 104 or
106 files, respectively.
(Click on thumbnail for enlarged view)
There isn't much of a difference between NT/IIS and
Linux/Apache. When dealing with 4 KB
files, Linux and NT matched each other closely, with
larger 8 KB files Linux was slightly ahead.
Our next test was aimed at HTTP requests not for one
single file but for one of a whole set of
files. For this, the clients picked pages from a file
tree with 10,000 4-KB HTML files. At an
overall size of 40 MBytes, these should easily fit into
buffer cache, leaving file I/O out of it for
the moment.
Only at the beginning did the system need to read the
files from disk, which explains the low
results at the beginning of the graph. However, even the
first value already corresponds to about
70,000 HTML pages served, enabling the server to deal
with requests directly from main
memory when dealing with 16 clients at the latest.
As was to be expected, basic behaviour only changed
marginally compared to dealing with only
one page. The only thing we noticed was that Linux's
performance was about 15 percent higher.
Baseline Duel
In a second variation, the overall size of one million
files was about twice as large as the 2 GB of
main memory. The total number of requests in test runs
for which a reboot had previously
cleared the buffer cache was clearly below 500,000. Files
would generally have to be loaded
from hard disk before being sent through the net.
In this setup, the freeware system clearly shows better
results: While NT can hardly manage
more than 30 requests per second, Linux can handle more
than 166. With 512 client processes,
it even manages 274 pages per second. Since more than 400,
000 pages are retrieved during this
test, however, we cannot be entirely sure that the
increase especially towards the end of the
graph isn't down to a caching effect. But who would
complain about an overly efficient buffer
cache?
When calling CGI scripts, Windows NT is no
match for Linux. As
the load is not confined to kernel mode in
this case, Linux can
benefit from additional CPUs. The graph at
the bottom nicely depicts
the linear increase for a CGI script with
integrated delay.
(Click on thumbnail for enlarged view)
As file I/O plays a major role here, the reason for these
performance differences between Linux
and NT might be found in their different file systems.
Possibly Linux's ext2 file system saved
small 4K files more efficiently on an 8GByte partition
than NT's NTFS file system. However,
this assumption is weakened by the fact that Linux will
increase considerably again with special
SMP patches involving several CPUs (see box on page 189).
Dynamic Play
After having dealt with static pages, both systems also
needed to prove their ability to handle
dynamic contents. The smallest common denominator for
tasks of this kind is the Common
Gateway Interface (CGI). Clients request pages which a
Perl script generates dynamically and
then delivers via CGI. For this purpose, we installed
ActivePerl Build 517 [3], which is based on
Perl 5.005_03 and didn't cause any installation or
operational problems.
Of course, this configuration is not first choice for
generating dynamic HTML pages on a
Windows system. An NT administrator would normally prefer
Active Server Pages (ASP) and
VBScript, which is why these results should rather be
read like a CGI or Perl usability test for
NT than a proper system comparison. Since Microsoft's
solution isn't portable to other systems
we unfortunately couldn't make the reverse comparison.
And the figures for CGI and ASP aren't
really comparable due to their entirely different
underlying concepts.
When providing a 4KB file via two parallel Fast
Ethernet boards, NT
clearly leaves Linux behind. Here, both systems
benefit from additional
CPUs.
(Click on thumbnail for enlarged view)
During the CGI tests, our NT server suffered massive
performance losses. Although both NT
and Linux serve more than twice as many dynamic pages
with four CPUs as they do with one,
NT in SMP mode is still just under half as fast as Linux
with only one CPU. However, Linux
needed quite a bit of fine tuning for dealing with high
loads before it worked properly. With 256
and more client processes, NT provided more errors than
correct responses. We could not
obtain any helpful hints from Microsoft about this
behaviour.
For simulating very slow client connections or
time-intensive database queries, we added - like
we did when testing the Heise server [4] - a special
script variation. In this version, calling
sleep(3) causes a response delay of three seconds.
This will, of course, first of all decrease the number of
request responses per second. However,
when several clients call the script simultaneously,
there should always be enough processes
available to keep the system busy. The number of request
responses per second should be
approximated to the full speed version. Although these
dormant processes block some memory
- file handles, server processes etc - and put a lot of
strain on the system, they don't use up any
CPU time for themselves. On the sun which is now Heise
web server this works beautifully.
KTop for Linux (top) and NT's Task
Manager (bottom) show
that the load is distributed across all
system CPUs.
(Click on thumbnail for enlarged view)
Linux's behaviour is similar. Up to 256 processes,
request responses per second increase neatly
in line with the number of clients. There, they nearly
reach the full speed version but don't
increase any more after that. Also, Linux couldn't
benefit from additional CPUs.
NT can't do more than seven pages per second. This is
probably where IIS design comes into
play, which unlike Apache works with threads. Normally,
web servers with internal threads are
meant to work more efficiently due to the reduced system
overhead. However, once all threads
are blocked, the server cannot process any further
requests. It might have been possible to
change this behaviour by massively increasing the number
of worker threads. But Microsoft
explicitly recommends not to increase this number to more
than 20 per CPU. This value didn't
significantly change the default settings' results. The
Apache server, on the other hand, for the
first time in this test reached our given limit of 512
processes.
The Double
Things started going NT's way, however, when 16 computers
had to be served via two network
boards. Although both Linux and NT clearly benefitted
from more CPU performance through
SMP, Linux didn't even in SMP mode reach NT's results
with only one CPU.
Internet Information Server blasted the pages through the
net at a speed which gave rise to the
assumption that it could also feed four and more network
boards if need be. This was backed
up by the fact that results with two CPUs were nearly
identical to those reached with four
CPUs.
To those who really need a web server providing static
HTML pages from memory at a speed
which requires several Fast Ethernet interfaces, you've
found your system here.
Conclusion
First of all, we must say that additional CPUs for plain
web server operation with static HTML
pages are a waste. Even with two Fast Ethernet lines
there's only a moderate less than twenty
percent increase. It seems that CPU performance is not
the decisive factor with these tasks. The
graphs indicate that the Primergy server itself didn't
have to work to its full capacity at all.
Linux's comparatively bad results when tested with two
network boards show that Mindcraft's
results are quite realistic. NT and IIS are clearly
superior to their free competitors if you stick to
their rules.
To clarify it once again: These results correspond to a
load beyond 1000 requests per second.
In comparison: At peak times, the Heise server deals with
about 100 requests/s. Also, we are
talking about purely static pages which on top of that
are already present in the system's main
memory. Our tests showed that Mindcraft's result can't be
transferred to situations with mainly
dynamic contents - the common case in nearly every
sophisticated web site.
In SMP mode, Linux still exhibited clear weaknesses.
Kernel developers, too, admit freely that
scaleability problems still exist in SMP mode if the
major part of the load comes through in
kernel mode. However, if user mode tasks are involved as
well, as is the case with CGI scripts,
Linux can benefit from additional processors, too. These
SMP problems are currently the target
of massive developing efforts.
In the web server areas most relevant for practical use,
Linux and Apache are already ahead by
at least one nose. If the pages don't come directly from
the system's main memory, the situation
is even reverted to favour Linux and Apache: Here, the
OpenSource movement's prime
products leave their commercial competitors from Redmond
way behind.
Relevant for practical use is Mindcraft's critical
assessment of Linux and Apache tuning tips
being difficult to come by. True enough, professional
Linux support structures are still in
development. However, Apache and Linux developers have
been extremely helpful. While
Microsoft needed more than a week to come up with the
ListenBackLog hint, our questions
regarding Linux and Apache problems were answered with
helpful hints and tips within hours.
Emails to the respective mailing lists even resulted in
special kernel patches which significantly
increased performance. We have, on the other hand, never
heard of an NT support contract
supplying NT kernels specially designed for customer
problems. (ju)
Bibliography
[1] Mindcraft study:
http://www.mindcraft.com/whitepapers/nts4rhlinux.html
[2] Download Benchmark program:
ftp://ftp.heise.de/pub/ct/ctsi/gww-10.tgz
[3] Perl for Win32: http://www.activestate.com/ActivePerl/
[4] Stets zu Diensten, Die Technik hinter www.heise.de, J?
gen Schmidt, c't 6/99, S. 272
[5] CGI-MacPanic:
http://www.heise.de/ct/99/13/186/CGI-MacPanic, see also CGI Causes MacOS X
Server
To Panic
[6] Information on Microsoft's Web Server,
http://www.microsoft.com/backstage/whitepaper.htm
[7] IIS 4.0: Tuning Parameters for High-Volume Sites,
http://msdn.microsoft.com/library/backgrnd/html/msdn_tuning.htm
[8] Linux SMP-Patches:
ftp://ftp.suse.com/pub/people/andrea/kernel/2.2.9_andrea2.bz2
[9] Apache Tuning:
http://www.apache.org/docs/misc/perf-tuning.html
Optimizing Linux and Apache
Initially, Linus Torvalds developed Linux on a 386, and
even now only very few developer can
access truly high end hardware. Therefore, one of the
free operating system's strengths lies in
getting the most out of a rather limited system. Using
Linux on large servers is a relatively new
trend. It, therefore, comes as no surprise that a fair
amount of manual adjustment is required for
a system like Primergy 870 if the aim is to push the
hardware to its limits. However, the
requirements are there.
A typical example is extending main memory: If you
install more than 1GByte of RAM, you must
adapt the PAGE_OFFSET constant in include/asm/page.h and
arch/ i386/vmlinux.lds and then
retranslate the kernel before you can use it with Linux
(all paths are related to the kernel sources
in /usr/src/linux/). The relevant values can be found in
the source texts.
When used as a web server in SMP mode, Linux
generally provides
worse results than with one CPU. However,
patches made a
considerable difference. The graphs were
generated in test runs with
104 and 106 HTML files, respectively.
(Click on thumbnail for enlarged view)
Similar things apply for the number of processes Apache
can start. With other Unix systems, all
you have to do is increase the 'HARD_SERVER_LIMIT256'
constant in httpd.h. With Linux,
this exceeds the maximum number of processes per user and
causes the error message 'can't
fork'. Increasing NR_TASKS in task.h will get rid of this
problem, too.
Many CGI scripts produced the error message of no file
descriptors being available. Their
number is determined by NR_OPEN in include/linux/limits.h,
fs.h and posix_types.h. Only after
all values had been modified did the CGI test run without
problems.
Also, Linux SMP support is still in development. When
asked in the kernel mailing list,
developers freely admitted that there's still a lot to be
done here. For example there's still a
global kernel lock set by many kernel operations which
blocks any other processes also
requiring kernel services.
The developer Arcangeli provided us with special patches
[8] for modifying scheduler and
memory management. In addition, they release the global
kernel lock whenever possible. As
shown in the graph above, these patches in some cases
brought about remarkable
improvements. Although the patches worked smoothly with
our system one must not forget that
they are a mere test project which even runs outside the
developer's kernel. Therefore, they
should not be used with production servers.
Useful hints for optimizing Apache can be found at [9].
For high load operation, the server
should be re-translated leaving out unrequired modules.
It also pays to experiment with the
settings for the number of processes, StartServer,
MinSpareServer, MaxSpareServer, and
MaxClients. The settings of 16, 16, 64, 512 we chose for
our test setup can't be transferred to
different requirements.
Optimizing NT and IIS
Only a few optimizations were necessary for NT to produce
good results. For one thing,
'Maximise throughput for network applications' in server
service properties in system
settings/network/services should be enabled. It is
recommendable at least for benchmarking to
switch off performance boost for foreground applications.
With NT, the network board's parameters
can be adjusted via a
graphic interface.
(Click on thumbnail for enlarged view)
For IIS, the first thing is: disable any features that
aren't needed, like additional ISAPI filters. We
also set the number of connections permitted to '
unlimited' in the IIS management console and
chose the maximum values for each of the performance
settings.
Still, IIS initially rejected the majority of connection
requests when subjected to high loads. The
solution to this problem can be found in [6], where
Microsoft server administrators describe
their server configuration. A real treasure chest for
every web master. In our case, a value of
200 (08C hexadecimal) for ListenBackLog got rid of this
error. We also found useful
information in 'Tuning parameters for high volume sites'
at [7].
We couldn't get any useful tips from Microsoft regarding
CGI script errors and bad
performance. The tips taken from [6] and [7] didn't make
a difference, either.
IIS Management Console is Internet Information
Server's central
switchboard.
(Click on thumbnail for enlarged view)
In theory, throughput can also be optimized using various
network board driver parameters.
Although I couldn't achieve any significant improvements
let's quickly take a look at this
procedure since it characterizes the handling differences
between NT and Linux servers very
well.
For NT, Intel offers a graphic tool which can be used to
conveniently adjust all parameters.
However, the system must be re-booted after every
alteration. And it takes eternities until such a
server has checked its entire memory, found all its
volumes and processed all BIOS routines.
With Linux, on the other hand, you are virtually on your
own. After some detective work, I
found the possible settings in the drivers source text
(drivers/net/eepro100.c) and translated the
driver as a bootable module. This took about half an hour
altogether. Then it was possible to
load this driver with certain parameters, make a quick
test run and remove the driver again -
everything without re-booting the system even once. That
half hour was quickly made up for.
MacOS X (re)served
With MacOS X, Apple is targeting the server market. The
Unix-based operating system with
integrated Apache is especially intended for performance
web server use. We were curious and
put our test setup against a server of this kind. However,
the results can only convey a first
impression since we optimized neither MacOS X nor the
integrated Apache for this task. The
entire system ran with its default settings.
In addition, although the G3 Mac with its PowerPC 750e
(400 MHz) we used does compare to
a Pentium II Xeon (450 MHz), its memory of 128 MBytes RAM
is rather on the small side.
This alone is enough reason to run this server 'out of
competition' here.
Installing the server is the simplest task: Insert MacOS
X Server 'Core OS', boot from CD,
doubleclick on installer. This causes the computer to
re-start, boot MacOS X Server and load
an assistant to help you select the required components.
Apache is selected by default. Ten or
fifteen minutes later you enter IP address and name -
ready.
Despite the handicaps we mentioned earlier, MacOS X
Server produced remarkable results
which were only marginally below the Linux and NT
results. Some manual adjustment should
produce at least comparable results. The d
--
☆ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: bbs@202.96.163.195]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店