Not able to use multiple cores with boost::asio::ssl
Hi, I have an application where I am planning to use boost::asio's ssl streams. There are two parts of the app, the initial connection establishment and ssl handshake is done by boost::asio::ssl and the connection is then transferred to the core application which does the the rest. I have written a prototype using multiple threads and io_services similar to io_service_pool example. I am using a dual quad core machine, however I am not able to get the cpu usage beyond one core (i.e. it never exceeds 12-14% in the top) no matter how much the load. On doing some profiling I found that the time taken from socket accept to ssl handshake completion deteriorates linearly with the number of connections without using the other cores. I am not using any explicit locks so expected the application to scale well with the number of cores available. Is is not possible to use multiple cores with boost::asio::ssl libraries or am I not doing it right? A pseudo-code of the app- start connection acceptors handle_accept() { new_conn = new Connection(io_service_pool.get_io_service()); new_conn->start(); } Connection::start() { ssl_socket_.async_handshake(handle_handshake); } Connection::handle_handshake(error) { if (!error) // transfer connection to the application core } Thanks in advance, Ramashish
I wouldn't expect that the number of cores would affect the number of
concurrent SSL sockets you are able to accept and handshake; this
would seem to be a function of the I/O subsystem of the machine and OS
(as seems to be demonstrated by the relatively low CPU usage). OpenSSL
itself may be part of the problem.
On Thu, Oct 8, 2009 at 10:49 PM, Ramashish Baranwal
Hi,
I have an application where I am planning to use boost::asio's ssl streams. There are two parts of the app, the initial connection establishment and ssl handshake is done by boost::asio::ssl and the connection is then transferred to the core application which does the the rest. I have written a prototype using multiple threads and io_services similar to io_service_pool example.
When you say that "the connection is then transferred to the core application", are you saying it is no longer being handled via asio?
On Fri, Oct 9, 2009 at 8:45 PM, Oliver Seiler
I wouldn't expect that the number of cores would affect the number of concurrent SSL sockets you are able to accept and handshake; this would seem to be a function of the I/O subsystem of the machine and OS (as seems to be demonstrated by the relatively low CPU usage). OpenSSL itself may be part of the problem. Thanks for the reply. The platform is Linux (kernel 2.6.28). I too suspected that OpenSSL may be serializing its operations, though I feel this should not be so. I will confirm the OpenSSL behaviour by using it in multiple threads and seeing whether it is able to utilize more than one core.
I have an application where I am planning to use boost::asio's ssl streams. There are two parts of the app, the initial connection establishment and ssl handshake is done by boost::asio::ssl and the connection is then transferred to the core application which does the the rest. I have written a prototype using multiple threads and io_services similar to io_service_pool example.
When you say that "the connection is then transferred to the core application", are you saying it is no longer being handled via asio?
Right, the connection is then no longer being handled by asio. I didn't find any way to get the control of the underlying socket and ssl impl object, they are always destroyed by asio. So, I am making sure that the ssl stream object is not destroyed till the connection is alive.
participants (2)
-
Oliver Seiler -
Ramashish Baranwal