perfsonar development work

[Nina Jeliazkova <>]

Hello Chris,

As some of you may have already noticed, there is an updated version of
perfsonarUI online,  with the suggested Populate option added.
It still consumes lot of memory, but should work reasonable until we
find a better alternative for XML processing.

Regards,
Nina

Chris Welti написа:
> Hi Nicolas,
>
> Reducing the SWITCH data set from over 300 interfaces down to 38 like in 
> GEANT, I get similar performance, around 1-2 seconds for the list of 
> interfaces and about 5 seconds to get all the data from all interfaces. 
> (btw, this also depends a little bit on the kind of time period that you 
> select).
> It seems that the MA does not scale well for many interfaces. It should be 
> tested how many interfaces are still feasible.
>
> Chris
>
>
> Nicolas Simar wrote:
>   
>> Chris Welti wrote:
>>     
>>> Personally I currently don't see the "retrieve all" to make any sense,
>>> as it does not seem to work properly anyway.
>>> If it takes more than a minute to get the results, what's the point?
>>> I even tried to use the perfsonarUI to do an retrieve all from the
>>> GEANT MA, which does not have that many interfaces, and it just locks
>>> up after a while, without any results.
>>> Does that function work for anyone that is running a production MA?
>>>       
>> I can do retrieve all from
>>
>> 1) GARR, 114 interfaces, 58 secs to get the data from all the interfaces
>>
>> 2) GARR, 114 interfaces, 9 sec to get the list of interfaces, stopped
>> after 2 minutes, didn't get a single result
>>
>> 3) GEANT2, 38 interfaces, 2 sec to get the list of interfaces, 6 secs to
>> get the data from all the interfaces
>>
>> 4) Hungarnet, 141 interfaces  , 4 sec to get the list of interfaces, 141
>> interfaces, pSUI indicated completed but no data available.
>>
>> 5) GARR, 114 interfaces, 9 sec to get the list of interfaces,1:31 to get
>> the data from the first 10 interfaces, 1:42 to get all of them, Error
>> code     error.rrdma.rrdjtool; clear data
>>
>> 6) GEANT2, 38 interfaces, 2 sec to get the list of interfaces, 4 secs to
>> get the first data, 3 second to get all the data completed. Error code
>> error.ma.query; clear data
>>
>> 7) Hungarnet, 141 interfaces , 8 sec to get the list of interfaces, no
>> data received. Error code     error.ma.query
>>
>> Nicolas
>>
>>     
>>> Regards,
>>> Chris
>>>
>>>
>>> Jason Zurawski wrote:
>>>
>>>
>>>       
>>>>>> I think the "retrieve all" is a good thing to have, but particularly
>>>>>> when testing large deployments (ESnet has 1000s of interfaces for
>>>>>> example) it would be good to have functionality to do the metadata
>>>>>> request to populate pS-UI, then selectively retrieve interface info
>>>>>> for
>>>>>> data requests instead of automatically getting everythihng. 
>>>>>> Working on
>>>>>> a Mac mini at SC, it was impossible to run pS-UI due to the volume of
>>>>>> data generated by certain services (also caused repeated Heap
>>>>>> Overflows).  
>>>>>>             
>>>>> I agree for testing purposes it will be convenient to send obnly
>>>>> metadata request.  I am thinking of two options
>>>>> 1) add a new menu item (in addition to retrieve all) with
>>>>> functionality to send only metadata request , therefore the table will
>>>>> be filled in only with interface metadata and no utilization
>>>>> statistics, and no data will be displayed at barchart /radar chart. In
>>>>> this case, could you suggest an appropriate title for the new menu
>>>>> item?
>>>>> or
>>>>> 2)add an option somewhere in order to switch the behaviour of
>>>>> "Retrieve All" between current behaviour and sending only metadata
>>>>> request.
>>>>>
>>>>> Which will be the preferred way?
>>>>>           
>>>> Option 1 makes the most sense to me, I would call this choice "Populate"
>>>> or something similar.  After this step there would need to be two
>>>> options for data retrieval: the current "retrieve all", then the ability
>>>> to select interfaces from the table, and simply "retrieve selected".
>>>> Anyone else feel strongly one way or another about this?
>>>>
>>>> -jason
>>>>
>>>>
>>>>         
>>>       

-- 
---------------------------------
Dr. Nina Nikolova-Jeliazkova
Institute for Parallel Processing
Bulgarian Academy of Sciences
Acad. G. Bonchev St 25-A
1113 Sofia, Bulgaria
Tel: +359 886 802011
ICQ: 10705013
www: http://ambit.acad.bg/nina
---------------------------------
PGP Public Key
http://cert.acad.bg/pgp-keys/keys/nina-nikolova-0xEEABA669.asc
        8E99 8BAD D804 1A43 27B7  7F87 CF04 C7D1 EEAB A669
---------------------------------------------------------------