Commanche performance

Hi all,

I have been looking through some of the capabilities of Comanche and I am
very impressed.  Seems like you can do anything in it that could do with
apache, but a much nicer/accessible interface.

So my question is, what is the performance and scaling like.  I know the
common belief is that apache is unbeatable, but using a higher level
language it is possible to accomplish more:  
http://www.sics.se/~joe/apachevsyaws.html

And has anyone tried running it under Exupery?

I know I don't have to tell this group the advantage of using high level
languages, but the accessibility strikes me as a big deal.  We could do
things like fully configure Comanche from a simple Morphic app or even
Seaside.

Thanks,
Jason

_________________________________________________________________
Check out all that glitters with the MSN Entertainment Guide to the Academy
Awards®   http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2

>Hi all,
>
>I have been looking through some of the capabilities of
Comanche and I am
>very impressed.  Seems like you can do anything in it that could
do with
>apache, but a much nicer/accessible interface.
>
>So my question is, what is the performance and scaling like.  I
know the
>common belief is that apache is unbeatable, but using a higher
level
>language it is possible to accomplish more:  

If I remember correctly from an old mail Comanche was around
1/3 of Apache for the number of transactions it can handle.

Ray

Hi!

I did some benchmarking about 2 years ago but never got around to
publishing in a readable form (perhaps I posted about it) but from my
memory I recall:

1. I found some code here and there that I rewrote for speed. Never got
around releasing those changes. It was not fantastic improvements but
definitely worthy.

2. After the tweaks the bottleneck appeared to be header parsing. I bet
that code can also be improved.

3. Dan Shafer has been doing investigations on the lower levels, and if I
am not mistaken the Croqueteers have very recently discussed Socket issues
in the Unix VM (stumbled upon that) causing problems. I haven't myself
looked at this level and IIRC I used "keep alive" when testing which
probably hides a bit of the Socket issues.

4. Performance varies substantially with size of payload. The larger the
payload is the header parsing turns into a smaller issue.

5. Oh yeah, I only tested KomHttpServer itself with "in memory" payloads.
I never bothered with actual file serving which is a can of worms in
itself.

Since most of us have so much "other stuff" to spend our time on I haven't
had the time to revisit KomHttpServer tuning.

I have also felt that some parts of KomHttpServer is needlessly complex
(especially the whole module setup etc) - but I don't think it affects
performance in a negative way.

regards, Göran

Do you have it laying around?  Maybe it would still be applicable.

I hear that.

>I have also felt that some parts of KomHttpServer is needlessly complex
>(especially the whole module setup etc) - but I don't think it affects
>performance in a negative way.

What is wrong with the module stuff?  It looks pretty flexible to me.  It
might be a little bit of work when talking to the objects via doit's, but a
nice web/morph interface could be made for it.  At that point, it could have
all the flexability of apache (maybe more) but in a much *much* friendlier
way.  I have been setting up apache instances the last couple of weeks at
work and those config files are a real bear.

_________________________________________________________________
>From predictions to trailers, check out the MSN Entertainment Guide to the
Academy Awards®
http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1