W3C home > Mailing lists > Public > www-lib@w3.org > January to March 2001

RE: libwww multithreading once more...

From: Jens Meggers <jens.meggers@firepad.com>
Date: Wed, 28 Mar 2001 09:43:59 -0800
Message-ID: <DDF913B74F07D411B22500B0D0206D9F185485@FIREPLUG>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:39 GMT