perfsonar-dev - Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)
Subject: perfsonar development work
List archive
Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)
Chronological Thread
- From: "Michael Bischoff" <>
- To: "Maciej Glowiak" <>
- Cc:
- Subject: Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface)
- Date: Tue, 15 Apr 2008 16:50:06 +0200 (CEST)
- Importance: Normal
hi Maciej,
Didn't know we already fired away with the a new base, is there a place where
this code
resides? Also for clarity, when we talk about the base does this include nmwg?
On a other note: the discussion about incoming (xml-> Object model) is pretty
empty even if
we have to build the whole document anyway stream should still improve memory
footprint.
I'm quite interested in the new base.
Since we are talking about the base two things:
-I still have uncommitted code because of 3.0 release pending; can someone
create a
branch+tag, is this release managements task, or should we do it ourselves?
-Can we please use normal mvn install instead of mvn install:install-file the
former creates
a valid pom with dependencies described.
Best regards,
Michael Bischoff
> Hi Michael,
>
>
> My previous e-mail should give you an idea what was the motivation for
> new psBase (except the performance) and how we would like to solve
> problems. Although we
> didn't analize the code so deeply. So, we're using "we know where the
> problem is" approach,
> however we made some performance testing (but not full profiling).
>
> Now I am a bit busy with dLS implementation (using new base), but if you
> want to do some extra tests of old or new base, it would be great.
>
> Maciej
>
>
>
> Michael Bischoff wrote:
>
>> Hello all,
>>
>>
>> I've tried to harvest most of the idea's flying around and summarise them
>> here:
>>
>>
>> Optimizing large data transfers (including Push Interface)
>>
>>
>> * Leader: RL
>> * Description: Return to project of push proposal. It should also cover
>> the possibility of
>> sending measurement data using non-XML protocol * Expected goals:
>> o Identify benefits and problems o Work on sequence diagram
>>
>> Inline encoded information in xml
>> use two channels: control channel + data channel
>>
>> Changing xml handling:
>> - Streaming DOM
>> - SAX
>> - STAX
>>
>>
>> Perhaps use different strategies for xml-> Object model and Object -> xml
>> for example use
>> dom for incoming and a streaming approach for outgoing.
>>
>> Optimise tomcat?
>>
>>
>> I think it is important to quantify(instrumentation) and make a informed
>> decision based on
>> that, we all have (converting) idea's about optimisation. (Not just the
>> server-side but
>> also the client.)
>>
>> To add my 2 cents: I think it's dangerous to presume things about what
>> optimisation would
>> work; from practise we discovered that the worst hotspot is almost never
>> where you presume
>> it is.
>>
>> To quote Jeff Kesselman(author of
>> http://java.sun.com/docs/books/performance/)
>> "You may think you know what your performance problem is, but you are
>> probably wrong. I've
>> been tuning code the better part of 15 years and I don't think my initial
>> guess as to what
>> my problem was has been right more then once or even close more then
>> twice."
>>
>> On an other note implementing streaming would require quite a change to
>> the personar base
>> code, this is just because how the data currently reaches the
>> ServiceEngine. Although there
>> are elegant solutions around that too. esp with respect to 'incremental
>> DOM'
>>
>> On jet an other note: I can't speak for the whole Java crowd but sending
>> serialised java
>> around isn't something I would lean to Java RMI uses that and it gave
>> everyone performance
>> headaches.
>>
>> About instrumenting/profiling
>>
>>
>> For java:
>> Netbeans has en excellent profiler
>> Management beans (I think they where introduced in 1.5)
>>
>>
>> In general, I think that ideally, we would want a continuous integration
>> server which also
>> does profiling so we can monitor performance improvements along different
>> versions and
>> also spot regressions right away.
>>
>> Best regards,
>>
>>
>> Michael Bischoff
>>
>>
>>
>
>
> --
>
>
> --------------------------------------------------------------------
> | Maciej Glowiak Network Research and Development ||
> |
>
> Poznan Supercomputing and Networking Center ||
> | (+48 61) 858 2024 -- skype_id: maciej_psnc GG: 4526858 ||
> ====================================================================
>
>
>
>
- WS-Notification information, Jeff W. Boote, 04/08/2008
- Conf call: Optimizing large data transfers (including Push Interface), Michael Bischoff, 04/09/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Maciej Glowiak, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Michael Bischoff, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Maciej Glowiak, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Michael Bischoff, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Maciej Glowiak, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Michael Bischoff, 04/15/2008
- Re: [pS-dev] Conf call: Optimizing large data transfers (including Push Interface), Maciej Glowiak, 04/15/2008
- Conf call: Optimizing large data transfers (including Push Interface), Michael Bischoff, 04/09/2008
Archive powered by MHonArc 2.6.16.