Re: [And-httpd-devel] and-server HTTP 1.1 features

[James A. <ja...@an...>]

 Sorry, I've got a lot of spam from @gmain.com ... so unless I've
emailed you before @gmail.com addresses tend not to get looked at for
a while, which is what happened to you.


"Adam Zell" <zel...@gm...> writes:

> Hello,
>
> I had a quick look at And-HTTPD, and am curious if the following features
> are supported:
>
> * HTTP/1.1 pipelining (reduce TCP cold start)

 Yes, Vstr makes this much less work.

> * HTTP/1.1 chunking (useful for Comet and streaming applications)

 No, and while I can see some usage for a streaming application I'm
not 100% convinced that constant streaming is a good thing to use HTTP
for. Saying that, I'd probably allow it as an optional feature after
I've done dynamic content generation support.

> * FastCGI, SCGI, LSAPI, etc. (external application support)

 Not at the moment, this is probably the next big thing that's
needed. I mostly have a design, but haven't got around to implementing
it. Also I think that most people want less FastCGI etc. and more
controlled HTTP proxying type behaviour.
 It doesn't help that I don't have anything that needs dynamic content
generation right now (at least anything that can't be done using the
and-ssi, scons, etc. tools).

> Have you done any comparisons or benchmarks to Cherokee/Lighttpd/LiteSpeed?

 I've done some personal benchmarks, they were mostly against itself
(Ie. strace etc.) although I've done a few against thttpd and some
against gatling. While I read the lighttpd mailing list, I'm reticent
to do comparisons against even that due to unfamiliarity (and even if
it won, it has a horrible design).
 Also there's a big problem of lack of usable benchmarking software,
and a lot of people have fall back on using "ab" even though it's a
horribly inefficient program.
 One thing I've thought about doing is a http-client type API, which I
could use to write a decent benchmark client, http-fuzz program and
dynamic content stuff. But there's a lot of things I'd like to do, and
I don't have time for all of them :)

 A lot of the speed comes from:

1) Pipelining (thttpd is probably one of the few that doesn't have
that though).
2) TCP_DEFER_ACCPET (if you have a lot of dead connections, which some
benchmarks tend to do, you do no work at all).
3) TCP_CORK for certain workloads (although I think the latest
lighttpd beta has that too).
4) epoll/sendfile (although most decent webservers have had both of
those for a while now too).
5) Memory scalability due to Vstr, although this is mostly unconfirmed
by data ... it should be true, and is the hardest for anything else to
copy :).

 (the same might well be true of TCP_CONGESTION, as noone else has
that yet ... AFAIK).

> If you don't have any objection and plan to keep the code active, I would be
> interested in extending the server (note: I have previously contributed to
> thttpd and Lighttpd).

 That would be great, I'm happy to look at all contributions and help
you in anyway with the code. I have a "TODO list"[2] which will in
theory tell you what I'm thinking about trying to write for and-httpd
next (treat it as higher == more likely, but mostly from the ex_httpd
section :).
 Probably the biggest difference to other webservers will be the
almost total usage of Vstr[1], for string/buffer operations. But
hopefully that will actually help, due to the documentation for
same.


 Do you know about the mailing lists at:

http://sourceforge.net/mail/?group_id=162195

...feel free to post any questions/patches/etc. there.


[1] http://www.and.org/vstr/

[2] http://www.and.org/and-httpd/TODO

-- 
James Antill -- ja...@an...
http://www.and.org/and-httpd