1 / 11

PerfsonarUI Performance experience

PerfsonarUI Performance experience. Nina Jeliazkova ISTF Sofia Bulgaria. PerfsonarUI (new features). User feedback from Cambridge workshop (summary on WIKI) Parallel requests to services No support for asynchronous calls in Axis 1.x Solution – each request in a separate thread

winola
Télécharger la présentation

PerfsonarUI Performance experience

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PerfsonarUI Performance experience Nina Jeliazkova ISTF Sofia Bulgaria

  2. PerfsonarUI (new features) • User feedback from Cambridge workshop (summary on WIKI) • Parallel requests to services • No support for asynchronous calls in Axis 1.x • Solution – each request in a separate thread • Aggregated requests • Dropping requests • Improved error reporting • Improved user interface • Plug-ins

  3. SetupDataRequests • Sequentially • One query per interface • Slow, multiplication of I/O delay • Aggregated per endpoint • The response can be huge (memory issue) • If one of the interfaces has a configuration problem, all the query fails • Can’t use keys (solved in SVN recently) • Parallel threads • One query per interface • Many threads stress services (!) • The gain is not substantial • Aggregated per endpoint • Same issues as for sequential approach

  4. SetupData response with keys Request Response

  5. Aggregated request (to ISTF-Java MA) Metadata Key Request SetupDataRequest for all interfaces ~40 sec

  6. Parallel requests (to ISTF-Java MA) 79 Setup data requests ~ 2 min Metadata Key Request Services increase the response time and can even crash

  7. Semi - aggregated request (to ISTF-Java MA) Metadata Key Request 3 SetupDataRequest for <=32 interfaces each ~50 sec 2 SetupDataRequest for <=64 interfaces each ~60 sec

  8. Semi - aggregated request (to ISTF, SWITCH, SEEREN-Java MA) Metadata Key Request ISTF (1 request) SWITCH (3 request) SEEREN (1request)

  9. RRD issues • RRD can’t be queried with arbitrary resolutions • The MA service doesn’t have information how RRD was configured • If RRD is configured with high resolution everywhere, the data received by the client will be huge • e.g. 60 sec resolution for the last year = 525600 points, ~ 50 bytes per point = 25 megabytes! • <nmwg:datum timeValue="1158377400" value="0.1234" /> • Memory issues • Axis • Visualization

  10. Possible solutions • Define reasonable defaults for RRD file's structure and mandate that perfSONAR services should support only these well known defaults • easy, but not user friendly; • the defaults already differ between CRICKET, MRTG and CACTI • Implement support for “rrdtool info” in RRD MA and specify queries/responses for exchange of information between RRD MA and clients about available averages/time periods • adds complexity both on the service and client side • Mandate that clients should always retrieve the finest available resolution and perform aggregation only when required - either upon user demand or because of system limitations • wastes bandwidth and CPU cycles; • Mandate that RRD MAs should calculate the requested averages on the fly if a finer than requested resolution is returned by rrdtool • transparent for clients, but would put a heavy burden on the services

  11. Thank you for your attention! Any questions?

More Related