Overview
Performance is vital in the world of stock trading, you can easily lose hundreds of thousands of dollars if the trading platform you’re using routes orders to the stock exchanges too slowly and you miss the your target price.
The order management system I work on uses IRC as the messaging middle ware– a message is sent to a channel and another process reads and processes the message. This gives us great flexibility, letting us write the user interface in .NET and the back-end server code in whichever language we choose and it also allows us to scale the system by moving processes to different machines.
But this setup has problems, if a message is missed by a process, there’s no easy to way to retrieve it and recent benchmarking showed that the latency of the messaging system spikes, unpredictably to 300 ms or more. Initially IRC made sense but the requirements have grown and it’s clear a more robust solution which provides greater reliability, performance and scalability is needed.
AMQP
The Advanced Message Queuing Protocol (AMQP) is an open standard, vendor neutral binary protocol for messaging middleware. AMQP features: messages, queuing and routing and it was designed by the financial industry to replace existing proprietary message queues. It seems to be the Promised Land—the perfect replacement for IRC.
After a quick evaluation of messaging brokers, the best candidates appear to be RabbitMQ and Apache Qpid. Both support AMQP, seem to have low latency and have vendor support—Qpid in the form of RedHat MRG. While both seem to be faster than IRC, I needed to be sure.
AMQP is more complicated than IRC and replacing the current messaging system won’t be easy. I wanted to create a benchmark that simulates the load we see in a production environment, but before I could create the test, I need to better understand what AMQP provides and the terminology it uses.
AMQP Features
Messages are glorified strings which are published to an exchange. They consist of a header and a content body, while headers have several properties; you only need to know one to get started: the routing-key, a field used by exchanges to determine which queue the message will be routed to.
Queues are where your messages wait until they are consumed. Queues can be configured to let messages die if a consumer is not available, queues along with exchanges can be made durable. Message can persists if the queue and the exchange are marked as durable and the message’s delivery mode is set to persistent.
Exchanges the help the broker decide which queue to route your message to. While they’re slated for removal in AMQP 1.0, but they’re still important and difficult to ignore– there are four types of exchanges: Fanout, Direct, Topic and Header.
- Direct exchange: Use routing keys, messages sent to a direct exchange are routed to exchanges where the routing key matches exactly.
- Topic exchange: A hierarchical exchange which also uses routing keys, routing keys are matched against a pattern, the hierarchy is established by separating keywords with the dot symbol.
- Fanout Exchange: A 1:N exchange, any message sent to an exchange is sent to all queues bound to that exchange.
A Channel is to AMQP what session is to HTTP, I’m not sure if that’s very accurate– all communication over a channel is stateful, and each instance of your program will have at least one channel.
Conclusion
There’s a lot to digest, I spent the better part of the day reading RabbitMQ’s .NET API Guide. In part two of this series I’ll walkthrough C# client and benchmark RabbitMQ. As always, your feedback and comments are appreciated.
ASP.NET MVC has always bothered me; even now I’m not sure exactly what bothers me, but it’s enough to make me question using .NET to develop web applications. No longer working at a .NET shop and having escaped from the realty distortion field I’ve pushed myself to revaluate languages and frameworks which I had ignored in the past.
Django, a Python framework for creating web applications which is loosely based on MVC architecture. In the two-three-odd hours I spent with Instant Django I realized that I’ve never had a compelling reason to develop web applications in ASP.NET and “I know C#” is not a not a reason to learn ASP.NET MVC.
Almost Immediately I noticed I wasn’t fighting the language, interpreted languages are much more compatible with the web development story, web application development with static languages is time consuming and tiresome. Within the first hour I was in love with the documentation, not that I needed it *too* much, the different components fit well together and that’s fairly significant friction point for me. To do web development with ASP.NET MVC properly you need some sort of ORM, usually NHibernate, a dependency injection framework and 3rd party validators—I’m left wondering, isn’t this getting too complicated, where is my productivity?
By the second hour I’m sold, my gut tells me that Django is good and my brain is agreeing with my gut on this one.
Source control is the bedrock of your development effort, it contains the history of your entire project and it’s too important to trust it to VSS. Visual Source Safe is a horrible source control system and i keeps you from being productive.
Teams using VSS love to use exclusive locks on source files, this only creates contention for files and kills the team’s productivity. Even worse, VSS’s doesn’t support branching which makes refactoring your code doubly difficult, all your changes have to be made offline and manually merged into the “trunk,” and only is VSS insanely slow it has no concept of transactions, if a bug fix required you to change and check-in multiple files at once, there’s no way to figure out which files were checked-in together using VSS’s history feature.
SVN is a much better, free alternative to VSS, which supports many features that you expect from a modern source control system: branching and merging and transactions and atomic commits.
If you think your project’s history is stuck in VSS, it’s not, there’s a great migration tool called vss2svn which lets you migrate your entire VSS repository along with the project history to SVN.
You’ll need to download and setup SVN server and create a repository and users for your projects first, I recommend using VisualSVN Server if you’re on Windows. What follows is a painfully long migration, but it’s well worth it in the end.
- Download and extract vss2svn to a hard drive which has plenty of space, as a general rule, you should have enough space to hold three copies of your VSS repository;
- After making sure that your repository does not have any files checked out, take your VSS repository offline by disabling all access to it, then create a backup of your VSS directory; at this time, you should also delete/destroy any files/projects you do not wish to migrate to svn.
- Run the analyze command on your VSS repository, you’ll have to run analyze several times if the analyze utility encounter errors in your repository– this is very time consuming and but an important step.
- Now you’re ready to run the migration utility from the command prompt. You’ll need to use the following command: vss2svn.exe –vssdir <dir> where <dir> is the directory which contains the scrsafe.ini file. vss2svn.exe will generate a svn dump file which you’ll later import into your svn repository;
- finally, import the dump file generated by vss2svn by using the following command on the machien where your svn repository resides: svnadmin load /path/to/repository < dumpfile.txt
