At 10:41 PM 4/29/02 +0200, Paulo Gaspar wrote:

>OTOH we are not talking about a new kid on the block. We are
>talking about the Apache (the web server) people, which are VERY
>performance sensitive and are doing multiplatform server code for
>many years already.
>
>Considering this, you may even be right but I would value much
>more your opinion after you actually looked at the library.
>
>Besides, the case you mention is an extreme one. Even if one
>might have to go native on some such cases, the APR covers and
>simplifies much, much more.
>
>

First, although I haven't used Apache 2.0, I have fairly
extensive experience with Apache 1.3. I was not impressed.
The interfaces are very ad-hoc, non-orthogonal, and generally
sloppy. There is, for example, no call to a module to say
"we're done with page -- clean up". Instead, their memory
management routines automatically release stuff at what they
consider the right time. This makes use of C++ highly
problematic as destructors are never called. Secondly,
because they weren't able to solve the problem of memory
leaks, they arbitrarily kill and restart servers. Trying
to put session management code in Apache is utterly impossible.

A quick spot check of the APR on a topic near and dear to
Firebird -- large file handling -- shows an example of
shallow architectural thinking. Most folks of the list
are aware that modern disks exceed 2GB, hence a 64 bit
seek offset is required. Microsoft simply declared a
new 64 bit seek call. The GLIB guys opted for a moronic,
schizoid compromise between standards adherence and
semantic incompatibility and decided a single seek
call would be either 32 bits or 64 bits depending on the
phase on the moon. Here was a great opportunity for
the Apache guys to set everything right and declare that
they have joined the 1990s, big disks are here, and
declare that a seek is a simple 64 operation. What did
they do? They made seek sometimes a 32 bit operation
and sometimes a 64 bit operation depending on conditionals
I couldn't decypher. They could have should have simply
declare seek a 64 bit operation and be done with it
forever. The decision was stupid, short sighted, and
wrong.

My performance measurement using identical machines and identical
loads shows NT 4.0/IIS as 30% faster than Linux/Apache 1.3.
The difference, I think, is architectural: Apache uses forks
many independent client processes while IIS is a single
multi-threaded process. This is not to say that I wouldn't
pick Apache over IIS any day of the week despite the performance
deficit, but it doesn't speak very well of the architectural
prowess of the Apache group.

Having written more multi-platform database systems than the
average bear, I will re-iterate my opinion that interposing
somebody else's code between the database system and the
operating system is always a mistake.



Jim Starkey