Author: Mark

TechEd 2007 Presentation – slides and demos

This year I’m presenting:

Understanding ASP.NET Internals
You’ve just been sent to Tech·Ed and were told you need to come back with an understanding of ASP.NET. In this session we provide a very technical walk-through of how ASP.NET works. For example, we walk through the page lifecycle, HTTP Handlers, and more. You’ll leave this session with a very good understanding of how ASP.NET works behind the scenes.

Below are the slides and demos:

I also refer to a couple of people whose blog’s you may be interested in if you want to learn more about ASP.NET internals:

In case you’re at TechEd and you’re reading this — this session is scheduled for:

  • Tuesday June 5th at 8:30 AM
  • Thursday June 7th at 1:00 PM (Repeat)

www.asp.net, update part 2

Last week we did an update of www.asp.net and had some significant problems with the main www.asp.net site. I summarized some of this here.

We originally thought the problem – what appeared as a memory leak – was due to a search component we were using. Under load the application would run the CPU at 100% and eat 2-3 MB of memory per-second. This would continue until the memory reach about 700 MB and then the application would attempt to recycle and start the whole cycle over again.

We’re now fairly confident we found the bug, it’s a bug which is only obvious under significant load. Simulating the type and pattern of load on a site as highly trafficked as www.asp.net is not as simple as it sounds. A few people questioned whether or not we even tested the site before we put it into production, which of course we had.

The bug was a in a couple of lines of code for a custom component on www.asp.net. On a positive note this was not Community Server code or Lucene (search code), but custom code written specifically for the CMS system that drives www.asp.net. I won’t go into the specifics, but the bug had to do with loading and parsing an XML document.

We’re definitely very sorry about the down time this caused, but we still want to keep everyone up-to-date with what we’ve found out.

weblogs.asp.net, www.asp.net, and forums.asp.net update

Well, we made some rather large site updates today. Some went well, some not so well. We’ve had a lot of feedback to digest.

I want to personally apologize for the roughness of today’s updates. It obviously didn’t go anywhere near as smoothly as we planned. We made the update around 2AM EST last night, unfortunately due to some technology reasons (shared membership so all sites can share usernames and passwords) we had to make a lot of updates simultaneously. At the same time we rolled out a new design which was created by a design agency in Seattle (so don’t hang us out to dry on the design!).

We started seeing some performance problems with the main www.asp.net application early this morning and of course those problems grew worse over the course of the next several hours. We believe the problem is a memory leak in a component we are using for search, but that isn’t confirmed yet. Nevertheless, the performance problems also impacted forums.asp.net (they are on the same server cluster). Around noon today we rolled www.asp.net back to previous version of the application — but as you can see from the new design forums.asp.net remained on the updated design.

The update also affected weblogs.asp.net: we moved weblogs.asp.net to its own set of dedicated servers, but also had some regressions/problems with JavaScript and themes not carrying over. Typically for security reasons we disable JavaScript and JavaScript is going to be re-enabled on the blogs. I’ve had several people point out that there were not notified of the update — previously we’ve sent mail to people to let them know about any changes. We did send mail this time, but for whatever reason only 119 emails got sent out… and of course some of our most vocal critics didn’t receive notices. Go figure!

We’re moving www.asp.net and forums.asp.net to some new hardware in the next couple of weeks as well. This should also do a lot to improve the performance — right now www.asp.net, forums.asp.net, and about 25+ other applications run on 2 web servers and a single database server (and serve a TON of traffic). Yes, we’re very much past due on making hardware updates.

So again, my apologies for the rough day – the frustration with the updates and breaking features is totally valid. We’ve also had some people point out complaints about performance. It’s easy to sit back and point out everything that is wrong — but there are many people both on my team and at Microsoft working to *improve* these sites and make them better.

If you want to throw any rotten tomatoes you can do so here or to me directly at rhoward@telligent.com — what we really appreciate though is real feedback. I don’t care if you call us out for something dumb that we’ve done, but at least also have a suggestion for what should be improved. 

Developers in Redmond, WA

We're looking for some developers interested in working for Telligent who live in Redmond, WA. We are growing our Redmond team and are looking for some key people to help us grow our Redmond office.

The ideal candidate is very familiar with ASP.NET, AJAX and other Microsoft web technologies. Both contract and full time positions are available. Please contact Scott Dockendorf (Scottd@telligent.com) for more details.

P.S., it will be really fun! 

FogBugz and I are having a falling out

I used to really like FogBugz but the latest version got all glitzy and went AJAX on me and now while it does some cool stuff it's gotten a lot slower. My only other complaint is that it's built to be cross-platform (PHP or ASP), which is admirable but it means that the application has to live somewhere in land of feature mediocrity on both platforms — I bet FogBugz would fly on ASP.NET.

We're not using FogBugz for feature defect tracking. We're using it as a customer management tool. For example, when you email sales@telligent.com you get into a FogBugz queue. While it was great about 2 years ago we're quickly out-growing this solution.

I don't really fault FogBugz for this. When we were working with a small amount of data it was perfect, maybe we've just outgrown it?

This summer we're bringing in our army of interns (email us if you're interested) and I think we're going to build a replacement for how we use FogBugz (focused on the CRM side).