I've applied the patches from Bug 40103 and created another nightly build.
Response parsing is now optional. [But it looks like the parsing time was not included in the sample response time]. Also the code no longer appends so many strings in order to create the response, so it should perform a bit better. It seems to work, as far as I can tell, but I don't have much experience in using LDAP, so it would be good it someone else could try it out. The XML response data should now be well-formed (even when Exceptions occur), but whether it is correctly formatted I don't know: For example, should the search results be nested in the <operation> tag? Also, the <searchbase> tag includes the rootDN which does not seem right, and the <dn> tag includes the name, the searchbase and the rootDN. Seems a bit wasteful to repeat this information, but maybe that is standard? On 22/01/07, Bruno Cosnefroy <[EMAIL PROTECTED]> wrote:
Hi, Thanks a lot Dolf for your answer. The time response of my "big" request was measured from another client. So I agree with you this should be a parsing problem in Jmeter. If somebody knows where I can find a patch not to parse the response (if it is not already included in Jmeter) and/or how to configure Jmeter to do that, I am really interested. Thanks, Bruno On 1/20/07, Smits, Dolf <[EMAIL PROTECTED]> wrote: > Hi, > > There might be a problem that all answers are parsed by Jmeter. > > I think that this was reported before, and a patch was made so you can > choose to NOT parse the answer. This is specially done for these kind of > cases. > In fact you do need the answer, because that is what the server sends. > So if the server really send the complete ansewer in less than one > second you need to stop parsing. > > Unfortunatly, some patches for the LDAP part are still in bugzilla, but > need to be applied to the source. > > One warning. > If your server reports that the search request took less than one > second, this does not necisarrily mean that the answer was received by > the clinet within one second. > Launching the same request over the network, and timing till the > complete answer was received is the important time. > If this really is less than a second, the problem is definitely within > parsing the answer within Jmeter. > If this also takes a long time, other issues might interfere. > > Hope this helps you a bit. > > Dolf > > > Dolf Smits > Senior Consultant Identity Management Solutions > > 070 333 3654 > 070 333 2511 > 06 55844837 > [EMAIL PROTECTED] > Let op: Vrijdags heb ik ouderschapsverlof en wordt uw mail niet gelezen. > Deze e-mail is uitsluitend bedoeld voor kennisneming door de > geadresseerde(n), en mag niet aan anderen worden doorgestuurd of op > andere wijze ter kennis worden gebracht. Indien u niet de geadresseerde > bent, verzoek ik u om de afzender te waarschuwen en de e-mail direct te > verwijderen/vernietigen. De afzender wijst elke aansprakelijkheid voor > (de inhoud van) deze e-mail af. > > > > > -----Original Message----- > From: Bruno Cosnefroy [mailto:[EMAIL PROTECTED] > Sent: vrijdag 19 januari 2007 16:22 > To: [email protected] > Subject: JMeter LDAP extended request : issue with big response > > Hi, > > I use Jmeter to send LDAP extended request to my LDAP directory. > It works fine for every request I have to send except for one. > The request takes less than one second with ldapsearch. However, the > response contains 4400 entries (29000 lines in ldif). > I can't make this request work in Jmeter, even in csv and non-GUI mode. > (I see the request in my ldap server logs but the jmeter client stop > working and the following requests are not sent) > Any idea of configuration? (I don't want the response data but only > the response time). > The CPU usage increases a lot when I try and I have to stop the process. > > Have anyone make tests with request receiving big response in Jmeter? > > > Thanks in advance, > Bruno > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
