Geeks With Blogs
On the Ledge The general evolution (and occasional regression) of a .NET developer

My first actual project with regard to our systems was to write a new Proxy.  I'm going to have to be a little ambiguous, once again, because I don't want to give away any proprietary or quasi-proprietary information.

One of our major systems serves as a sort of brokerage for Flumphs (I'm going to compensate for being ambiguous by being completely ridiculous about it).  Flumph providers constantly feed our system with information about new Flumphs.  Flumph-consumers have given us their criteria they use to buy and sell Flumphs, so our system facilitates the automated sale/purchase of Flumphs to different consumers.

So, a Flumph provider sends information about one into our system.  Our system does some routine checks.  Is this a valid Flumph?  Do we already have this Flumph in our system?  Then, we begin to examine the rules we have for different clients.  What additional information can we get from third parties about this Flumph?  Does anyone want a Flumph like this?  If not, should we buy the Flumph ourselves in order to sell it, later?  After all these questions have been answered, automatically, the system responds to the Flumph provider with a buy, a rejection with a reason, or a notice that we're not buying because the system is down for maintenance (usually during a release).

This process is happening at the rate of several Flumphs per second, and the majority of providers want their response in 18 seconds or less.  The typical response comes in around one second.

We had started to run into an anomaly where this operation was timing out in blocks.  The time outs seemed to have nothing to do with volume.  In fact, the provider with the smallest volume was the first to exhibit the behavior.  Different hypotheses were tested, but no one thing seemed to hold the explanation.  We assumed that it must be a few, different factors working together as opposed to one, big issue.

My piece of the puzzle was to rewrite the Proxy.  The Proxy sits between our system and Flumph providers.  Its sole mission in life is to receive HTTP requests (these are incoming XML data) and forward them to the system, then send the response (also XML data) back to them.  It seems simple, right?  Well, until you realize that not every client uses the same XML format, nor do they wish to receive the same XML format.

My mission was to make the Proxy leaner and faster, not only by tightening the code and processes, but also by making as much asynchronous as I could, including logging.  I also needed to add the following, new functionality:

  • The old Proxy used log4net to write the request info and the response info to a database.  I had to add logging events to track the time between when the request was received and when the request was forwarded as well as the time between a response was received and the response was forwarded.  I also had to log any timeouts or exceptions and display them with different severities in log files.
  • The timeout cap was the same for all clients.  I had to make the timeout settable for each client.
  • If a timeout occurred, I had to send an XML rejection response to the client as opposed to the system actually timing out and throwing that exception.  This way, the client's system can just keep on chugging without having to process a timeout.
  • Cache various client and system settings that would be refreshed every hour.
  • Implement a templating system to allow different XML formats to be sent to different clients.

In doing this project, I learned a lot.  It was my first time really working with threads and the performance benefits they can bring to a system if you do them right.  I learned a lot about IIS configuration and multiple processors.  I learned a lot about the guts of an HTTP request and response.  These were all new worlds to me, not just because I hadn't really delved into those areas, but because the problem domain wasn't a business problem, per se, but a framework problem.  My classes and objects all revolved around HTTP operations as opposed to business operations.

It was a level of abstraction I wasn't used to working with, but I learned a lot and released a really good Proxy.  In the posts to come, I'll spin out how I handled the different things outlined above and what I learned that I could carry with me to other projects.

Posted on Tuesday, September 22, 2009 9:51 AM Architecture , Proxy | Back to top

Comments on this post: Proxy Problems

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © ledge | Powered by: