Crunch Mode Blog - A State of Mind by Developers at D2Soft Technologies

Like us on Facebook

RSScache Even Faster!

Short story:

The last two days have been for me a crunch mode of code optimization.  Just ask any developer: optimizing an application is never fun.  But sometimes you just need to do it.  However, the feeling when you succeed is incredible, so it's well worth the try!

So now, it was time to improve the responsiveness of my RSScache service.  With more than half a million requests per day providing real-time RSS data, it's no wonder that the service could slow down when highly accessed.  Hopefully, I had a plan :)

Fear no more, RSScache is now a lot faster!  You will also see this improvement when using News Interceptor 3.  All feed requests will now be answered in incredible speed.  Great!

Long story:

Too many times I hear developers say that a hardware upgrade is the way to get speed improvements.  If that was the case, I would have changed my servers at least three times in the last two years.  But you see, I'm still running the same hardware as in October 2004.  So if your server is getting a bit slow, maybe it's your applications that need improvements.

However, optimizing your application means that you know where to look.  In my case, I have been playing with Microsoft .Net long enough to know what was the slowdown with RSScache.

I really like using Web Services, as I do in my RSScache product.  And I like that Microsoft is pushing developers to use the concept more in their applications.  The problem is that it's just not well suited for heavy-loaded applications.  That's what I found out with RSScache about a year ago, when I started to get more users accessing the service, slowing it down.

One important thing that I discovered when calling a Web Service through an ASP.Net page is that the resources are pretty limited.  By that I mean that the number of simultaneous connections you can open to the Web Service is VERY limited.  Since RSScache is getting a lot of users each seconds, I needed to improve this resource.  After reading some small notes in a hidden document of the .Net Framework, I found out that it was possible to get up to 99 concurrent connections.  However, my own tests have shown that this number can't really be reached and all I have been able to have is 25 concurrent connections.  Still pretty far from what Microsoft says.

Hopefully, I had another solution in mind.  That's what I have put up.  Since the ASP.Net is limited in the number of threads, I could not count on parsing all requests in real-time.  So I worked on some offline (asynchronous) parsing service that would actually take care of the long running feed parsing operations.  Still, this allows me to do real-time parsing of the feeds, while answering to all requests without any delays.  After some tweaking, it's finally working and now online.

The following graphic shows the number of simultaneous connections each second.  The pink line is the actual connections to the service, while the green line is the connections to the Web Service.  As you can see in the second image, the green line is a lot lower (and that's a good thing).  It proves that requests are now answered a lot faster.

Well, that's about it for optimisation for now, until next time.  Hope you could reach the end of this long technical post!