Fuck Cancer

An acquaintance of mine was the guest of honor on a local radio station’s morning show this past Thursday. The DJ’s described the shirt he was wearing as having nothing but the title of this post on the front: Fuck Cancer. I can’t say that I’ve ever seen him wear it, though I’ve only met him a couple times. My wife has run with him at local events, and it was she who first told me about the shirt.

You see, this gentleman is living with cancer that will eventually take his life. It will give him nothing in return. No love, no gifts, no happy memories, no pat on the back. It will only take. It will take him. Paraphrasing him, cancer doesn’t deserve our respect because it has none for us, so fuck cancer.

Yesterday, I received an email from a friend of mine letting me know that a childhood friend of ours had passed away. My friend Joe was diagnosed with cancer in October of 2011. He passed away April 1, 2012, just a couple months past his 43rd birthday.

I met Joe in 1st grade. We rode bikes together and played football together. I remember riding to football practice together in the back of my dad’s pickup (you could do that back then…). He was our star tailback. We got our first motocross bikes for Christmas in 7th grade; matching 1981 YZ 80’s. We rode every chance we could. We went to our first Supercross race together. It was Anaheim, 1982. Shortly after that race, my family moved to Utah, and we kept in touch as best we could. Our lives grew apart, but we kept crossing paths off and on through the years, as I moved back and forth between California and Utah. It was always good to see him and we could pick up like we had just seen each other days ago.

One of the last times I saw him in person was again in Anaheim, at a Supercross race in 2002, or 2003. I was standing in the pits with a group of friends, when I got the urge to turn around and scan the crowd. Not 10 feet away from me was Joe. I got the chance to meet his kids, and see his older brother, who was also there. We exchanged cards for years after, but since I moved back to Utah in 2005, I haven’t had the opportunity to see him in person.

Cancer took his life years too soon. It is a heartless, cruel, miserable beast.

Rest in peace, Joe.

TFS 2010 Performance Issues with New Project Collection

We stumbled onto an interesting performance problem this week with our TFS 2010 server at work. The DefaultCollection on our corporate TFS server was getting a little crowded, so my team decided to spin up our own project collection to ease management and help us isolate our build operations. The new project collection was created and I was assigned the role of ProjectCollectionAdministrator.

The first order of business was to migrate the source code from our Team Project on the DefaultCollection to a new Team Project on the new collection. I used the TFS Integration Tool to accomplish the migration, but it seemed to be performing slowly while migrating the files. I chalked it up to heavy usage on the server and went about my migration business. Hell, it was only going to happen once anyway, so… Little did I know that this was merely a warning of things to come.

After the migration was complete, I mapped our new source control node to my file system and performed a Get Latest. Yikes!! Performance was pretty bad, and as others started using the system, we started to see Get’s performed against large source control nodes fail outright. They just spun while querying the database for items to get, never attempting to pull the files from source control.

We went about our usual troubleshooting routines of checking logs, event logs, processes, memory usage, etc. We couldn’t help but feel that the issue was with indexing, or something similar, in the new project collection’s database (for those who aren’t familiar with TFS, each Project Collection gets its own database in SQL Server).

It took the efforts of our DBA’s to track down the problem. We/they couldn’t actually inspect the stored procedures in the collection’s database because the procedures are encrypted. The DBA’s noticed an unusually high number of reads on some tables, relative to the amount of records they contained. In comparison to the collection whose performance was good, they were seeing substantially more reads against the smaller tables while people were trying to perform Get’s.

The DBA’s determined that the execution plan(s) of one, or more, stored procedures were in a bad state. Recompiling the stored procedures was not an option because, due to their encryption, we couldn’t see into them to determine which ones to recompile. So, one of the DBA’s used a fancy trick (fancy to me, anyway). He ran sp_recompile on the affected tables, which resulted in recompilation of the stored procedures that accessed the tables. He described it as a “sledge-hammer” method of accomplishing the goal, but it worked a treat. As soon as the recompile completed, our new collection was flying.