perfsonar development work

[Nina Jeliazkova <>]

Chris,

I am aware of memory problems, but to address this we have to replace DOM and Axis 1 (I mean form client side) with more efficient alternative. This is currently under development.
BTW, you might try to switch off the simultaneous sending of multiple requests (Options/Request/Send requests in parallel - unchek it) and I am pretty sure you will be able to retrieve all SWITCH interfaces.



The difference is that after metadata request, psUI will start sending Setupdatarequests one by one, thus it will be consuming less memory / less load on server, but more time necessary for communication.


Chris Welti написа:

Hi Nina,

after restarting the perfSONARUI it also works from my PC really quick. Was probably just a bug.
  

... or a delayed start of garbage collection ... anyway, time to do some memory profiling.

If it would be like this for all MA, then I don't see a problem.
Does anyone know what GEANT uses as data source? (RRD?SQL?)
  

I think RRD, but Loukik might correct me.

Regards,
Nina

And what kind of hardware?
Maybe I have to try again for the SWITCH MA when I reduce the data to just 32 interfaces....

Regards,
Chris

Nina Jeliazkova wrote:
  

Chris,

Retrieve all is a major functionality, since all summary displays rely
on it. It is working fine with Geant MA from my side.



Regards,
Nina

Chris Welti написа:
    

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?

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
---------------------------------------------------------------

    

-- 
---------------------------------
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
---------------------------------------------------------------