Monday, October 23, 2006

Some more remote desktop subtlety

If you are remote desktop'ed into a machine, then your clipboard is synced between your local machine and the remote machine. So, if you copy some data from a text file on the remote machine, you can paste that data into the local machine, and vice-versa.

This is not true, however, if you daisy chain your remote connections, as in the previous post.  Your local machine and machine A will be synced, and machines A and B will be synced, but you can't copy from machine B directly to your local machine.

What I do to get around this is to copy from B, then create a new text file on A. Paste the data from B into the text file, then copy the text from A, and paste it onto your local machine.

Or, you could save the data to a text file from B, directly onto your local machine's C drive, using the technique in the previous post.

Going a bit further with Remote Desktop

Phil Haack pointed us all to a blog entry by Steven Harman, which shows how to automagically map your remote drives to your remote desktop connected computer.  I'll go one step further.

Let's say you're remote desktopped into Machine A.  You are all super cool, now that you've read Steven's blog post, so you have easy access to your local computer's hard drive.

But, let's say you need to remote desktop into machine B, which you can only do from machine A (due to network limitations).

How do you map your local machine's hard drives all the way through to machine B?

It's simple, actually.  On machine A, in your remote desktop window, map a network drive to \\tsclient\c (if the c drive is the one you want mapped).

That drive should show up with a letter now, probably close to 'Z', unless you changed it during the mapping.

Now, if you remote into machine B, after following Steven's advice, you'll see a drive similar to 'Z on TSClient'.  That drive is actually the hard drive of your local machine, visible to both machines A and B.

Take note, however, that file operations to your local drive through a daisy-chained Remote Desktop connection will be noticeably slower than usual.

Thursday, October 19, 2006

2005 Yamaha R6(Raven) for sale

As much as it pains me, I have to say good bye to my baby. The wife and new daughter aren't too happy with the idea of me joyriding around on two wheels anymore, so it's got to go.

Here are the stats:

2005 Yamaha YZF-R6
Raven (black)
~3500 miles


Modifications:
semi-flush front turn signals (the lights protrude about 1" from the side of the fairings, but are the flush style of lights, not the stockers)
integrated rear turn signals
silver to black Micron slip-on exhaust
removed rear fender
flush license plate lights (bright white led)
hard wired garage door opener (currently wired for Genie doors, easily changed for other doors)

I am the only owner of the bike, I bought it new in Daytona, Florida, from Jim Walker Suzuki-Yamaha. I have all of the original paperwork, as well as all maintenance records.

All scheduled maintenance has been performed by certified Yamaha mechanics, on time per the schedule. Additionally, I did an extra oil change at 200 miles, just to be safe.

The bike is a lot of fun to ride, and really in great shape. It's been garaged since the first day I bought it. Currently, the bike is garaged at my house in Redmond, just 10 minutes or so from Main campus. I'm available any time to show the bike to interested parties.

I'm asking $7199 OBO.

I have a HJC helmet which matches the bike, XL, included with the bike, if it fits.

I also have a size 46 Alpine Stars TZ1 leather jacket for sale, $200. It's the black and grey color scheme. http://www.alpinestars.com/moto/jackets_tz1jacket.html

I'd appreciate it if you would share this information with anyone you know that is looking for a bike.

Tuesday, October 17, 2006

VSTT: Service Background

I just realized that I've been talking about OfficeLive, but I haven't given you any idea of the user load I'm testing for, or what our performance goals are.

The most used part of our system is a user registration database.  This database is used by OfficeLive, Office Online, and Office 2007 online registration.

The user estimates for all of these services combined is approximately 70 million users over a 1 year period, which equates to 5,833,334 per month. This equates to ~2 users added every second. This number is just an average, though. We have to test to our system to our peak load, not the average load.

Our stress tests have tested our system to 2500 concurrent users.  We estimate that we will be able to support triple that number in production, based on the resource utilization we see with 2500 users.

Building a system to support 70 million entries in a database system comes with a huge set of challenges. I'll continue to share the problems we face, and the solutions we find, as we conquer them.

Monday, October 16, 2006

VSTT: Working with a test rig

In VSTT, you will quickly find the need to generate large numbers of concurrent users.  Generating this level of load will be impossible with a single machine.

VSTT enables this through the use of a "test rig".  You can read the MSDN documentation, on MSDNWiki, here. You might even notice a community comment by yours truly on the wiki site.

Basically, the way it works is that you have one boss machine, called a controller.  The controller works with zero or more worker machines, called agents.  These machines are associated together during installation of the Team Test Controller and Team Test Agent. Both are available on your distribution media for VSTT or VSTS.

Once you have the agent and controller software installed in your test rig, you're ready to generate massive amounts of load.

Now we get to the interesting part.  How do you know how many users you should simulate? It is best to start with a clearly defined goal for the number of concurrent users your software or service should support. My suggestion is to start a load test with half that number of users. Then, you can use a step based load pattern to gradually increase that number of users, until you reach your goal level.  I believe it's a good idea to make your steps as large as you can.

For instance, if you are going to supoprt 1000 users, and you're running a 10 hour test, start with 500 users. Use goal based load pattern, and set your step amount to 100, and the step duration to 90 minutes. This will cause you to reach your target of 1000 users at 7.5 hours into the test.  That allows you to test each step long enough to see if there are problems with the new load level. You will also get to test at your target load level for 2.5 hours, which will provide you with a good baseline for future testing.

If your test fails at any step, you can start a new test, and test at that user level, or slightly below it, and begin to narrow down the reason for your test failing.

The only caveat is if your test fails because you run out of resources on your agents.

In one part of the OfficeLive service, we started testing at 500 users.  We gradually increased the number of users from 500 up to 2500. Once we started to get closer to the maximum number of users we thought we could support, we started changing to a goal-based load pattern. We set the goal based pattern to monitor one of our SQL backend machines, and to adjust load until the processors were at 90% utilization. Every time, however, our test would fail shortly after passing 2500 users.  The test failed because we were running out of memory on one of our agents.

You have two options if this happens. If there is a particular agent that is causing you problems, you can adjust the load weighting for that agent, so that it gets fewer users assigned to it.  If however, all of your machines are low on resources, you have reached the limit on the number of users you can simulate, and, consequently, the amount of load you can place on your system.

In our case, all of our agents run out of memory, so we have found that running with more than 2500 users, on our particular hardware, is not possible.

Hopefully, I've shed some light on how to determine the maximum load you can generate, given your specific hardware assets.

VSTT: Custom counter sets

When you are building a load test in VSTT, you can specify sets of counters to be collected as a group. VSTS provides a bunch of default counter sets, like ADO.NET, and IIS, and SQL.  Those counter sets are great for default programs and installations.

If your service or application, like mine, creates and publishes custom counters, you may find a need to create your own counter sets. Once you've done so, you will almost certainly want to share those counter sets among your colleagues.

If you look in Program Files\Microsoft Visual Studio 8\Common7\IDE\Templates\LoadTest\CounterSets, you will see several .CounterSet files.  They are XML files (with a really easy schema), which define what counters and instances should be collected.

If you edit a custom counter set through the UI, you should find a new file in that directory. 

If you don't want to deal with the UI (it can be slow), then you can create the xml file directly.  This will enable you to build the custom counter sets as part of your build process, or part of the development process.  Manipulating the XML is shockingly easy, due to the simple schema.

You can then check that file into your source control (you are using source control, right?), and all your buddies can copy it to the correct directory on their computer.

The next time they start VSTT, they will see the counter set in the UI, in the list of available counter sets, and can map those counters to computers that you will be monitoring in your load test.

Announcing a new series

The next post will be the start of a new series.  I'll be writing about some of the lessons I have learned while working for Microsoft, helping to build and test Office Live (www.OfficeLive.com).

I will be focusing on stress testing web applications and services, using the tools included with Visual Studio Team Edition for Testers.

First some terms and acronyms. I will abbreviate VS Team Edition for Testers as VSTT. You can also use Visual Studio Team Suite(VSTS). The load  and web testing framework included with VSTS and VSTT is called Ocracoke internally to Microsoft.

Ocracoke is the name of an island in North Carolina, where VSTS was built.

So, stay tuned, and hopefully you'll find some use from these posts.

Monday, October 09, 2006

Upside-down respect

I noticed something at the MSFT company meeting a couple weeks ago that totally shocked me.

During the company meeting, most of the really high-level executives gave a speech.

I was sitting surrounded by a bunch of people who have been MSFTies much longer than I have (most of the company has been there longer than I have). When the executives started speaking, and the demos were over, most of the employees around me kind of tuned the execs out. They speak corporatespeak, like all executives, and most peons I know don't care about corporatespeak.

There were two exceptions. The one that didn't surprise me,and shouldn't surprise you, was Steve Ballmer. SteveB is a madman, and he single-handedly raised the energy level in the entire baseball stadium.

The second one really surprised me. In every other company I have ever worked for, the HR chief was the least listened to person in the company. HR types generally speak a language that not only do peons not care about, but which irritates them.

Lisa Brummel, on the other hand, is different.  When Lisa came out on stage, the entire stadium quieted, and you could sense the interest that people had in her words. Most of the guys around me leaned forwards in their chairs, as if to hear her better.

One of the more senior guys around me made an interesting comment, and one that I have never heard applied to any HR rep at any other company I've worked at. He said something to the effect of "I respect Lisa Brummel more than any other executive at this company". That is a shocking statement, applied to an HR chief.  More shocking (at least to me), is that I agreed with him.

Today, there is an article in the Seattle Times about Lisa Brummel, and some of the changes she is driving. The changes she has introduced have been met with some confusion, as us peons learned how they affected us. However, once we had some meetings about the new changes, everyone I've spoken to was extremely happy about the changes, and basically all said something like "about time".

Thank you, Lisa Brummel, from all of us peons.

Wednesday, October 04, 2006

More Vista happiness

The screenshots I include with this post don't exactly match the story, but you'll be able to figure it out.

I was messing around with XNA on Vista the other day, and realized something.  I created a new folder, and the icon for that folder was the generic, "I'm a folder" icon.

Then, I put a picture in that folder.  I half expected the folder's icon to change, such that it showed that there was a picture in the folder.

However, what I didn't expect, and was pleasantly surprised to learn, is that the icon was changed in a way that matched the actual picture in the folder.  The picture is a blueprint of a porsche 550. You can see, in the icon for that folder, the outline of the blueprint image, and can definitely see that the icon reflects what is in the folder.

In another folder, I added a couple of items. The icon for that folder showed that there were two items in the folder. It gets even cooler when you have subfolders.

This is going to be a huge timesaver, once we can get our heads wrapped around all the extra information that is in the icon.  Looking for a picture, but you don't remember where you put it?  Just breeze through the folder icons, and you've got a chance to find it.  Can't remember which folder you put that distinct word doc in? Check out the folder icons to find it.

The more I use Vista, the more I like it.

Taking a tradition too far

Traditions are fun.  I'm a big fan of traditions, especially ones that are humorous in some way.

Here at Microsoft, on your anniversary, employees traditionally put one pound of chocolate goodness (M&Ms are very common) outside their door for every year they have worked in the borg.

We have a guy on our team, Mikky, who has been at Microsoft 15 years. Today, there are 12 pounds of M&Ms outside his door (the last three pounds are in his office; they wouldn't fit in the bowl).

This is definitely a funny example of a tradition that has been taken too far.  Personally, I would have tried to find denser chocolate, so the 15 lbs wouldn't be so large.

Congratulations, Mikky.  We sure are glad you've stuck around so long.

Several updates

The guy who writes one of the blogs I read on a regular basis, the Daily WTF, is starting a new business.  He's going to create a type of job board, but with a new (at least as far as I know) twist.  He's going to advertise the jobs on blogs, using a format similar to google adwords and such. Phil Haack is jumping on board, too.

I am totally interested in this, and want to get on board (the bloggers who do the advertising get paid).  To that end, I'm going to start posting more frequently, and more of my posts are going to focus on technical issues and challenges, especially using .NET.

For the meantime, I'll be focusing on stress/perf testing, and also on game development using XNA.  Since XNA is finally in beta, I can post some code samples and such, and start gettting the word out about it.  I've started an XNA game, so expect to see more about that.

Also, I've been contacted by the Coding4Fun guys about writing a series of articles or two about XNA and game devlopment.  I'm going to partner with another Microsoftie, Jason Cahill, to build a game over a series of articles.  We just started talking about it yesterday, so I don't have a lot of details, but I do know that we're going to build a tic-tac-toe game. We wanted to choose a game that nearly everyone would already know how to play, so we could focus on the development challenges, and not defining or explaining a lot of rules.

I'll keep you posted on our progress there, and I'll probably put up some entries dealing with the issues we face getting that to work.