Since my last patch submission (Round2) I spent a considerable amount of time performing performance analysis of my proposed both client side and server side.
The client side testing primarily consisted of running parallel copies of slapd-mtread and monitoring in real time with dtrace to monitor the behavior of all the concurrent threads in clients looking for signs of thread starvation. I was not able to find any.
On the server side I performed similar testing while using modified versions of the test036-meta-concurrency and test020-proxycache test cases. Again looking for thread starvation.
Additionally, on the server side I setup single server and proxy cache server environments, in combination with slamd to perform head to head comparisons of HEAD (most recently as of 10/7/10) vs. HEAD (most recently as of 10/7/10) and the round 3 MT patches
to see if there was any performance degradations or other performance issues, especially related to situations where slapd was using libldap_r as part of various backends.
The results of the head to head comparisons, especially in the proxycache situation, show a 3% performance improvement with the MT patches over the HEAD without the patches.
The reason according to dtrace outputs is that there are now cases, especially in ldap_result where my proposed patch has up to 50% less calls to thread_lock/unlock than are performed in the current HEAD.
All of the head to head dslam/dtrace results are included along with the other patch materials.
The proposed patch details are located here:
http://cr.opensolaris.org/~djl/openldap-codereview-r3/
Details about the contents of http://cr.opensolaris.org/~djl/openldap-codereview-r3/dtrace is located here: http://cr.opensolaris.org/~djl/openldap-codereview-r3/README.txt
Doug.
Doug Leavitt wrote:
Since my last patch submission (Round2) I spent a considerable amount of time performing performance analysis of my proposed both client side and server side.
Sounds good, I've done a very brief review. I'd like to see the LWP removal as a separate patch. Also would like to see the introduction of LDAP_MUTEX_LOCK() and friends as a separate patch, before the real functionality changes.
The client side testing primarily consisted of running parallel copies of slapd-mtread and monitoring in real time with dtrace to monitor the behavior of all the concurrent threads in clients looking for signs of thread starvation. I was not able to find any.
On the server side I performed similar testing while using modified versions of the test036-meta-concurrency and test020-proxycache test cases. Again looking for thread starvation.
Additionally, on the server side I setup single server and proxy cache server environments, in combination with slamd to perform head to head comparisons of HEAD (most recently as of 10/7/10) vs. HEAD (most recently as of 10/7/10) and the round 3 MT patches
to see if there was any performance degradations or other performance issues, especially related to situations where slapd was using libldap_r as part of various backends.
The results of the head to head comparisons, especially in the proxycache situation, show a 3% performance improvement with the MT patches over the HEAD without the patches.
The reason according to dtrace outputs is that there are now cases, especially in ldap_result where my proposed patch has up to 50% less calls to thread_lock/unlock than are performed in the current HEAD.
All of the head to head dslam/dtrace results are included along with the other patch materials.
The proposed patch details are located here:
http://cr.opensolaris.org/~djl/openldap-codereview-r3/
Details about the contents of http://cr.opensolaris.org/~djl/openldap-codereview-r3/dtrace is located here: http://cr.opensolaris.org/~djl/openldap-codereview-r3/README.txt
Doug.
On 10/ 9/10 10:06 AM, Howard Chu wrote:
Doug Leavitt wrote:
Since my last patch submission (Round2) I spent a considerable amount of time performing performance analysis of my proposed both client side and server side.
Sounds good, I've done a very brief review. I'd like to see the LWP removal as a separate patch. Also would like to see the introduction of LDAP_MUTEX_LOCK() and friends as a separate patch, before the real functionality changes.
No problem. I can break them up. I propose delivering them as:
patch 1: remove old Sun LWP code patch 2: macro definition changes (LDAP_MUTEX_LOCK() and friends) patch 3: MT hot changes using patch#2 changes.
Does that seem reasonable?
Doug.
Doug Leavitt wrote:
On 10/ 9/10 10:06 AM, Howard Chu wrote:
Doug Leavitt wrote:
Since my last patch submission (Round2) I spent a considerableamount of time performing performance analysis of my proposed both client side and server side.
Sounds good, I've done a very brief review. I'd like to see the LWP removal as a separate patch. Also would like to see the introduction of LDAP_MUTEX_LOCK() and friends as a separate patch, before the real functionality changes.
No problem. I can break them up. I propose delivering them as:
patch 1: remove old Sun LWP code patch 2: macro definition changes (LDAP_MUTEX_LOCK() and friends) patch 3: MT hot changes using patch#2 changes.
Does that seem reasonable?
Very good, thanks.
Howard Chu wrote:
Doug Leavitt wrote:
On 10/ 9/10 10:06 AM, Howard Chu wrote:
Doug Leavitt wrote:
Since my last patch submission (Round2) I spent a considerableamount of time performing performance analysis of my proposed both client side and server side.
Sounds good, I've done a very brief review. I'd like to see the LWP removal as a separate patch. Also would like to see the introduction of LDAP_MUTEX_LOCK() and friends as a separate patch, before the real functionality changes.
No problem. I can break them up. I propose delivering them as:
patch 1: remove old Sun LWP code patch 2: macro definition changes (LDAP_MUTEX_LOCK() and friends) patch 3: MT hot changes using patch#2 changes.
Does that seem reasonable?
Very good, thanks.
Hi. Since Doug and I have been in touch for this patch a while ago, I just wanted to say that I agree with Howard's analysis and suggestions. Please go ahead.
Thanks, p.
-
Doug Leavitt -
Howard Chu -
Pierangelo Masarati