the impact of web service integration on grid performance
play

The Impact of Web Service Integration on Grid Performance Franois - PowerPoint PPT Presentation

The Impact of Web Service Integration on Grid Performance Franois Taani Matti Hiltunen & Rick Schlichting Lancaster University AT&T Labs - Research HPDC-14 , The 14th IEEE International Symposium on High Performance Distributed


  1. The Impact of Web Service Integration on Grid Performance François Taïani Matti Hiltunen & Rick Schlichting Lancaster University AT&T Labs - Research HPDC-14 , The 14th IEEE International Symposium on High Performance Distributed Computing , Research Triangle Park, NC, USA, July 24-27, 2005

  2. Context & Motivation  New Globus version (3.9.x / 4.0.x): convergence  Grid Computing: federating resources (OGSA)  Web Services: integrating services (WSRF)  Web Services and their associated technologies (SOAP, XML, WSDL) are reputed inefficient  What is the performance impact on Globus?  Globus has grown into a large, complex, collaborative middleware (IBM, Apache,...)  How to extract meaningful profiling data?  How to profile a complex piece of software?  What does it tell us about Globus ? 2/29

  3. Chosen Approach 2 steps:  Black box profiling: minimal interferences. Coarse results. 1. Sample based profiling: less accurate but more detailed. 2. We focused on the connectivity of the WSRF  implementation of GT4-Java:  Low level “ plumbing ”. No high level service involved  Motivation: profile the founding bricks of the Globus platform Experimental set-up:   Standalone SMP server running 4 Intel Xeon @ 1.6GHz  No network cost involved!  Avoids context switching overhead!  Globus 3.9.4 used (last GT4 alpha release, released Dec.04) 3/29

  4. Outline  Introduction: Motivation and Approach  Black Box Profiling: Set-Up and Results  Sample Based Profiling: Approach and Results  Conclusion 4/29

  5. Outline  Introduction: Motivation and Approach  Black Box Profiling: Set-Up and Results  Sample Based Profiling: Approach and Results  Conclusion 5/29

  6. Black-Box Profiling: Approach  Black Box Approach: Measure externally visible latencies  Many different situations to be considered! create subscribe add 3 client container notify 3 averaging × 5 destroy clock instrumentation × 5 × 5 influence of resource init × 50 influence of client init (10 000 invocations) influence of container init 6/29

  7. Resource Set-Up create subscribe client cont. × 5 × 5 7/29

  8. Resource Set-Up Container init Client init overhead overhead (~ 8.2s !) (~ 24.8s !) 8/29

  9. Resource Set-Up Container init Client init overhead overhead (~ 8.2s !) (~ 24.8s !) High lazy initialization costs! (> 30s!) Stabilized latency remains high (380ms) 9/29

  10. First Notification 1 st notify client cont. × 5 × 5 10/29

  11. First Notification Client init Container init overhead overhead (~ 1.4s !) (~430ms) Stabilized latency (~ 1.1s! ) 11/29

  12. Second Notification 2 nd notify client cont. × 5 × 5 Resource init overhead (~ 930ms !) Stabilized latency 1 st notification (~1.1s) 12/29

  13. Second Notification Lazy initialization everywhere 2 nd notify client cont. Stabilized request latency still high (170ms) × 5 × 5 Resource init overhead (~ 930ms !) Stabilized latency 1 st notification (~1.1s) 13/29

  14. Outline  Introduction: Motivation and Approach  Black Box Profiling: Set-Up and Results  Sample Based Profiling: Approach and Results  Conclusion 14/29

  15. Sample Based Profiling: Introduction  Goal: relate observed latencies to Globus internal structure  Profiling data obtained through sampling (SUN hprof basic profiler)  JVM periodically stopped . Stack of active thread is captured .  Result : A set of weighted stack traces . Weight = measures how often the stack was observed.  Visualization : Set of weight stacks = multi-dimensional object  Time (represented by weights)  Threads : each trace belongs to a thread  Control flow (represented by stacks, reflects use relationships)  Code Structure (package organization, class hierarchy, etc. ) 15/29

  16. Program visualization  Problem studied for quite a long time now.  Projection (aggregation / collapsing) required  Many possibility.  Our goal: related profiling to software structure  Our choice: package aggregation + stack depth Growing lib 1 lib1.Wale .breath Call lib1.Mammal.inhale lib2.Lung .inhale Stack lib 2 lib2.Muscle.contract lib2.Nerve .transmit lib3.Signal.travel lib 3  Tracing calls reveals the software structure. 16/29

  17. Sample Based Profiling: Example lib1.Wale .breath lib1.Mammal.inhale lib2.Lung .inhale lib2.Muscle.contract lib2.Muscle.stop lib2.Nerve .transmit lib3.Blood .flow lib2.Nerve .transmit × 3 × 1 × 2 lib3.Signal.travel lib3.Pressure.foo lib3.Signal.travel Sampling yields a set of weighted stack traces (weight reflects time spent)  Aggregates invocations of the same library.  Chart w.r.t. position in call stack. 6 6 EXCLUSIVE INCLUSIVE 5 5 Time Units Time Units lib3 lib3 4 4 lib2 lib2 3 3 lib1 lib1 2 2 1 1 0 0 1 2 3 4 5 6 1 2 3 4 5 6 Stack Depth Stack Depth 17/29

  18. Experimental Set-Up create subscribe add 3 client container hprof notify 3 Java VM × 5 destroy × 5 profiling data 18/29

  19. Container Profiling: Results 19/29

  20. Container Profiling: Results Sharp drop at length 13 Layered structured Some very deep traces. for upper stack Look quite regular beyond depths depth 28 (recursion?) org.apache.axis predominant 20/29

  21. Container Profiling: Results Sharp drop at Busy waiting related to length 13 notification management. Outside request critical path. Layered structured Some very deep traces. for upper stack Look quite regular beyond depths depth 28 (recursion?) org.apache.axis predominant 21/29

  22. New Experimental Set-Up create subscribe add 3 client container hprof notify 3 Java VM × 5 destroy × 5 + extra granularity to observe package org.apache.axis profiling data 22/29

  23. New Results Traces of length 13 have disappeared. They were caused by the notification management. sun.reflect (reflection) org.globus.gsi (security) org.globus.wsrf This is a recursion in org.apache.wsdl.symbolTable (web services). Symbol management issue? 23/29

  24. Profiling Breakdown  Abstracts away low level packages (java.*, etc.)  Sample breakdown among “higher level” packages: Package Name Samples %  org.apache.axis.wsdl 231 21%  org.apache.axis.encoding 66 6%  org.apache.axis (others) 113 10%  org.globus.gsi 249 23%  org.globus.wsrf 49 4%  cryptix.provider.rsa 82 7%  org.apache.xerces 78 7%  others 237 21% 24/29

  25. Profiling Breakdown  Abstracts away low level packages (java.*, etc.)  Sample breakdown among “higher level” packages: Package Name Samples %  org.apache.axis.wsdl 231 21%  org.apache.axis.encoding 66 6%  org.apache.axis (others) 113 10%  org.globus.gsi 249 23%  org.globus.wsrf 49 4%  cryptix.provider.rsa 82 7%  org.apache.xerces 78 7%  others 237 21% Symbol management issue? 25/29

  26. Profiling Breakdown  Abstracts away low level packages (java.*, etc.)  Sample breakdown among “higher level” packages: Package Name Samples %  org.apache.axis.wsdl 231 21%  org.apache.axis.encoding 66 6%  org.apache.axis (others) 113 10%  org.globus.gsi 249 23%  org.globus.wsrf 49 4%  cryptix.provider.rsa 82 7%  org.apache.xerces 78 7%  others 237 21% SOAP + XML: 44% 26/29

  27. Profiling Breakdown  Abstracts away low level packages (java.*, etc.)  Sample breakdown among “higher level” packages: Package Name Samples %  org.apache.axis.wsdl 231 21%  org.apache.axis.encoding 66 6%  org.apache.axis (others) 113 10%  org.globus.gsi 249 23%  org.globus.wsrf 49 4%  cryptix.provider.rsa 82 7%  org.apache.xerces 78 7%  others 237 21% Security / Cryptography: 30% 27/29

  28. (Temporary) Conclusion on Globus  Globus :  Lazy optimisation : very high latency on first invocation of operations (up to 30s to set up a resource on a new container!)  Stabilized latencies still high: ~ 160ms for a round trip request (with authentication turned on)  No clear culprit. A mix of factors: WSDL, SOAP, security  Is lazy optimisation a problem ? Yes and No.  Brand new version. 3.9.4 numbers already better than 3.9.2!  Containers not supposed to be started frequently  Globus services are there to manage very long running jobs. A few seconds does not really matter.  But points at some applications for which Globus (in its present form) would be clearly ill chosen 28/29

  29. Conclusion & Outlook On Approach  Use of simple and well known profiling techniques  Visualisation was adapted to scale up to the complexity of a software like Globus  The diagrams we used don’t contain all the answers:  They can be best seen as maps to guide further steps  Different kinds of projection actually useful  Interesting complexity related problems:  Which is the best “semantically relevant” level to project profiling traces? Too low: no meaning. Too high: no details.  Can we leverage the “middleware” nature of Globus to obtain finer profiling data with the same lightweight tools? 29/29

  30. The End (Thank you) 30/29

Recommend


More recommend