[Nope]

Originally Posted by xing

Nope, for the record, the the post above was posted before I saw your reply. =)

I do have to say I should've read the complete thread more fully as mistwang did have mention about the pros and cons of poll vs epoll and how it applied in concurrency rates. So you are right in that he was hinting that poll could be faster than epoll depending on concurrency rate.

Though I would still liked it having epoll enabled simply because it would put everyone on the same event dispatcher, even if it's at LiteSpeed's disadvantage, as it would be to no-one's advantage at using the same event api, when the product supports it.

Well, I admit not reading the complete manuals/guides for all the servers I tested. I did usually look into comments on the pages/forums though. I did also disable all that came to mind which could hinder performance as especially hssTVS didn't support them and I wouldn't give it an unfair advantage. Honestely, I did the benchmarks mostly for my own benefit, wanting to know where my code was compared to others.

Originally Posted by xing

Now I know who to contact for hssTVS setup, you will definitely hear from us when it comes to the next round of benchmarking.

Next time I'll ask you too.

Originally Posted by xing

As for conditional GETs and HEAD, I would say conditional GETs are much more important than HEAD and it would be a good benchmark metric.

Well, a lot search engine crawlers still use HEAD as do a couple of http/1.0 Proxies out there. But you are right, use of HEAD is definetely decreasing. What I like about HEAD additionally is the fact that it shows the raw speed of the internal parsing without the network/disk/ram speed being much of an issue. Of course a 304 is almost as lean, just adding the date parser to the results.