It's been a while since I posted anything about what's going on behind the scenes so I figured I'd post a quick update. We've been concentrating our efforts mainly on speed and uptime and have been attacking those two issues on multiple fronts.
The most common question I get asked is 'why aren't you running .NET?'. The answer is a simple one: we don't need to. Though I will qualify that with 'yet'. Many parts of CodeProject have been ported, rewritten, refactored and rewritten again in the various versions of .NET and I'm about to start work on a .NET 2.0 framework in order to test some ideas that have been swimming around in my head. However, our venerable ASP codebase works, is a known quantity, is easily maintainable and when something breaks it's very obvious what happened. We still, and probably will for some time have load issues, but rewriting code to be twice as fast is actually more expensive than buying a faster processor. And for us it always will be. Rewriting the code to be faster is, at best, a temporary solution, and sooner or later more hardware will have to be thrown in. The most important thing for us is that the system is scalable. This is what we have been addressing.
On the hardware side we increased our webserver capacity by 50%. This took a load off the other servers which, unfortunately, has quickly been filled by extra demand. I say unfortunately because after a marathon effort to move the entire server farm across town to our hosting facility, we ran out of cabinet room. So a few weeks ago we ordered our own cage and have two racks nearly full of equipment. Web servers are no longer a bottleneck since we can throw in new boxes whenever the piggy bank allows.
Bandwidth was a bottleneck that was solved when we moved to the hosting centre. Or so we thought. We've got hold of a Network Admin at Telus who spent a great deal of time working with us to find any kinks, and we found them in the oddest places. Switches which didn't operate as promised, cards in the hosting centre that had blown but not triggered alarms, a redundant network feed that turned out not to be redundant in the common sense meaning of the term, and gigabit NIC settings that should have auto-set but didn't. We know far more about network administration than any of us (except maybe Dave) ever wanted to know.
In adding more webservers we needed to ensure our load balancing solution was appropriate. We've been using the Network Load Balancing in Windows 2000 which up until now has been working fine. However, this service suffers from a few problems: it doesn't route requests based on server load; it doesn't halt requests to a server if IIS on that server has died; and for session state to be maintained (in ASP) you need to set IP affinity on. IP affinity means that once you hit a server, you are stuck to that server until you start a new session or the server recycles. And speaking of session state when a server running an ASP site goes down or is cycled, all session information is lost. Furthermore, sharing session state between ASP and ASP.NET sections of a site can be a hassle.
So we decided to kill a few birds with one stone and rewrite our session management to use SQL Server instead of IIS. This allows us to:
Turn off IP affinity. This means load balancing will be smoother
Use our firewall's load balancing system that responds to server load. Again, even smoother balancing.
Be more agressive with our automatic server cycling. We cycle servers as soon as memory usage or load is too high, but we tend to be judicious since cycling a server kills the sessions for that server. Taking session management off the server, combined with agile load balancing means we can cycle our servers with extreme prejudice.
Move to ASP.NET gracefully, instead of in one big lump
Load on the SQL cluster is, at the moment, manageable, but there are times when load can max out. Work has been done on further optimising data access and ensuring connection pooling is working as efficiently as possible. Even so, our database backend is the one piece of our puzzle ripe for optimising and will be the focus of our next set of upgrades.
After all the dust settled, load tests showed around a 10-20% improvement in load capacity. The improvements to scalability on both the web and data access sides of things are far more valuable, though, as is the ability to mix and match ASP and ASP.NET pages and components.
I mentioned the 'yet' caveat when talking about us not needing .NET, but that statement applies strictly to the site as it stands now. All future work, improvements and features will be .NET only. A more fine grained article attribution system, more thorough client-based site monitoring systems, offline caching and processing, and features that simply don't make sense in ASP mean the new .NET codebase will be used more and more.
My name is Tim Oden and I am a contract recruiter for Microsoft Corporation. I am currently looking for a developer evangelist and came across your site. I thought it might be a good idea to send you the job description and see what happens.. My hope is that you may know some people who are looking for this type of opportunity. The position is based in Dallas, TX and I have included a Job Description below. If you have any questions for me or would prefer not to receive these type of emails please let me know.
Do you want to join a startup?!!! Are you passionate about software development? Do you want to influence how an industry views .NET?! The BRAND NEW Communications Sector DP&E team has an awesome opportunity for you to make a difference in the way we drive .NET adoption in the Telco/CableCo/Media & Entertainment verticals.
Specific responsibilities of the Developer Evangelist include:
Driving developer adoption of .NET specifically around the use of xml web services, mobility (tabletpc, devices and MapPoint), and vertical specific solutions.
Building activities which accelerate communication with the developer community to drive momentum for the .NET platform. This includes building and leading user groups for our accounts, broad reach evangelism, either directly or through the use of the internet (ie blogging).
Profiling developers across the sub verticals and working with CSNA Marketing to develop new and unique ways to appeal to the developer community.
Developing deeper relationships with SI's and ISV's in the Communications Sector, so that .NET is fully utilized in their solutions. Requirements/Qualifications
We are looking for a highly motivated individual who can help us take evangelism to the NEXT level. The candidate should have a deep understanding and experience of developing and architecting innovative solutions on the .NET platform. The individual should have excellent development, communication and leadership skills.
The ideal candidate will be expected to demonstrate the following competencies:
Has depth skills in building and architecting solutions using the either the Microsoft .NET Framework, J2EE/J2EE or C/C++. These solutions should cover a wide array of solutions from the desktop, to enterprise mission critical applications, and mobility solutions. Media experience is also a plus.
Strategic thinking in assisting our accounts to build a vision around Microsoft .NET.
Deliver broad MSDN Community Development events. These events should not just be account specific, but will also cut across multiple accounts and sub-verticals. These events will not just be focused on doing straight .NET development, but will also focus on how you build mobility, specific LOB, and customer care scenarios with .NET.
Provide pre-sales support around .NET opportunities.
Should be passionate!!!! This is all about passion. Passion for software development on .NET. The candidate will be required to give inspiring, persuasive and passionate presentations to large and small audiences to create excitement. Demonstrates an acute ability to balance an impressive stage presence with the need to carefully listen and personalize the message to connect with individuals from various backgrounds and perspectives. Demonstrates situational awareness by frequently improvising in presentations to make an important point, provide strategic context, and influence audience point of viewstrategic context, and influence audience point of view.
I just released a very nice tool for DICOM file inspection . When I initially created the functional specification, I decided to target the MFC platform only. I could not target unix boxes because of the complexity increase in the design specification and time constraints.
My experiences www.codeproject.com have been reasonable. In fact, the article wizard is a good tool and allows independent publication and removes all the red tape.
I've got a lot, and I mean a LOT, of VBScript code. This website for instance. Moving a large, live site to a new platform gives me some leeway to explore ideas before making them live while getting instant feedback and serious load testing. I can mock-up in VBScript and use the current infrastructure to test, then rewrite in C# using the evolving .NET infrastructure. In the end all I'm doing is providing a front end for a database anyway.
But I digress.
I just read Joel's How Microsoft Lost the API War[^] and apart from being very amused at his comments on MSDN magazine I was a little defensive about his comments that C# is simply VB with curly bits. I'm a C++ guy. I work to the metal. I know 50 ways to leak memory, a dozen ways to corrupt the stack and there's enough FORTRAN programmer left in me that I'll use a goto if I'm feeling surly.
But I don't clean up memory these days. I don't cast structs to (void*) and then cast them back to a different struct. I now implement logic. I am, and this hurts me no end, productive. I'm focussed on the thing I'm building and not the tools I'm using.
Moving from C++ to VBScript is like going back to primary school. It's easy. It's all fluff and a 20 word vocabulary and I hated it until I realised that I was cranking out applications in no time flat spending far, far less time debugging and more and more time building. It has classes, arrays, types, and automatic type casting, memory management and reasonably robust error handling.
So now I'm back from my sabatical and working in C# and feeling a little less sheepish about it all. That is until I started porting my VBScript based ASP pages to C# ASP.NET pages. Change a dim to a string, add a semi-colon, and replace End-If's with curlies and you're done.
Part of me feels ripped off. "But you said it was a first class Language!". Most of me though is brerathing a big sigh of relief. I very occasionally wish I could clean up specific pieces of allocated memory, and the neat freak in me looks a little distainfully at the discarded object lying around, but in the end I know it will all be taken care of, and taken care of in a way that makes leaks impossible, and in a way that frees me up to do the things I enjoy best.
So I'm comfortable with the idea that I'm still writing in VBScript. I've got a few more class libraries to choose from now, and the curly brackets sure save some typing, but I think it's a good thing to let go my Type A control freak tendencies and just enjoy the moment.
Remember that a lone amateur built the Ark. A large group of professionals built the Titanic.
I can't agree with you more. C# is fantastic! I've started doing c# development about a year or so ago and haven't been happier since. I, on the other hand, come from a VB3/4/5/6 background. I do have experience w/ c/c++ as well, but primarily VB. C# gives me all the control I need without digging into the dirty C++ stuff. And thats the way I like to keep it. The .NET framework is definitely quite a great piece of work too. Today we're developing Web services, what will we be developing in 10 yrs? and how are we gonna be doin it? Wonder if by then we'll just need to draw a picture or somethin.
I've come from a C/C++ background and C# is definitely the first language that I've been happy to move over to with both feet. Even Java didn't do it for me - I guess because I could never quite remember some of the subtle contructs. C# solves this - it is C++ but with old requirements removed (header files etc.), and well designed facelifts ("using <namespace>") from the ground up.
I still found it unconfortable for a while not having to delete (or delete) objects all the time. Particularly where you feel you are bloating the heap all the time with arrays of 100's of small objects, but I am receving councilling on this as we speak .
God is REAL unless declared int
Last Visit: 8-Apr-20 13:05 Last Update: 8-Apr-20 13:05