Sophis Risque: stress-tests using SEC events
Jul
29
Written by:
7/29/2014 5:04 PM
One client, a fund asset manager, asked me recently if I didn't have any tool that permits to make non-regression tests or performance tests when migrating from a version of Risque or Value to another one.
The goal of this post is to provide such a tool, when doing non-regression performance tests. This is based on the fact that the SEC server linked to the Oracle server is the bottleneck of the Sophis architecture.
When each Sophis Risque/Value client receives a notification, in most cases on versions <5.2 and in some cases after on Sophis internal messages, it does a query on the Oracle server. On user events, it depends how it was developed.
Logging the SEC events in a file during one day and reading it after and sending events will permit to simulate the behavior of the Sophis platform. Logging time elapse between 2 events permits to use a compression factor when sending the events again.
The sample described below, a C++ batch linked to the Sophis API, is based on a version of Sophis Risque 5.3.7 or Value equivalent. Most of SEC events architecture was reviewed after the 6.0, but on internal Sophis events only. If the Misys client has implemented user messages in order to notify changes on its own data, the below description will work, but for the user messages only. It is developed in C++ but could be easily adapted for the .Net toolkit.
SEC events are composed of 2 types of messages: the internal ones (named PAPI) and the user ones (USER). The definition of this type of messages is available in the header sphevents.h fo the toolkit:
const long classAPIPacket = 'PAPI';
const long classUserEvent = 'USER';
The PAPI messages are handled by any callback overriding CSRApi::HandleEvent, the user ones by any callback overriding CSRGlobalFunctions::HandleEvent. In order to trace both types of events, the tool should then implement these 2 callbacks. In fact, on CSRApi we will impement the log. On CSRGlobalFunctions::HandleEvent, since CSRApi::HandleEvent does nothing, we just have to have to call CSRApi::gAPI->HandleEvent.
Sophis events have a hierarchical composition. It is composed of tags and values, and, on tags of type 'PCKT', the value correspond to another event. The best format to dump such messages is then the XML one. On the 5.3.7 version, I didn't find any existing .xsd that corresponds to the description of such a class. This is the one that I've created in order to use it for the dump:
xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0" targetNamespace="itquants" xmlns="itquants"> <xs:complexType name="event">
<xs:sequence>
<xs:element name="tag" type="tag" minOccurs="1" maxOccurs="unbounded">
xs:element>
xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
<xs:attribute name="time" type="xs:double" use="optional" />
xs:complexType>
<xs:complexType name="tag">
<xs:sequence>
<xs:element name="value" minOccurs="0" maxOccurs="1">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="event" type="event" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="content" type="xs:string" minOccurs="0" maxOccurs="1"/>
xs:sequence>
<xs:attribute name="type" type="xs:string" use="required" />
xs:complexType>
xs:element>
xs:sequence>
<xs:attribute name="id" type="xs:string" use="required" />
xs:complexType>
<xs:element name="events">
<xs:complexType>
<xs:sequence>
<xs:element name="event" type="event" minOccurs="0" maxOccurs="unbounded">
For reading the XML file in C++, I will use XSD, provided by codesynthesis. I've tried to use the last version, the 4.0 one, but, unfortunately, it has a dependency to the Xerces library v3.0 and the version of Sophis Risque I'm using is linked to Xerces 2.8. XSD v3.3, which is compatible with a Xerces v2.8, was thus used. The only problem with this version is that mixing sequences with values does not work and was introduced in the later version. That's why I've added a content tag. At first, I'd added an attribute, which is faster to to parse, but some values contain text with xml tag (like "S&P" for example...). Using CDATA in an attribute is not possible, and instead of converting the string in a XML format, I prefer to use the "content" markup...
When launching the batch, there are two modes: one as writer, the other one as reader:
- The first mode (writer) is to be used to log SEC events during the day. There is no need to load specific toolkit dll's, since it is using only pure Sophis objects for reading. Moreover, it is recommended to not load specific toolkit dll's, since it is using the CSRGlobalFunctions overriding, which should be unique. Other parameters can be configured: the elapse time between 2 calls to CSRApi::ProcessEvents (timeout), and how many seconds the batch should log the events (by default almost one day). The verbosity permits to log only some types of message.
- The second mode (reader) should be used once the log file is generated. It will read it, generate CSREvent objects, and send them to the SEC server. It accepts a compression parameter, which corresponds to the fact that we can send events faster (>1) or slower (<1). A compression factor equal to 0 will indicate that we will try to send events without timeout.
In both modes, the user can interrupt the treatment by using the Ctrl+C keys.
Finally, to launch the SEC logger in write mode, the following command can also be used:
ITQLogger.exe --mode writer --file_name "c:\temp\sec_dump.xml"
To read it and to stress the Sophis platform:
ITQLogger.exe --mode reader --file_name "c:\temp\sec_dump.xml" --compression 0
Later enhancements could be:
- log the events in a database different from the Sophis one. OTL could be used to connect to this other database, one record per event, with the generation time logged in order to get statistics easily using Oracle queries.
- adding a console to visualize the number of events/s (in real time or not)
A good sample for stress-testing the platform is then:
- launching several Sophis clients
- log the SQL queries using a tool like Toad SQL Tracker
- reading a production one day file on UAT D-1 database.
The code provided is the following one: ITQLogger.zip