Re: [TCLUG:12613] Reasons not to use Apache?

["Eric M. Hopper" <hopper@omnifarious.mn.org>]

On Thu, Jan 20, 2000 at 03:26:19PM -0600, Dave Sherohman wrote:
> 
>> 	If my StreamModule system were more mature, and the Common Data
>> Language (preprocessor?  compiler?) were written, I'd recommend my
>> StreamModule system.  As it is, I recommend (as much as I dislike it)
>> CORBA.
> 
> That's still a good deal heavier than I think is necessary.  While the
> server may end up being heavily-OOP on the inside, I'm looking at a
> simple telnet- based protocol along the lines of SMTP or NNTP.  The
> basic flow is to just identify the thing you want to work with, then
> issue commands against it (with the option of embedding the navigation
> within a command).

	*nod* I've always had this bias against text based protocols for
lots of different reasons.  :-) I've always thought that one of the more
interesting things to do with SMTP would be to introduce a binary mode
in which all the request and response codes and things were encoded in 2
bytes or so.  :-)

	Also, text based protocols tend not to be designed with
asynchronicity in mind.  They tend to make the client wait until the
server responds before the client can say something else, and they also
tend to have the server do lots of work for one client before paying
attention to another.  Will you be talking to lots of clients from a
server, or just one or two?

>> 	If you had a surefire way to do session tracking over HTTP, it
>> would be a different matter, but you really don't.  Cookies don't
>> really solve the problem.
> 
> Even then, there's all the extra wrapping and unwrapping of
> transmissions for HTTP that seems unneccesary to me.  It seems a lot
> simpler to just send a string and get a string back.  (Although I
> suppose there's probably a library out there that allows you to do
> this under HTTP and takes care of all the extra steps behind the
> scenes.)

	*nod* I'm all for eliminating extra wrapping.

>> 	Minimizing server processes is pointless under UNIX.
> 
> Any particular reason?

	The per-process overhead isn't very large.  A little extra
memory perhaps, but not much.  After all, libc is shared.  Most UNIX
programs spend their life waiting for IO, so extra processes don't
generally cause a burden on the CPU.

	Lets itemize the costs of a UNIX process:

- An entry in the process table, woohoo!
- A little extra memory, but not much because of library sharing
- Possible extra CPU load and more context switches if it uses a fair
  amount of and the CPU is really busy
- Extra context switches if this process communicates synchronously with
  other processes.

	None of these costs are particularily high.  The ones that have
the greatest potential for causing problems are 1 and 4.  If both
processes are large, and contain a lot of the same code, and that code
isn't in a shared library, or if they mirror the same large data
structure, then 1 can be a problem.  4 can be a big problem only if the
process communicates heavily with other processes on the same system
using a synchronous protocol.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

PGP signature