RE: libwww multithreading once more...

Hi, 

ok, this goes a bit beyond my knowledge, so let me catch up ;-) In a mean while
i would love to try out your version of HTHost.c However, before this, let me 
just make sure we're on the same page:

The way we implemented the multithreaded access to libwww is by having one 
"main" thread sitting and processing requests (in the event loop). The client 
threads that come in notify this main thread that they need to send out the 
resuest through the "breaker" domain socket, pass the request info, and go to 
wait on condition variable which gets signalled by the "main" thread when it 
gets the response for the client's request. At this point client thread wakes up 
and continues doing it's stuff ...

So, from the user point of view all the requests are blocking, meaning that we 
didn't implement the asynchronous mode of WinInet (although it wouldn't be a big 
deal to add it - the framework is already in place). 

What i'm leading to is that each client has to wait until it's request is done 
before submitting a new one. I just wanted to make sure it's clear. 


>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.

We were always hitting the same server (without cache of course). Although, 
according to what you've said, we should've tried it on multiple servers.

>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. 

Are you saying that if i do send() and then recv() on a blocking socket, the 
time i will be waiting for recv() to finish does not depend on the speed 
(round-trip delay) of the network ?


Cheers,
Anton

P.S. Thanks a lot for the information !!!






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
>

~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 13:39:23 UTC