Hardware Qualification Tests for Reuters Market Data System Infrastructure

Transcription

1 for Reuters Market Data System Infrastructure Performed by Amjad Khan, Sun Microsystems working with Reuters at Oak Brook on 05/25/2005 Purpose Qualification tests were performed to verify that the following RMDS infrastructure components can be run successfully on the hardware platform and specific OS specified below: Market Data Hub (MDH) Source Distributor (mdh5.0.1.l2.infra.solaris.tis.rrg) TIC-RMDS Edition (RTIC) (rtic l2.solaris.tis.rrg) Point-to-Point Server (P2PS) LAN Configuration (p2ps5.0.1.e4.solaris.tis) P2PS/POP Cascading Configuration (p2ps5.0.1.e4.solaris.tis) Using tools provided by Reuters to generate simulated data, the tests measured maximum throughput for market data updates. Where applicable, tests were performed with each of the transport options for the MDH backbone - RRCP versus TIBCO Rendezvous and with only version of the RMDS software. Test Environment Platform Details: Sun Fire V240, Dual 1.5GHz UltraSPARC IIIi, and 2GB RAM Operating System: Solaris 10 SPARC (GA version) Network Switch: Extreme Summit Gigabit Switch 5i Summary of Test Results w/baseline Configuration Config Options RRCP; cache RRCP; cache enabled cache Max update 97,000 There were no backbone errors or packets lost in any of these test. 67, ,000 68,000 Page 1 of 5

2 TIC-RMDS Edition (RTIC) RTIC RTIC Config Options Max update RRCP 65,000 There were no backbone errors or packets lost in any of these test. Rendezvous 59,000 59,000 when two RVDs used. 58,000 when one RVD used. P2PS/LAN Config Options enabled cache Mounts: Commonality Max update no fan-out 152,000 There were no backbone errors or packets lost in any of these test. *p2ps*timedwrites was set to False no fan-out 84,000 *p2ps*timedwrites was set to False no fan-out 135,000 *p2ps*timedwrites was set to False no fan-out 80,000 *p2ps*timedwrites was set to False consumer 50/50 1 producer 50/ ,650 *p2ps*timedwrites was set to True and *p2ps*flushinterval was set to 20 51,510 *p2ps*timedwrites was set to False and *p2ps*flushinterval was set to 0 4,900 *p2ps*timedwrites was set to True and *p2ps*flushinterval was set to 20 4,500 *p2ps*timedwrites was set to False and *p2ps*flushinterval was set to 0 Note: For the fan-out tests, two instances of snkmnttest, each making 50 mounts was run on two different boxes. Cascading P2PS (P2PS/POP) Config Options Mounts: Commonality Max update no fan-out 80,000 *p2ps*timedwrites was set to False 11 See Test Methodology section for explanation of consumer 50/ See Test Methodology section for explanation of producer 50/50. Page 2 of 5

3 consumer 50/50 35,350 *p2ps*timedwrites was set to True and *p2ps*flushinterval was set to 20 19,190 *p2ps*timedwrites was set to False and *p2ps*flushinterval was set to 0 producer 50/50 4,400 *p2ps*timedwrites was set to True and *p2ps*flushinterval was set to 20 3,650 *p2ps*timedwrites was set to False and *p2ps*flushinterval was set to 0 Baseline Configuration These tests were performed using the following baseline configuration. Default values for configuration parameters were used except where other values are indicated below. Operating System UDP send/receive buffers are by default set to 2 Mbytes on Solaris 10 TIBCO Rendezvous RRCP Rendezvous reliability = 3 *RRCP*userQLimit : *RRCP*pktPoolLimitHigh : *RRCP*pktPoolLimitLow : *RRCP*udpRecvBufSize : 2048 *RRCP*udpSendBufSize : 2048 *RRCP*maxPktPoolSize : Default values for all *src_dist parameters. RTIC RV3_FORCE_DISTRIBUTE TRUE; SUBSC_DECAY_TIME ; P2PS/LAN and P2PS/Host P2PS/POP *p2ps*guaranteedoutputbuffers: 400 *p2ps*maxoutputbufers: 600 *p2ps*sslmsgpacking: True *p2ps*minimumopenwindow: 256 *p2ps*maxmount: 200 *p2ps*guaranteedoutputbuffers: 400 *p2ps*maxoutputbufers: 600 Page 3 of 5

4 *p2ps*sslmsgpacking: True *p2ps*maxmount: 200 Test Methodology A data simulator is used to send updates at a specified rate to the Source Distributor being tested. The updates are sent to a sink application via a P2PS. The update rate is assumed to be sustainable by the Source Distributor if the average number of updates received by the sink application is equal to the specified update rate from the data simulator with less than 0.1% difference. Retransmissions on the MDH backbone should be either zero or negligible as noted in the test results. RTIC A data simulator is used to send updates at a specified rate to a Source Distributor which forwards them to the RTIC being tested. The RTIC is configured to send out all messages it receives (RV3_FORCE_DISTRIBUTE is set to True) so a consuming application is not needed for this test. The update rate is assumed to be sustainable by the RTIC if the average number of updates output by the RTIC is equal to the specified update rate from the data simulator with less than 0.1% difference. Retransmissions on the MDH backbone should be either zero or negligible as noted in the test results. P2PS/LAN To avoid the Source Distributor becoming the limiting factor when testing the P2PS in its LAN configuration, at least two source servers (data simulator/source Distributor) are configured to provide updates to the P2PS. Multiple sink applications connected to the P2PS receive the data. The update rate is assumed to be sustainable by the P2PS if the average number of updates received by the sink applications is equal to the specified update rate from the data simulators with less than 0.1% difference. Retransmissions on the MDH backbone should be either zero or negligible as noted in the test results. For fan-out test details, see the discussion in the P2PS/POP section. P2PS/POP A data simulator is used to send updates at a specified rate to a Source Distributor which forwards them to a P2PS in Host configuration. Cascaded from the P2PS/Host is the P2PS/POP test machine. Multiple sink applications connected to the P2PS/POP receive the data. Since commonality of RICs being viewed affects performance, three types of update throughput test are conducted: (1) No fan-out; i.e. each sink application requests a unique set of RICs. (2) Producer 50/50; i.e. from viewpoint of Source Distributor, 50% of RICs are common. In this test 50% of incoming updates to P2PS/POP must be fanned out to every mount (consumer). Page 4 of 5

5 Therefore, for 100 incoming messages (50 common/50 unique) 5050 outgoing messages. (3) Consumer 50/50; i.e. from viewpoint of end user, 50% of RICS being viewed by one consumer (mount) are common to all users. In this test, if 10 mounts each have 1 common RIC and 1 unique RIC, then total RICs = 1 + (10x1)=11. Therefore, for 101 incoming messages (100 unique/1 common) 200 outgoing messages. For more information DISCLAIMER: The test results contained in this report are made available for informational purposes only. There is no guarantee of similar performance results. All information contained herein is provided on an AS-IS BASIS WITHOUT WARRANTY OF ANY KIND. Obtaining repeatable, measurable performance results requires a controlled environment with specific hardware, software, network, and configuration in an isolated system. Adjusting any single element may yield different results. Additionally, test results at the component level may not be indicative of system level performance, or vice versa. Reuters provided recommmended procedures and tools for conducting these tests so that different vendors could produce results based on similar configurations of RMDS. Reuters takes no responsibility for the resutls reported by each hardware vendor. Page 5 of 5