Overview
Features
Download
Documentation
Community
Add-Ons & Services

HTTPServer performance

Please post support and help requests here.

Re: HTTPServer performance

Postby alex » 20 May 2009, 03:59

aderouineau wrote:So the Async stuff posted in the blog is a false async, by using threads?

Yes.
aderouineau wrote:Would the Reactor allow the handling of many concurrent (small-burst) connections for a torrent tracker?

Yes. If you depend on select (portable), then you're stuck with static limit of sockets you can have opened (usually 1024). The poll() has no such limit, but not all platforms have it (e.g. windows lacks it). But it is only available in the trunk code (although it is simple to backport to a 1.3.x release).
alex
 
Posts: 1158
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: HTTPServer performance

Postby aderouineau » 20 May 2009, 10:57

But the value of the limit can be changed at compile time, if I'm correct; and although I plan on making it multi-platform, I'll advise not to use it on windows (after all, who wants to trust windows for highly scalable apps :p).
I don't know if it would be wise to change that limit though... What do you think?

Is EPOLL used for polling? If I remember correctly, there's a project (not a framework) that can use two different polling libraries.

Since polling is only available in trunk, I guess I can just use Reactor with normal select during development, and hopefully polling will be in stable when I'll be done with the app (probably some time around september). Will polling be in stable then?

I'm also wondering about the real performance difference between poll and select...

Thanks again for the help!
aderouineau
 
Posts: 163
Joined: 18 May 2009, 17:38

Re: HTTPServer performance

Postby alex » 20 May 2009, 13:02

aderouineau wrote:But the value of the limit can be changed at compile time, if I'm correct; and although I plan on making it multi-platform, I'll advise not to use it on windows (after all, who wants to trust windows for highly scalable apps :p).
I don't know if it would be wise to change that limit though... What do you think?

I don't think that is a problem, although according to C10K page some std libraries have it compiled in:
C10K wrote:Unfortunately, select() is limited to FD_SETSIZE handles. This limit is compiled in to the standard library and user programs. (Some versions of the C library let you raise this limit at user app compile time.)

aderouineau wrote:Is EPOLL used for polling? If I remember correctly, there's a project (not a framework) that can use two different polling libraries.

No - poll(2) is used. C10K page is the best source on async IO I know of.
aderouineau wrote:Since polling is only available in trunk, I guess I can just use Reactor with normal select during development, and hopefully polling will be in stable when I'll be done with the app (probably some time around september). Will polling be in stable then?

I would love it to be, but I can not promise. Few months ago, someone offered to sponsor async IO development, but that was a solitary offer and there was not much interest from other parties to contribute. We love to code, but life has its demands, so without something like that, it is hard to make firm promises.
aderouineau wrote:I'm also wondering about the real performance difference between poll and select...

See C10K page for answer to that.
alex
 
Posts: 1158
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: HTTPServer performance

Postby aderouineau » 20 May 2009, 13:12

I was actually reading C10K before coming back here :p

EPOLL and kPoll really seem to perform better than poll/select.
Would it be easy to include their use in Reactor, and chose the best available one at library compile time?

EDIT: I'm still wondering if a pool of a few dozen threads wouldn't be enough, because the clients would basically connect, send a small request, get a fairly small reply, and disconnect; so the "bursts" are rather short. How would a true asynchronous mechanism work better than a pool of threads for connections that don't idle?
aderouineau
 
Posts: 163
Joined: 18 May 2009, 17:38

Re: HTTPServer performance

Postby alex » 20 May 2009, 15:24

aderouineau wrote:EPOLL and kPoll really seem to perform better than poll/select.
Would it be easy to include their use in Reactor, and chose the best available one at library compile time?

If you mean epoll and kqueue() in edge-triggered notification mode, they do not fit into the reactor pattern. Reactor is based on level-triggered notification mechanism. kqueue() could be used in level-triggered mode, but that's Free/NetBSD only AFAIK.
aderouineau wrote:EDIT: I'm still wondering if a pool of a few dozen threads wouldn't be enough, because the clients would basically connect, send a small request, get a fairly small reply, and disconnect; so the "bursts" are rather short. How would a true asynchronous mechanism work better than a pool of threads for connections that don't idle?

There is no universally valid answer to this question. It depends on your hardware configuration. If you have enough cores to accomodate (i.e. avoid context switching) the threads and enough memory for the stacks, you may be better off with threads. Otherwise, async IO may work better. Threads with a reactor in each could be a compromise solution. You'll have to study the available mechanisms and decide which one maps best to your requirements.
alex
 
Posts: 1158
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: HTTPServer performance

Postby aderouineau » 20 May 2009, 21:04

alex wrote:
aderouineau wrote:EPOLL and kPoll really seem to perform better than poll/select.
Would it be easy to include their use in Reactor, and chose the best available one at library compile time?

If you mean epoll and kqueue() in edge-triggered notification mode, they do not fit into the reactor pattern. Reactor is based on level-triggered notification mechanism. kqueue() could be used in level-triggered mode, but that's Free/NetBSD only AFAIK.


Yes, sorry; that's what I had meant.
What you say seems strange though, because projects I've seen that have the ability to use epoll also provided backward compatibility with regular poll; yet you'd still use the same functions. Here's an example: ioxx

alex wrote:
aderouineau wrote:EDIT: I'm still wondering if a pool of a few dozen threads wouldn't be enough, because the clients would basically connect, send a small request, get a fairly small reply, and disconnect; so the "bursts" are rather short. How would a true asynchronous mechanism work better than a pool of threads for connections that don't idle?

There is no universally valid answer to this question. It depends on your hardware configuration. If you have enough cores to accomodate (i.e. avoid context switching) the threads and enough memory for the stacks, you may be better off with threads. Otherwise, async IO may work better. Threads with a reactor in each could be a compromise solution. You'll have to study the available mechanisms and decide which one maps best to your requirements.


I guess I can start with Proactor and see if that'll be enough or not. It's too bad that I have to reimplement the handling of HTTP, though. Good thing only GET is used for requests and text sent as response :p

Again, thanks a lot for your help! Good thing to know there's always at least someone, even if the activity is scarce.
aderouineau
 
Posts: 163
Joined: 18 May 2009, 17:38

Re: HTTPServer performance

Postby guenter » 21 May 2009, 06:32

If you only have GET requests and short text responses, what you can do is write everything you read from the network in your reactor code into a std::stringstream, and then use Poco::Net::HTTPRequest::read() to parse the HTTP request from that stream. You can do something similar with the response - create a Poco::Net::HTTPResponse object and write it to a std::stringstream. For writing the response in a reactor-based server, you will need some form of buffering anyway, as you never know in advance how much data you can write at once.
guenter
 
Posts: 1165
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: HTTPServer performance

Postby aderouineau » 21 May 2009, 13:06

Ahh hadn't seen that function! That'll help a lot!

At the same time I was wondering if I shouldn't just redo the parsing of the protocol. Since there's almost nothing, using full-blown Request and Response classes might be overkill and would introduce unnecessary overhead... What do you suggest?
aderouineau
 
Posts: 163
Joined: 18 May 2009, 17:38

Re: HTTPServer performance

Postby alex » 21 May 2009, 19:58

aderouineau wrote:What you say seems strange though, because projects I've seen that have the ability to use epoll also provided backward compatibility with regular poll; yet you'd still use the same functions. Here's an example: ioxx

I did not say they can not be put behind a common interface.
alex wrote:If you mean epoll and kqueue() in edge-triggered notification mode, they do not fit into the reactor pattern.
alex
 
Posts: 1158
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: HTTPServer performance

Postby aderouineau » 21 May 2009, 20:59

How could you not make epoll work with the Reactor pattern if you can have a common interface in front of poll() and epoll?
aderouineau
 
Posts: 163
Joined: 18 May 2009, 17:38

PreviousNext

Return to Support

Who is online

Users browsing this forum: No registered users and 2 guests