[asio-users] Async HTTP and requests requiring long processing time

[Bruno Coudoin]

Hi,

I have an HTTP server based on HTTP Server 3. We run it on Boost 1.42 on
Debian 6.

The server works fine for years. Recently we added a new feature that
requires a long processing time like 10 minutes. When even a single
client make this request, our server starts slowly to no more accept
incoming requests. On the client side, we stay connected indefinitely.

With netstat I can see a lot of sockets associated to my server process
in the CLOSE_WAIT state. Under normal operation, without this long
processing it does not happens.

It is similar to the previous post by George van Venrooij. In my case, I
ended up testing with simple wget so I am sure the problem is not on the
client side.

Beside this long request, the load is very small like 10 clients at 1
request per second.

Does anybody experience a similar behavior? Is doing long processing
supported or is there a way to make it works.

BTW, I changed the code to run the long processing in a background
thread and return immediately to the client and the problem is gone.

Bruno.

[Guilherme Namen]

Hi Bruno.
For this problem there are several ways to solve. So I will give to some
solutions.
*Multiply data multiply request*
You can stop the connection and make a request to thread pool, so this way
you can restrict the access to some resources and limit the cpu time to
process the same thing.
With this process you can create a queue with the request parameters
putting two or more request in same process in the thread pool, and put one
thread process to write the response to its respective request.
*Single data multiply request*
If you have a process that access the same data you can put this data in
memory and create a read write mutex to access this data. This perspective
every request is read thread on the data, and you can put a batch process
to update the data.
*Few data multiply request*
You can use the both solutions create a queue for each data type.

Post by Bruno Coudoin
Hi,
I have an HTTP server based on HTTP Server 3. We run it on Boost 1.42 on
Debian 6.
The server works fine for years. Recently we added a new feature that
requires a long processing time like 10 minutes. When even a single
client make this request, our server starts slowly to no more accept
incoming requests. On the client side, we stay connected indefinitely.
With netstat I can see a lot of sockets associated to my server process
in the CLOSE_WAIT state. Under normal operation, without this long
processing it does not happens.
It is similar to the previous post by George van Venrooij. In my case, I
ended up testing with simple wget so I am sure the problem is not on the
client side.
Beside this long request, the load is very small like 10 clients at 1
request per second.
Does anybody experience a similar behavior? Is doing long processing
supported or is there a way to make it works.
BTW, I changed the code to run the long processing in a background
thread and return immediately to the client and the problem is gone.
Bruno.
------------------------------------------------------------------------------
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

[Bruno Coudoin]

Hi,

Thanks for your feedback. Yes I know how to work around this issue and I
already fixed it.

What makes me sad is that I lost a lost of time on this issue, I found
no documentation explaining that it was not recommended to process long
request.

If there is not way to make asio to stay functional in this case, may I
suggest a little warning in the documentation.

Bruno.

Post by Guilherme Namen
Hi Bruno.
For this problem there are several ways to solve. So I will give to
some solutions.
*Multiply data multiply request*
You can stop the connection and make a request to thread pool, so this
way you can restrict the access to some resources and limit the cpu
time to process the same thing.
With this process you can create a queue with the request parameters
putting two or more request in same process in the thread pool, and
put one thread process to write the response to its respective request.
*Single data multiply request*
If you have a process that access the same data you can put this data
in memory and create a read write mutex to access this data. This
perspective every request is read thread on the data, and you can put
a batch process to update the data.
*Few data multiply request*
You can use the both solutions create a queue for each data type.
Hi,
I have an HTTP server based on HTTP Server 3. We run it on Boost 1.42 on
Debian 6.
The server works fine for years. Recently we added a new feature that
requires a long processing time like 10 minutes. When even a single
client make this request, our server starts slowly to no more accept
incoming requests. On the client side, we stay connected indefinitely.
With netstat I can see a lot of sockets associated to my server process
in the CLOSE_WAIT state. Under normal operation, without this long
processing it does not happens.
It is similar to the previous post by George van Venrooij. In my case, I
ended up testing with simple wget so I am sure the problem is not on the
client side.
Beside this long request, the load is very small like 10 clients at 1
request per second.
Does anybody experience a similar behavior? Is doing long processing
supported or is there a way to make it works.
BTW, I changed the code to run the long processing in a background
thread and return immediately to the client and the problem is gone.
Bruno.

[Green, Cliff]

... Recently we added a new feature that requires a long processing time like 10 minutes.

As Guilherme has already recommended, queuing the work to another thread is the way to go. This is a general recommendation for Asio design - if a handler is going to take a "long" time to complete, pass the work off to something else. I generally do all network event processing in one thread - i.e. all Asio related work is in a single thread (which simplifies a lot of issues), and if functionality is needed that is compute or IO intensive, that work is passed to another thread (which knows nothing about network / Asio). Sometimes the design can get a bit complicated when dealing with "transactional" type network requests, but there are straightforward solutions.

Cliff

[Guilherme Namen]

You can use the sleeping barber problem (
http://en.wikipedia.org/wiki/Sleeping_barber_problem) that is a thread
synchronization patter in this case.
The barber is your IO process the customer are the request the wait room is
the maximum request that can wait. There is a another implementation of
this synchronization problem that evolve more than one barber that you can
use.

Post by Bruno Coudoin

... Recently we added a new feature that requires a long processing

time like 10 minutes.
As Guilherme has already recommended, queuing the work to another thread
is the way to go. This is a general recommendation for Asio design - if a
handler is going to take a "long" time to complete, pass the work off to
something else. I generally do all network event processing in one thread -
i.e. all Asio related work is in a single thread (which simplifies a lot of
issues), and if functionality is needed that is compute or IO intensive,
that work is passed to another thread (which knows nothing about network /
Asio). Sometimes the design can get a bit complicated when dealing with
"transactional" type network requests, but there are straightforward
solutions.
Cliff
------------------------------------------------------------------------------
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
asio-users mailing list
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

[Gruenke, Matt]

Can anyone explain why? Are there any locks held while executing
completion handlers? Or does this advice originate purely from a
standpoint of not wanting to let the connection go idle?


Matt

-----Original Message-----
From: Green, Cliff [mailto:***@boeing.com]
Sent: June 14, 2013 13:47
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] Async HTTP and requests requiring long
processing time

... Recently we added a new feature that requires a long processing

time like 10 minutes.

As Guilherme has already recommended, queuing the work to another thread
is the way to go. This is a general recommendation for Asio design - if
a handler is going to take a "long" time to complete, pass the work off
to something else. I generally do all network event processing in one
thread - i.e. all Asio related work is in a single thread (which
simplifies a lot of issues), and if functionality is needed that is
compute or IO intensive, that work is passed to another thread (which
knows nothing about network / Asio). Sometimes the design can get a bit
complicated when dealing with "transactional" type network requests, but
there are straightforward solutions.

Cliff