Re: [twsocket] HTTP/1.1 pipelining--any need?
The ICSHTTP-server already have support for pipelining as long as you are only serving static files. But if processing a request requires dataprocessing in another thread, the responses might be answered in the wrong order. I put responses and requests in a list and make sure the reponse to be sent is the correct one, if not - wait for the correct one being finished and then send all responses ready for sending. I know Apache support pipelining, at least if you are only getting static files, but I have not yet seen browsers that use pipelining. Regards Bjørnar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois PIETTE Sent: 30. juli 2006 10:03 To: ICS support mailing Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? As Piotr explained, there is no need for threads--it could all be async! In the THttpConnectıonö we need a dynamıc array of requests and when they are storedö we answer them one by one. This is good for static pages located on the same device. Using multithreaded pipeline will drasticaly reduce overall execution time when talking about dynamic pages which - for example - involves querying a database or similar blocking resources (anything which is I/O bound will benefit). Let's take a simple example: Assumin a client sending two pipelined requests for dynamic page. Building a dynamic page require accessing a database located on a dedicated server, accessing a few static files and some processing to build the actual page. In a single threaded piplined operation, everything is done sequenced. In a multithreaded pipeline operation, while a multithreaded approach will have processing for one request while the other is waiting for is database or file access. Overall time is shorter, there is a better CPU usage. Without mention the time shortening if the server is a multiprocessor. Conclusion: as always, multithreading is not mandatory but _may_ help optimize overall performance. If badly used, it may also very well lower performance. And in any case it _will_ lower performance for a single request. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
As Piotr explained, there is no need for threads--it could all be async! In the THttpConnectıonö we need a dynamıc array of requests and when they are storedö we answer them one by one. Regards, SZ - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 9:20 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? How can different threads respond to the same socket?? Seems impossible to me. As I said: Pipelining use would require changing the state machine in ICS component. The change is to clearly separate the execution of the request from the state machine so that it can be delegated to a thread. If you look at the rfc, the requests are meant to be executed serially. The responses must be provided in the same sequence as the requests. This doesn't mean that each request can't be executed by a separate thread. As I said, responses has to be serialized to be sent in the correct order. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Fastream Technologies [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 7:23 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 6:17 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1 is anything utilized by clients in the real world or just hypothetical? Currently no ICS code (client/server) supports it. Pipelining use would require changing the state machine in ICS component. At first glance I don't think it is too much difficult to implement. But performance would be enhanced only when using threads to serve each request in the HTTP server component. The thread has to be used not for the entire client instance but for HTTP request processing only so that pipelining could start different threads to execute each request. Of course serialization would be necessary to send the results in the correct order. How can different threads respond to the same socket?? Seems impossible to me. If you look at the rfc, the requests are meant to be executed serially. Is there any client which make use of pipelining ? I doubt ! I do not know any neither! That's why I felt the need to ask here. Regards, SZ -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
As Piotr explained, there is no need for threads--it could all be async! In the THttpConnectıonö we need a dynamıc array of requests and when they are storedö we answer them one by one. This is good for static pages located on the same device. Using multithreaded pipeline will drasticaly reduce overall execution time when talking about dynamic pages which - for example - involves querying a database or similar blocking resources (anything which is I/O bound will benefit). Let's take a simple example: Assumin a client sending two pipelined requests for dynamic page. Building a dynamic page require accessing a database located on a dedicated server, accessing a few static files and some processing to build the actual page. In a single threaded piplined operation, everything is done sequenced. In a multithreaded pipeline operation, while a multithreaded approach will have processing for one request while the other is waiting for is database or file access. Overall time is shorter, there is a better CPU usage. Without mention the time shortening if the server is a multiprocessor. Conclusion: as always, multithreading is not mandatory but _may_ help optimize overall performance. If badly used, it may also very well lower performance. And in any case it _will_ lower performance for a single request. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] HTTP/1.1 pipelining--any need?
Hello, I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1 is anything utilized by clients in the real world or just hypothetical? Currently no ICS code (client/server) supports it. Best Regards, SubZero -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1 is anything utilized by clients in the real world or just hypothetical? Currently no ICS code (client/server) supports it. Pipelining use would require changing the state machine in ICS component. At first glance I don't think it is too much difficult to implement. But performance would be enhanced only when using threads to serve each request in the HTTP server component. The thread has to be used not for the entire client instance but for HTTP request processing only so that pipelining could start different threads to execute each request. Of course serialization would be necessary to send the results in the correct order. Is there any client which make use of pipelining ? I doubt ! -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
- Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 6:17 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1 is anything utilized by clients in the real world or just hypothetical? Currently no ICS code (client/server) supports it. Pipelining use would require changing the state machine in ICS component. At first glance I don't think it is too much difficult to implement. But performance would be enhanced only when using threads to serve each request in the HTTP server component. The thread has to be used not for the entire client instance but for HTTP request processing only so that pipelining could start different threads to execute each request. Of course serialization would be necessary to send the results in the correct order. How can different threads respond to the same socket?? Seems impossible to me. If you look at the rfc, the requests are meant to be executed serially. Is there any client which make use of pipelining ? I doubt ! I do not know any neither! That's why I felt the need to ask here. Regards, SZ -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
How can different threads respond to the same socket?? Seems impossible to me. As I said: Pipelining use would require changing the state machine in ICS component. The change is to clearly separate the execution of the request from the state machine so that it can be delegated to a thread. If you look at the rfc, the requests are meant to be executed serially. The responses must be provided in the same sequence as the requests. This doesn't mean that each request can't be executed by a separate thread. As I said, responses has to be serialized to be sent in the correct order. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be - Original Message - From: Fastream Technologies [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 7:23 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? - Original Message - From: Francois PIETTE [EMAIL PROTECTED] To: ICS support mailing twsocket@elists.org Sent: Saturday, July 29, 2006 6:17 PM Subject: Re: [twsocket] HTTP/1.1 pipelining--any need? I wonder the optional RFC2616 pipelining mechanism for requests in HTTP/1.1 is anything utilized by clients in the real world or just hypothetical? Currently no ICS code (client/server) supports it. Pipelining use would require changing the state machine in ICS component. At first glance I don't think it is too much difficult to implement. But performance would be enhanced only when using threads to serve each request in the HTTP server component. The thread has to be used not for the entire client instance but for HTTP request processing only so that pipelining could start different threads to execute each request. Of course serialization would be necessary to send the results in the correct order. How can different threads respond to the same socket?? Seems impossible to me. If you look at the rfc, the requests are meant to be executed serially. Is there any client which make use of pipelining ? I doubt ! I do not know any neither! That's why I felt the need to ask here. Regards, SZ -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] HTTP/1.1 pipelining--any need?
Hello! If you look at the rfc, the requests are meant to be executed serially. The responses must be provided in the same sequence as the requests. This doesn't mean that each request can't be executed by a separate thread. As I said, responses has to be serialized to be sent in the correct order. But this doesn't make much sense in common case. Having more than one thread for a single client (additional to single thread for every client) will make thread switching and synchronization stuff the server's bottleneck, not mentioning the code obfuscation. This may, however, be a good thing when requests are done externally (for ex. a call to SQL server on another machine) and while they're completed the HTTP server doesn't do anything useful, but then again - we don't need separate threads to achieve that. -- Piotr Dalek [EMAIL PROTECTED] -- PS. Fajny portal... http://link.interia.pl/f196a -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
