Our CEP system has a process that reads market data from Reuters RDMS and publishes the ticks to Coral8. Everything runs fine when the market data reader is running on a 32-bit development machine. However, when we put the process onto our 64-bit Windows 2003 server, the market data process steadily consumes about 85% of one core.
We use the Reuters RFA API. This involves using the 32-bit C++ DLLs that RFA provides. Our market data process is mixed-mode between managed C++ and C#, and the unmanaged Reuters DLLs.
In order to get our market data process to run on 64-bit Windows, we need to use the CORFLAGS utility that Microsoft provides. The command-line argument to do this is:
CORFLAGS OurMarketDataReader.exe /32BIT+
The process runs under WOW64, which provides 32-bit emulation under 64-bit Windows systems.
The following MSDN article gives some warnings about WOW64 and performance:
WOW64 is important because it allows you to leverage most of your existing 32-bit code when performance and scalability are not a concern...... Another thing to keep in mind about WOW64 is that it is not designed for applications that require high-performance. At the very least, the WOW64 sub-system needs to extend 32-bit arguments to 64-bits, and truncate 64-bit return values to 32-bits. In the worst case, the WOW64 sub-system will need to make a kernel call, involving not only a transition to the kernel, but also a transition from the processor's 32-bit compatibility mode to its native 64-bit mode. Applications won't be able to scale very well when run under WOW64. For those applications that you would like to leave as 32-bit, test them under WOW64. If the performance is not meeting your expectations, you'll need to look at migrating the application to 64-bit.
Our market data process handles about 3000 ticks per second over about 8000 stocks and currency pairs. In the market data process, I put in 2 caches (it's actually a ring of caches) that the process switches between. Every tick that is read from RDMS is put into a cache (ticks are last-reliable), and every second, the cache is dumped to Coral8. While the cache is being dumped, the other cache takes over.
We are hoping that Reuters will provide either native 64-bit DLLs for RFA, or a native .NET version of RFA that does not involve wrapping the existing 32-bit RFA DLLs. This is the only way that we will be able to get decent performance on 64-bit Windows.
Fortunately, Brian Theodore is now head of the Reuters API group, and we have started to engage with him.
If Reuters can't deliver this to us, then we will probably need to requisition a 32-bit server that is simply devoted to running the market data process. That means a good amount of groveling by me to the Hardware group :-( It also means sending market data over the network to Coral8, which is an additional network hop that we can afford right now, but that we might not want to incur in the future.
©2008 Marc Adler - All Rights Reserved.
All opinions here are personal, and have no relation to my employer.
Subscribe to:
Post Comments (Atom)
1 comment:
Hi Marc, this is Brian from Thomson Reuters ("Reuters" is so early this year, get with the program!)
For clarity, the latest RMDS API, RFA6 contains two interfaces. One is for legacy Marketfeed apps (anything <= RMDS6), and is only available as a 32-bit DLL. The second one is our new OMM ("Open Message Model") interface and comes as a native 64-bit C++ DLL (anything >= RMDS6)
There are two primary differences between Marketfeed and OMM:
1) OMM supports arbitrarily complex and hierarchical data models (e.g., anything you could describe in XML you can describe with OMM). Marketfeed is a simpler data model that only supports a field/value pair list, and not so suitable for anything more complex than that (e.g., yield curves, FIX messages, time series data, etc) -- would matter to you if you're publishing internal data, or consuming a native OMM source.
2) Brand new wire format and highly optimized CODEC. The compression ratio of OMM on the wire vs Marketfeed is ~2:1, therefore what used to be a ~110 byte Marketfeed market data update message is now ~55 bytes as OMM.
RMDS6.x supports seamless and transparent conversion between Marketfeed and OMM within the infrastructure, so any application using the OMM interface can easily consume Marketfeed data as OMM (called the Marketprice Domain Model).
My guy will be over next week to show you how all this works, and ensure your developers come up to speed with the 64-bit OMM interface -- all pretty straight forward.
Let me know if you have any more issues.
-Brian
Post a Comment