Everyone,
Very soon (we're planning on tomorrow evening) we're moving to the new version of Investors Hub. Fortunately, unlike with the SI rollover years ago, we can roll back to the previous platform quickly and easily if we find that, for example, that the machines are getting overworked and not keeping up.
I often hear "If it ain't broke, don't fix it." and actually am an advocate of that philosophy, but this really does qualify for fixing. The site isn't broken in terms of being non-functional or even having bugs (at least the code on this side of the pond), but in the broader business sense, it's hobbled and this is a necessary repair.
The programming language we've been using was fine while it lasted (and the bottom line is that's what's changing most) but has not only started becoming a troublesome bottleneck that limits our traffic-handling capacity, it also presented a sizable brick wall when adding a lot of functionality we want to add to the site.
For those of you who speak binary, one of the biggest gains for us is the difference between an interpreted language and a compiled one.
For you non-binary types, if we use Favorites as an example, every time someone goes to that page (or it refreshes), the webserver has to read every single line of the hundreds of lines of code, check to see that it has the correct syntax, convert the line of code into "machine code", then do what that code tells it to do.
With the new language, Favorites is already machine code. The time-consuming steps of reading code line by line, checking for correct syntax, and converting to machine code (millions of times per day, mind you) are skipped because all of this is done one time rather than every time any user goes to the page.
This results in a fraction of the workload for the webservers and a large multiple of the number of pageviews and users the webservers can handle without slowing down. And actually should speed up page delivery for everyone, with the exception of dialup users (4.87% of our traffic) who will see a slowdown initially because of larger page sizes, but we'll later optimize the code to give it what we call "a smaller footprint".
There are also big benefits gained at the database server, as the data reader we can use for .NET is very specifically designed for our database server package, unlike the Classic ASP version which is more of a "one size fits all" data reader. This is actually an "it's nearly broke" item that the migration helps us with. The database server is currently dealing with nearly as much work as it can handle without slowing down. And why otherwise minor glitches or changes can bring it to its knees during market hours.
This migration to .NET increases the speed of the site and dramatically increases its ability to handle more traffic.
But that's not all it does. It gives us the ability to add features to the site that we simply couldn't previously.
And while we're in the middle of substantially rewriting the whole site, we're taking advantage of the ability to fix some design flaws and incorporate new features that would've required substantial rewrites to address anyway. If they were even possible in the old language.
Anyone who's been around here for any length of time knows that we're not a "change for change's sake" kind of company. We don't change what works unless we really feel we must or should, and changing to the .NET platform is a "must and should" item that's actually been pending for years but we're just now able to tackle.
And while the new site has been in Beta, Meatloaf and Dave have added lots of new features that were requested. Features we couldn't have had previously. This relative ease of adding features is a benefit we're already seeing.
Here's hoping for a successful transition!
Bob Z.
