Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: softfail (athena.apache.org: transitioning domain of
 alex.wulms@scarlet.be does not designate 195.130.132.48 as permitted sender)
Message-ID: <4C77FA80.1070308@scarlet.be>
Date: Fri, 27 Aug 2010 19:48:48 +0200
From: Alex Wulms <alex.wulms@scarlet.be>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; nl;
 rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: dev Digest 26 Aug 2010 13:15:26 -0000 Issue 1836
References: <1282828526.22628.ezmlm@apr.apache.org>
In-Reply-To: <1282828526.22628.ezmlm@apr.apache.org>
Content-Type: multipart/alternative;
 boundary="------------070407030400000705010304"

This is a multi-part message in MIME format.
--------------070407030400000705010304
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Tue, 24 Aug 2010 21:11:54 +0100
Nick Kew wrote:
> On Tue, 24 Aug 2010 20:55:26 +0200
> Alex Wulms <alex.wulms@scarlet.be> wrote:
>
>   
>> > Hi,
>> > 
>> > I'm Alex. This is my first message to this mailing list. Some of you
>> > might already have seen some messages from me on the
>> > dev@httpd.apache.org mailing list.
>>     
> And from FOSDEM, unless I'm confusing you with someone?
>   
Hi Nick, it's indeed me.
>   
>> > Please feel free to include them in a future version of APR.
>>     
> Thanks.  Looks good on the 5-second glance.  Could well be worth
> adopting!  Have you benchmarked it against dbm or memcache, and
> would you think it a good socache backend?
>   
I did not benchmark it against dbm or against memcache. I noticed in APR
some client code to connect to a memcached server and my first instinct
tells me that connecting through a socket (I assume) to another server
process gives a basic performance overhead, even if it is a local socket
through IPC (does memcache support this?, either way, you have at least
the cost of the context switching between the httpd request worker
process and the memcached process for each look-up) so I did not
investigate further into using the memcache code. In stead, I continued
on the shared-memory path that I had already entered before I had the
need for a hash table. Obviously I might have been completely wrong on
my assumption that memcached is a separate process, not integrated in
the httpd request worker process.

I'm not familiar enough with the socache backend to judge if this hash
table implementation is suitable for it. I believe the code might still
need some enhancement.

One important point is that the rmm-hash code is not 100% thread safe
and I have left it up to the client of the API to implement an
appropriate locking strategy in order to protect against potential
corruptions. It is a little bit the same approach as is used for example
in the Java collection framework. The client can usually be more fancy
about determining the size of the critical section and when to invoke
the locks. I have understood that invoking the (global) lock function
itself is a relatively expensive operation so in case of a tight loop
where I need to invoke the rmm-hash methods multiple times and only
execute a little bit of other code, I prefer to lock once before the
loop and unlock after the loop (in my client code) then having the
rmm-hash implementation perform (expensive?) lock/unlock operations per
iteration. But I don't know how well that plays with other usages like
for example in an socache backend.

Cheers,
Alex


> -- Nick Kew


--------------070407030400000705010304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On Tue, 24 Aug 2010 21:11:54 +0100<br>
Nick Kew wrote:<br>
<blockquote type="cite">
  <div class="moz-text-plain" wrap="true" graphical-quote="true"
 style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">
  <pre wrap="">On Tue, 24 Aug 2010 20:55:26 +0200
Alex Wulms <a class="moz-txt-link-rfc2396E"
 href="mailto:alex.wulms@scarlet.be">&lt;alex.wulms@scarlet.be&gt;</a> wrote:

  </pre>
  <blockquote type="cite" style="color: rgb(0, 0, 0);">
    <pre wrap=""><span class="moz-txt-citetags">&gt; </span>Hi,
<span class="moz-txt-citetags">&gt; </span>
<span class="moz-txt-citetags">&gt; </span>I'm Alex. This is my first message to this mailing list. Some of you
<span class="moz-txt-citetags">&gt; </span>might already have seen some messages from me on the
<span class="moz-txt-citetags">&gt; </span><a
 class="moz-txt-link-abbreviated" href="mailto:dev@httpd.apache.org">dev@httpd.apache.org</a> mailing list.
    </pre>
  </blockquote>
  <pre wrap="">And from FOSDEM, unless I'm confusing you with someone?
  </pre>
  </div>
</blockquote>
Hi Nick, it's indeed me.<br>
<blockquote type="cite">
  <div class="moz-text-plain" wrap="true" graphical-quote="true"
 style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">
  <pre wrap="">
  </pre>
  <blockquote type="cite" style="color: rgb(0, 0, 0);">
    <pre wrap=""><span class="moz-txt-citetags">&gt; </span>Please feel free to include them in a future version of APR.
    </pre>
  </blockquote>
  <pre wrap="">Thanks.  Looks good on the 5-second glance.  Could well be worth
adopting!  Have you benchmarked it against dbm or memcache, and
would you think it a good socache backend?
  </pre>
  </div>
</blockquote>
I did not benchmark it against dbm or against memcache. I noticed in
APR some client code to connect to a memcached server and my first
instinct tells me that connecting through a socket (I assume) to
another server process gives a basic performance overhead, even if it
is a local socket through IPC (does memcache support this?, either way,
you have at least the cost of the context switching between the httpd
request worker process and the memcached process for each look-up) so I
did not investigate further into using the memcache code. In stead, I
continued on the shared-memory path that I had already entered before I
had the need for a hash table. Obviously I might have been completely
wrong on my assumption that memcached is a separate process, not
integrated in the httpd request worker process.<br>
<br>
I'm not familiar enough with the socache backend to judge if this hash
table implementation is suitable for it. I believe the code might still
need some enhancement. <br>
<br>
One important point is that the rmm-hash code is not 100% thread safe
and I have left it up to the client of the API to implement an
appropriate locking strategy in order to protect against potential
corruptions. It is a little bit the same approach as is used for
example in the Java collection framework. The client can usually be
more fancy about determining the size of the critical section and when
to invoke the locks. I have understood that invoking the (global) lock
function itself is a relatively expensive operation so in case of a
tight loop where I need to invoke the rmm-hash methods multiple times
and only execute a little bit of other code, I prefer to lock once
before the loop and unlock after the loop (in my client code) then
having the rmm-hash implementation perform (expensive?) lock/unlock
operations per iteration. But I don't know how well that plays with
other usages like for example in an socache backend.<br>
<br>
Cheers,<br>
Alex<br>
<br>
<br>
<blockquote type="cite">
  <div class="moz-text-plain" wrap="true" graphical-quote="true"
 style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">
  <pre wrap="">
<div class="moz-txt-sig">-- 
Nick Kew

</div></pre>
  </div>
</blockquote>
<br>
</body>
</html>

--------------070407030400000705010304--