Slashdot Mirror
Debugging Microsoft.com
teslatug writes "Channel 9 has an interesting video interview with Chris St.Amand and Jeff Stucky who test and debug Microsoft.com. They reveal some of the big problems they used to face such as recycling processes every 5 minutes due to memory leaks and 32 bit limitations, and being unable to push more than 10 Mbits of data to their datacenters due to Windows' networking stack limitations."
They should be redesigned.
That's a big problem of software made by companys:
1 - The company's cashflow is based arround selling new versions of the software
2 - They can't sell to it's customers improvements that they customers can't see
3 - There is a fixed time that can go by beetween one release and the next one
4 - Resources are limited
Because of this, a major redesign is something that won't be profitable, because only the advanced users will note the changes, but 99% of their customers won't, so the software won't sell well. Bug fixes also won't sell, because they are also unvisible to the naked eye of the majority of the userbase, and also customers expect those changes to be free.
So, some companys only can expect revenue from a given software once a year, and they have to invest into that software, a given set of limited resources over, say, 6 months, when they have to freeze the featureset so they can start debugging. Seeing which things sell, they will obviously focus their atention on: New Features, and a nicer GUI.
OTH, a project that doesn't have a company running it, can just get out lots of upgrades, when needed, and focus their time on making the software better, even if some of the changes made to the software won't be seen by most of it's users.
With software prices dropping, and Free Software proving to be a better option, the budget of software companys will be even more limited, and we won't see this situation changing anytime soon.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
According to microsoft, the MSN messenger service (which serves to around 70 million people) used to run on 250 32-bit servers, and now it runs on just 25 or something like that... (apparently one of the big reasons was the limit on the number of tcp connections).
It's quite amazing to think that a service as huge as messenger can run on just 25 servers!
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
IIS just can't hold up by itself, if you just serve static pages you are ok, but when people starts using that asp + odbc shit, you have to restart IIS every 5 fucking minutes.
That's not because of IIS; it's because of the people writing the ASP apps and stupid admins not configuring IIS correctly. If you have stupid people writing applications, those applications have a tendency of doing stupid things. Combine that with admins who don't properly isolate that applications running on IIS and you've got a recipe for requiring an IIS restart "every 5 fucking minutes".
Give me 5 minutes and I can write a nice app that takes down Apache no problem. A few infinite loops, perhaps each creating a dozen new database connections and allocating a massive string buffer in memory.
IIS 6.0 has a lot of features built into it that allow for admins to configure application pools to more effectively isolate applications. You can configure those application pools to recycle automatically given certain criteria (like memory usage, CPU usage, # req/sec, @ req/total, etc.), and the pools are isolated from each other so that if one dies due to a misbehaving application, the other applications on the system are not affected.
We used to receive a stupid "too many conections" from ODBC in our log, and restarting the stupid services woudln't do a damn thing, all you could do was restart the machine, Yes, restart a SERVER.
Perhaps that's all you could do, but somebody who spent more than 10 minutes reading about administering IIS would know to recycle the ODBC COM+ application to clear out the connection pool. Then they would find the stupid people writing that crappy applications and fire them, or at least isolate their applications in a separate app pool or worker process. (Dllhost.exe.)
Spare me the anecdotal stories of your LAMP solutions doing so much better than your Windows solutions. You have absolutely no credibility given your complete ignorance.