Overview
Features
Download
Documentation
Community
Add-Ons & Services

HTTPServerConnection

A general discussion forum.

HTTPServerConnection

Postby amercieca » 25 Jun 2010, 16:08

Hi,

I had a look at the code in HTTPServerConnection .cpp (version 1.3.6p2), line 86, and the code is making a call to createRequestHandler on the HTTPRequestHandlerFactory object. This returns a new request handler on the heap each time and assigns it to an auto_ptr for eventual cleanup .

Code: Select all
std::auto_ptr<HTTPRequestHandler> pHandler(_pFactory->createRequestHandler(request))


I have hacked the code a bit so that the handler returned is not deleted, and in my HTTPRequestHandlerFactory implementation, I return the address of the same HTTPRequestHandler each time (which is allocated on the stack). This I did because I thought that allocating a new request handler for each call might be expensive for heavy loads. I tested my code and it works ok. Obviously, the code in the request handler has to be thread and reentrant safe.

Humbly, could I ask as to why this was implemented this way? Why is a new request handler created on the heap for each call? Would the approach I mentioned above make for better performance?

Or maybe, the HTTPServerConnection class could have some kind of option specified - say in the constructor - to denote if request handlers returned by the createRequestHandler call on the factory to be deleted or not? Because in that way, one could implement either approach.

Comments would be appreciated.

Thanks.
amercieca
 
Posts: 3
Joined: 25 Jun 2010, 15:11

Re: HTTPServerConnection

Postby guenter » 26 Jun 2010, 09:12

I don't think allocating the request handler on the heap will have much of an influence to performance. First, there are at least 5 to 10 memory allocations happening for each request anyway (e.g., various std::string objects in the HTTPServerRequest object, a std::map for headers, etc.), so one additional allocation for the request handler does not make much of a difference. Then, on a modern system, under heavy network load, the bottleneck will not be memory allocations, but threading and network I/O.

The reason the framework has been designed this way is because it makes it easier to write request handlers. Because every request handler object is only used once, and in one thread makes it much easier to implement one. You don't have to care about synchronization issues (unless you access shared resources), and you don't have to care about proper cleanup when the handler is done.
guenter
 
Posts: 1110
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: HTTPServerConnection

Postby amercieca » 27 Jun 2010, 08:54

Hi guenter,

Thanks for your answer.

I do see your point about one extra heap allocation not being a performance bottleneck.
Just wanted to note though that allocating a new request handler for each request does not just entail the heap allocation/deallocation; it also entails the required constructor calls, and any other/further initialization processing required. Now, numerous allocations, constructor calls and initialization processing, whilst possibly not being too expensive as a single unit, they do add up as a whole and could impact performance.

And as for it being simpler to implement due to synchronization issues, that is all fine for instance resources because, as you said, these resources are 'automatically' thread safe; but this would still require attention to shared resources - and in many cases, this is the case. So not having to deal with synchronization issues because a new request handler is created each time, will - in most cases - not prevent a developer from having to deal with synchronization issues. Say if a request handler needs to access a database and execute a few queries to process the request, who would establish the database connection each time in the new request handler? One would surely establish the db connection (maybe as part of a connection pool) elsewhere, keep it around as a shared resource for far better performance. And this would obviously entail the developer having to deal with synchronization issues. What I mean is that if the rationale for allocating a new request handler for each request, is to do away with synchronization issues, in most cases, one would still need to deal with such issues for access to global resources - effectively defeating the purpose of creating a new request handler each time.

Anyway, just my 2p worth.

Thanks.
amercieca
 
Posts: 3
Joined: 25 Jun 2010, 15:11


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron