Skip to Content.
Sympa Menu

perfsonar-dev - RE: [pS-dev] Performance Testing

Subject: perfsonar development work

List archive

RE: [pS-dev] Performance Testing


Chronological Thread 
  • From: Michael Michalis <>
  • To: 'Maciej Glowiak' <>
  • Cc: 'Andreas Hanemann' <>, 'Nina Jeliazkova' <>, 'Loukik Kudarimoti' <>, 'Ilias Tsompanidis' <>, , "'Athanassios C. Liakopoulos'" <>, 'Jochen Reinwand' <>
  • Subject: RE: [pS-dev] Performance Testing
  • Date: Mon, 14 May 2007 08:21:28 +0300

Hi Maciej,

Thanks for your feedback. Please find my comments in line.

> -----Original Message-----
> From: Maciej Glowiak
> [mailto:]
> Sent: Friday, May 11, 2007 2:39 PM
> To: Michael Michalis
> Cc: 'Andreas Hanemann'; 'Nina Jeliazkova'; 'Loukik Kudarimoti'; 'Ilias
> Tsompanidis';
> ;
> 'Athanassios C. Liakopoulos';
> 'Jochen Reinwand'
> Subject: Re: [pS-dev] Performance Testing
>
> Michalis,
>
> Please find some of my comments:
>
> 1)
>
> You mentioned about measuring network connectivity times: T3, T4. In
> case of Java services it'll be difficult to measure these times, because
> of Axis. Perhaps we could use some internal Axis handlers or listeners,
> but we should ask someone who knows Axis better than me :)

I think finding a way to measure T3&T4 is useful. In one hand we can safely
determine service performance without incorporating the network latency, and
on the other hand in conjunction with T1&T2 measurements we can actually
measure what the network latency could be. But I think in the Utrecht
meeting was decided not mess with the service or base code for now.

> As far as I understand, your document describes how the performance
> tests should be done in general, but your test case example was LS, so I
> assume it'll be one of the first tested services, so understanding our
> Java architecture would be quite important.

Yes I've selected the LS for giving the examples, because I thought LS
request can differentiate a lot from each other and because of some problems
with the eXist database. Definitely I agree that good knowledge of the
service architecture is extremely important.
> So, We have:
>
> Client -> network -> Axis -> RequestHandler -> MessageHandler -> Service
> (and the reverse sequence in back way)

We can consider our services to "begin" at RequestHandler.
> Network connectivity time is dependent on various circumstances, and
> should be regarded separately.
>
> Axis is now a black box for us. We can't measure time between sending
> message to the service and passing message as DOM to Request Handler.
>
> RequestHandler, AFAIR, already measures time in milliseconds (I don't
> remember exactly, for sure I did it for my LS internal performance
> testing). The same may be done for MessageHandler and Service.

If this is the case, it can be very useful if we decide to leave axis out of
the measurement, and if there are measurement points in MeassageHandler and
I Service that will be great.


> In fact RequestHandler and MessageHandler may be consider together as
> "PerfSONAR-base".
>
> If you need any changes in perfSONAR-base classes in order to measure
> times of various components, just let me know.

As I said earlier it was decides not to temper with the code at this point.
If thinks are decided differently then we will definitely let you know :).
> 2)
>
> Categorization of requests is good idea in general, but without
> understanding the way how it works may be false.
>
> For instance LSQuery and LSRegister. My understanding of your thoughts
> was that LSQuery may be more time consuming because it's dependent on
> what LS was asked for. That's true of course. But LSRegister may be even
> more time-consuming because of internal storage of XML database
> (sometime simple registration takes tens of seconds!).


> So, I think in all cases there should be agreement between testing team
> and developers how to categorize requests and what they're dependent on.


Yes you are right, the cases used in the doc were just an example.
Categorization of the requests can only be made with the help of the
developer of the service and the actual users.



Michalis
>
> Best regards
>
> Maciej
>
>
>
>
> Michael Michalis wrote:
> > Sorry forgot the doc.
> >
> >> -----Original Message-----
> >> From: Andreas Hanemann
> >> [mailto:]
> >> Sent: Thursday, May 10, 2007 2:39 PM
> >> To: Michael Michalis
> >> Cc: Nina Jeliazkova; Loukik Kudarimoti; Ilias Tsompanidis; perfsonar-
> >> ;
> >> Athanassios C. Liakopoulos; Jochen Reinwand
> >> Subject: Re: [pS-dev] Performance Testing
> >>
> >> Hi Michalis,
> >>
> >> I have used the commented version from Nina and added some comments on
> >> my own. The testing method that you describe is very useful at least as
> >> a first step. We have to see whether we need more specific tests later.
> >> These could be needed to exactly determine the conditions of a service
> >> performance problem (e.g. the differences between response time for LS
> >> registration and deregistration requests reported during the perfSONAR
> >> meeting by RNP).
> >>
> >> Best regards
> >> Andreas
> >>
> >> Nina Jeliazkova wrote:
> >>> Hello Michael,
> >>>
> >>> Please find my comments in track changes (attached).
> >>>
> >>> Best regards,
> >>> Nina
> >>>
> >>> Michael Michalis
> >>> <>
> >>> wrote:
> >>>
> >>>
> >>>> Hi all,
> >>>>
> >>>>
> >>>>
> >>>> I've put together an initial document describing performance testing.
> I
> >>>> would greatly appreciate any comment or suggestions made on the
> >> document.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Best Regards,
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Michalis Michael
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> Andreas Hanemann,
> >>
> >> Boltzmannstrasse 1, 85748 Garching, Germany
> >> Telefon: +49 89 35831-8712
> >> Fax: +49 89 35831-9700
> >
>
>
> --
>
> --------------------------------------------------------------------
> | Maciej Glowiak Network Research and Development ||
> |
>
> Poznan Supercomputing and Networking Center ||
> | (+48 61) 858 2024 -- skype_id: maciej_psnc GG: 4526858 ||
> ====================================================================




Archive powered by MHonArc 2.6.16.

Top of Page