- From: Jens Meggers <jens.meggers@firepad.com>
- Date: Wed, 28 Mar 2001 09:43:59 -0800
- To: "'Anton Belov -- Customer Engineering'" <antonb@scot.canada.sun.com>, www-lib@w3.org
Hi, I do interprete the numbers in a slightly different way. I can imagine that the reason for the 30% performance improvement in the single threaded version is because of the pipelining function in libwww. I assume Miscrosoft does not have implemented that. Libwww does also keep a single connection alive for a short time, thus saving the TCP connection time. The performance degradation in the multithreaded version can be caused because the pipelinine cannot catch up with multiple threads. At least, it cannot do it in the long term. I'm curious what happens when switching off the pipleining in the version that has to compete with the multitheaded Windows DLL. Have you tried that? If not, I would be happy to send you a HTHost.c version that has pipelining switched off. I also have changed the code in a way that allows to specify the max number of requests to be pipelined, which sould be even better than the Microsoft DLL. In your experiment that reports 10 times slower request times, are you using the event based model connecting to severel Host in paraellel. Is your load test designed in a way to connect only to a single web server, or are you connecting to different web servers? This is important because it affects the piplining performance. Concerning your first argument with slow networks, I do not agree. Even when your PC is connected to a slow modem, the OS should never wait for the data to be passed. Winsock and the TCP/IP stack are managing buffers that are designed in a way not to wait until a slow network sends it data. Keep in mind that TCP/IP is packet based and that a whale bunch of data is passed between the internal APIs at a single time. In principal, there should be no difference between a slow and a fast network. Also, a multithreaded version should perform lightly worse on a slow network because it opens several TCP connection, causing some overhad due to additional signalling. Cheers, Jens -----Original Message----- From: Anton Belov -- Customer Engineering [mailto:antonb@scot.canada.sun.com] Sent: Mittwoch, 28. März 2001 07:45 To: www-lib@w3.org Subject: Re: libwww multithreading once more... I think that the processing time may benefit from non-blocking sockets functionality, especially if requests go over a slow network (internet) - a big chunk of the time will be spent on waiting for the response on the socket, so if you use non-blocking ones you may be able to send out a few other requests while waiting. On a fast network (intranet) it probably won't matter though ... On the same topic: what we've done here is to write a little wrapper around libwww that exposes the exact same interface to the user as Microsoft's WinInet DLL (that's why we needed to support multithreading), then we did a little performance comparison on a similar horse-power machines (one NT and another Solaris). For single thread requests we beat them consistenly, the request processing time was at about 30% faster with libwww. However, when we started to add more threads the signle-threaded nature of libwww showed it's face - the response time was increasing linearly with coefficent of 1 with number of threads (10 threads, almost 10 times slower request time), whereas on NT the increase was much slower (10 threads, 5 times slower request time). It was good enough for us, but still it's too bad, because the potential is obviously there. Cheers, Anton >X-Authentication-Warning: balefire.eai.com: uucp set sender to <olga@eai.com> using -f >Really-From: olga@eai.com >From: "Olga Antropova" <olga@eai.com> >To: "Anton Belov -- Customer Engineering" <antonb@opcom-mail.canada.sun.com> >Subject: Re: libwww multithreading once more... >Date: Wed, 28 Mar 2001 09:20:13 -0600 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 > >Yes, >Mutexes will serialize the requests making non-bloking functionality >useless. That is if you lock mutex in event (request) registering and unlock >it in request-done callback. >Common processing time will be the same but the responsiveness from the >clients point of view would suffer. >Olga. > >----- Original Message ----- >From: "Anton Belov -- Customer Engineering" <antonb@scot.canada.sun.com> >To: <olga@eai.com> >Sent: Tuesday, March 27, 2001 10:36 AM >Subject: Re: libwww multithreading once more... > > >> Wouldn't it make harder to make use of non-blocking sockets functionality >? >> >> >> >> >> >X-Authentication-Warning: balefire.eai.com: uucp set sender to ><olga@eai.com> >> using -f >> >Really-From: olga@eai.com >> >From: "Olga Antropova" <olga@eai.com> >> >To: "Anton Belov -- Customer Engineering" ><antonb@opcom-mail.canada.sun.com>, >> <www-lib@w3.org> >> >Subject: Re: libwww multithreading once more... >> >Date: Tue, 27 Mar 2001 10:37:30 -0600 >> >MIME-Version: 1.0 >> >Content-Transfer-Encoding: 7bit >> >X-Priority: 3 >> >X-MSMail-Priority: Normal >> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 >> > >> >Yes, >> >I have simulated multithread-safe libwww having mutexes around the top >level >> >lib accesses in a little lib wrapper. >> >That is simpler and achives (close to) the same behavior. >> > >> >Olga. >> > >> >----- Original Message ----- >> >From: "Anton Belov -- Customer Engineering" <antonb@scot.canada.sun.com> >> >To: <www-lib@w3.org> >> >Sent: Tuesday, March 27, 2001 10:07 AM >> >Subject: Re: libwww multithreading once more... >> > >> > >> >> We have simulated the multithread-safe behaviour, by having only one >> >thread >> >> sitting in the event loop, and others coming in and notifying it >(through >> >domain >> >> socket) that they want to send a request. The event-loop thread would >go >> >and >> >> pick up the request details and send it out, in a mean while the >requester >> >> thread will sleep (on condition variable) until it's notified by the >> >event-loop >> >> thread that it finished processing the request. >> >> >> >> This way the access to the library is always within the same one >thread, >> >on the >> >> other hand an application that uses it thinks that it's doing >> >mutlithreaded >> >> access. Of course, performance-wise it makes absolutely no difference, >> >since the >> >> access is serialized. >> >> >> >> Cheers, >> >> Anton >> >> >> >> >> >> >Resent-Date: Tue, 27 Mar 2001 10:39:47 -0500 (EST) >> >> >Resent-Message-Id: <200103271539.KAA04774@www19.w3.org> >> >> >X-Authentication-Warning: balefire.eai.com: uucp set sender to >> ><olga@eai.com> >> >> using -f >> >> >Really-From: olga@eai.com >> >> >From: "Olga Antropova" <olga@eai.com> >> >> >To: "Roland Bickel" <r.bickel@cmg.nl>, <www-lib@w3.org> >> >> >Date: Tue, 27 Mar 2001 09:40:01 -0600 >> >> >MIME-Version: 1.0 >> >> >Content-Transfer-Encoding: 7bit >> >> >X-Priority: 3 >> >> >X-MSMail-Priority: Normal >> >> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 >> >> >Subject: Re: libwww multithreading once more... >> >> >Resent-From: www-lib@w3.org >> >> >X-Mailing-List: <www-lib@w3.org> archive/latest/4813 >> >> >X-Loop: www-lib@w3.org >> >> >Resent-Sender: www-lib-request@w3.org >> >> >List-Id: <www-lib.w3.org> >> >> >List-Help: <http://www.w3.org/Mail/> >> >> >List-Unsubscribe: <mailto:www-lib-request@w3.org?subject=unsubscribe> >> >> > >> >> >Hi, >> >> > >> >> >In general there are two ways to do multiple requests processing at >the >> >same >> >> >time: >> >> > >> >> >1) blocking system calls and threads >> >> >2) non-blocking system calls and a sophisticated state machine >> >> > >> >> >On the single processor computer the performance of this two >approaches >> >> >should be about the same. >> >> > >> >> >libwww implements the second way of mutiprocessing. That is a more >> >complex >> >> >of the two approaches. >> >> >Laying threads on top of this approach is way too complex if not >> >impossible. >> >> > >> >> >I personally think that libwww is impossible to make thread safe. >There >> >are >> >> >too many global structures. >> >> > >> >> >Olga. >> >> > >> >> >----- Original Message ----- >> >> >From: "Roland Bickel" <r.bickel@cmg.nl> >> >> >To: <www-lib@w3.org> >> >> >Sent: Tuesday, March 27, 2001 9:21 AM >> >> >Subject: libwww multithreading once more... >> >> > >> >> > >> >> >> >> >> >> Right, i've spent a lot of time trying to figure out how the >following >> >> >could >> >> >> be implemented in a asynchronous way.. I hope some of you guys/girls >> >can >> >> >be >> >> >> of help... i cannot imagine i'm the only one ever stumbling across >this >> >> >> problem ... >> >> >> >> >> >> here goes : >> >> >> i want to be able to do multiple, simultaneous http PUT messages, >> >> >> preferrably without a fork construct. So suppose i have one thread >> >walking >> >> >> through the even loop waiting for responses to a previous issued PUT >, >> >if >> >> >> another process tries to send another PUT message *how* can I update >> >the >> >> >> eventloop ? prefer some .c examples.. >> >> >> >> >> >> Thanks in advance, >> >> >> Roland >> >> >> >> >> >> btw.. isn't there some FAQ ? i think this would make a nice topic... >> >> >> >> >> >> >> >> > >> >> >> >> ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~ >> >> >> >> Anton Belov >> >> Sun Microsystems Americas Customer Engineering >> >> anton.belov@canada.sun.com >> >> Ph. (905)415-2841 Fax. (905)477-0217 >> >> >> >> >> > >> >> ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~ >> >> Anton Belov >> Sun Microsystems Americas Customer Engineering >> anton.belov@canada.sun.com >> Ph. (905)415-2841 Fax. (905)477-0217 >> >> > ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~ Anton Belov Sun Microsystems Americas Customer Engineering anton.belov@canada.sun.com Ph. (905)415-2841 Fax. (905)477-0217 ------------- End Forwarded Message ------------- ~v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^vv^v^v^v^v^v^v^v^v^v^v^~ Anton Belov Sun Microsystems Americas Customer Engineering anton.belov@canada.sun.com Ph. (905)415-2841 Fax. (905)477-0217
Received on Wednesday, 28 March 2001 12:54:27 UTC