C, ACE C++, Blob Streaming, and Orbix over ATM

Transcription

1 The Performance of Object-Oriented Components for High-speed Network Programming Douglas C. Schmidt Washington University, St. Louis Introduction æ Distributed object computing èdocè frameworks are well-suited for certain communication requirements and certain network environments í e.g., requestèresponse or oneway messaging over low-speed Ethernet or Token Ring æ However, current DOC implementations exhibit high overhead for other types of requirements and environments í e.g., bandwidth-intensive and delay-sensitive streaming applications over high-speed ATM or FDDI 1 2 Outline æ Outline communication requirements of distributed medical imaging domain æ Compare performance of several network programming mechanisms: í Sockets í ACE C++ wrappers Distributed Medical Imaging in Project Spectrum í CORBA èorbixè í Blob Streaming æ Outline Blob Streaming Architecture and Related Patterns æ Evaluation and Recommendations 3 4

2 Distributed Objects in Medical Imaging Systems DOC View of Project Spectrum æ Blob Servers have the following responsibilities and requirements: * Eæciently storeèretrieve large medical images èblobsè * Respond to queries from Blob Locators * Manage short-term and long-term blob persistence 5 6 Motivation for Distributed Object Computing CORBA Architecture æ Simplify application development and interworking, e.g., í CORBA provides higher level integration than traditional ëuntyped TCP bytestreams" í ACE encapsulates lower-level networking and concurrency systems programming interfaces æ Provide a foundation for higher-level application collaboration í e.g., Windows OLE and the OMG Common Object Service Speciæcation ècossè æ Beneæts for distributed programming similar to OO languages for non-distributed programming í e.g., encapsulation, interface inheritance, and objectbased exception handling 7 8

3 CORBA Components æ The CORBA speciæcation is comprised of several parts: 1. An Object Request Broker èorbè 2. An Interface Deænition Language èidlè 3. A Static Invocation Interface èsiiè 4. A Dynamic Invocation Interface èdiiè 5. A Dynamic Skeleton Interface èdsiè ACE Architecture æ Other documents from OMG describe common object services built upon CORBA í e.g., CORBAServices! Event services, Name services, Lifecycle services æ A set of C++ wrappers, class categories, and frameworks based on design patterns 9 10 Motivation for CORBA and ACE on Project Spectrum æ Two crucial issues for overall communication infrastructure æexibility and performance æ Flexibility motivates the use of a distributed object computing framework like CORBA to transport many formats of data í e.g., HL7, DICOM, Blobs, domain objects, etc. æ Performance requires we transport this data as quickly as the current technology allows Key Research Question Can CORBA and ACE be used to transfer medical images eæciently over high-speed networks? æ Our goal was to determine this empirically before adopting distributed object computing wholesale 11 12

4 Performance Experiments NetworkèHost Environment æ Enhanced version of TTCP í TTCP measures end-to-end bulk data transfer with ackknowledgements í Enhanced version tests C, ACE C++ wrappers, and CORBA, and Blob Streaming æ Parameters varied í 100 Mbytes of data transferred in various chunk sizes í Socket queues were 8k èdefaultè and 64k èmaximumè í Network was 155 Mbps ATM æ Compiler was SunC using highest optimization level TTCP Conæguration for C and ACE C++ Wrappers TTCP Conæguration for CORBA Implementation 15 16

5 TTCP Conæguration for Blob Streaming Performance over ATM 65 C, ACE C++, Blob Streaming, and Orbix over ATM Mbits/sec C/64k window ACE/64k window Blob Streaming/64k window Orbix/64k window C/8k window ACE/8k window Blob Streaming/8k window Orbix/8k window Blob chunk size in megabytes Primary Sources of Overhead æ Data copying æ Demultiplexing æ Memory allocation æ Presentation layer formatting High-Cost Functions æ C and ACE C++ Tests í Transferring 64 Mbytes with 1 Mbyte buæers Test ètime ècalls Name C sockets write èsenderè read C sockets ,085 read èreceiverè getmsg ACE C++ wrapper write èsenderè read ACE C++ wrapper ,984 read èreceiverè getmsg 19 20

6 High-Cost Functions ècont'dè æ Orbix String and Sequence Test ètime ècalls Name Orbix Sequence write èsenderè read 7.3 1,108 memcpy Orbix Sequence ,846 read èreceiverè ,064 memcpy Orbix String write èsenderè read ,315 strlen 6.0 1,108 memcpy High-Cost Functions ècont'dè æ Blob Streaming Test ètime ècalls Name BlobStreaming write èsenderè read 1.3 2,055 memcpy BlobStreaming ,546 read èreceiverè ,734 memcpy write Orbix String ,443 read èreceiverè ,142 strlen ,064 memcpy Overview of Blob Streaming Blob Streaming System Architecture æ Blob Streaming provides developers with a uniform interface for operations on multiple types of Binary Large OBjects èblobsè æ Two primary goals 1. Improved abstraction í Shield developers from knowledge of blob location èe.g., memory vs. ëlocal" æles vs. remote networkè 2. Maximize performance í Transport blobs as eæciently as current technology allows 23 24

7 Blob Streaming Architecture æ Blob Streaming components allow transparent use of resources through uniform blob interfaces æ Blob Streaming support the following: í Blob location. e.g., smart caches to decouple transfers from location algorithms í Blob routing. e.g., context based routing í Source and destination independent Blob transport, e.g.,. Store and retrieve from remote or local databases. Abstract operations like readsèwrites may use local æle readsèwrites, or remote readsèwrites via sockets 25 Blob Streaming Architecture Design Goals æ Goal: decouple application from OS platform í e.g., applications can be shielded from fact that current version is implemented for UNIX. Thus, can port Blob Streaming to Windows NT or OSè2 without changing applications í Platform speciæc operations hidden behind abstract interfaces. e.g., WIN32 WaitForMultipleObjects and UNIX select æ Advantages í Portability and extensibility 26 Blob Streaming Architecture Design Goals ècont'dè Design Patterns in Blob Streaming æ Goal: application independence from transport mechanism í Switch transports at any stage in the development without aæecting application code. Presently using CORBA and TCPèIP as transport mechanisms æ However, none of these mechanisms are exposed to programmers æ e.g., can use Network OLE. As transport technology improves, Blob Streaming can change without aæecting applications æ e.g., ëdirect ATM" æ Advantages í Portability, extensibility, and performance tuning 27 æ Blob Streaming is based upon a system of design patterns 28

8 æ Intent The Reactor Pattern í An object behavioral pattern that decouples event demultiplexing and event handler dispatching from the services performed in response to events æ This pattern resolves the following forces for event-driven software: í How to demultiplex multiple types of events from multiple sources of events eæciently within a single thread of control Structure of the Reactor Pattern í How to extend application behavior without requiring changes to the event dispatching framework æ Participants in the Reactor pattern Collaboration in the Reactor Pattern Using the Reactor for Blob Streaming 31 32

9 Structure of the Active Object Pattern in ACE æ Intent The Active Object Pattern í Decouples method execution from method invocation and simpliæes synchronized access to shared resources by concurrent threads æ This pattern resolves the following forces for concurrent communication software: í How to allow blocking operations èsuch as read and writeè to execute concurrently í How to simplify concurrent access to shared state Collaboration in ACE Active Objects Using the Active Object Pattern for Blob Streaming 35 36

10 Half-SyncèHalf-Async Pattern Structure of the Half-SyncèHalf-Async Pattern æ Intent í An architectural pattern that decouples synchronous IèO from asynchronous IèO in a system to simplify programming eæort without degrading execution eæciency æ This pattern resolves the following forces for concurrent communication systems: í How to simplify programming for higher-level communication tasks. These are performed synchronously èvia Active Objectsè í How to ensure eæcient lower-level IèO communication tasks. These are performed asynchronously èvia the Reactorè Collaborations in the Half-SyncèHalf-Async Pattern æ This illustrates input processing èoutput processing is similarè Using the Half-SyncèHalf-Async Pattern for Blob Streaming 40 41

11 The Acceptor Pattern Structure of the Acceptor Pattern æ Intent í Decouple the passive initialization of a service from the tasks performed once the service is initialized æ This pattern resolves the following forces for network servers using interfaces like sockets or TLI: 1. How to reuse passive connection establishment code for each new service 2. How to make the connection establishment code portable across platforms that may contain sockets but not TLI, or vice versa 3. How to ensure that a passive-mode descriptor is not accidentally used to read or write data 4. How to enable æexible policies for creation, connection establishent, and concurrency Collaboration in the Acceptor Pattern Using the Acceptor Pattern for Blob Streaming æ Acceptor factory creates, connects, and activates a Svc Handler 44 45

12 Evaluation and Recommendations æ Understand communication requirements and networkèhost environments æ Measure performance empirically before adopting a communication model í Low-speed networks often hide performance overhead æ Insist CORBA implementors provide hooks to manipulate options í e.g., setting socket queue size with ORBeline was hard æ Increase size of socket queues to largest value supported by OS æ Tune the size of the transmitted data buæers to match MTU of the network 46 Evaluation and Recommendations ècont'dè æ Use IDL sequences rather than IDL strings to avoid unnecessary data access èi.e. strlenè æ Use writeèread rather than sendèrecv on SVR4 platforms æ Long-term solution: í Optimize DOC frameworks í Add streaming support to CORBA speciæcation æ Near-term solution for CORBA overhead on high-speed networks: í e.g., Blob Streaming integrates CORBA with ACE 47 Optimizations Obtaining ACE æ The ADAPTIVE Communication Environment èaceè is an OO toolkit designed according to key network programming patterns æ All source code for ACE is freely available í Anonymously ftp to wuarchive.wustl.edu í Transfer the æles èlanguagesèc++èaceè*.gz and gnuèace-documentationè*.gz æ To be eæective for use with performancecritical applications over high-speed networks, CORBA implementations must be optimized æ Mailing list í ace-users@cs.wustl.edu í ace-users-request@cs.wustl.edu æ WWW URL í