What's it all about, Alfie?

Today I spent a lot of time trying to figure out what the problem was with the hardware for this little feeder app to this larger webapp. I started with a desktop box, and got it set up and running. The times were nice, but still about twice what it was running on my desktop. So that spun off a big investigation as to why seemingly identical boxes are off by a factor of two.

After that for a bit, I was given a Windows Server to check. It was fine, but the times were slower - primarily due to slower processors in the server. Still, it was nice to see that I was able to run the application on Windows Server as opposed to just XP. But in the end, "nice, but no good", I was still a long way away from the marks I'd taken using my desktop.

When I went back to the desktop to try and account for the factor of 2, I noticed the network card was running at 1/10th that of my desktop, so I called in the network support guys to ask to have it switched up to 1Gbps. Turns out, they can't start until 4:15 pm. Yum.

I wish this was more clear-cut. I have something, but not enough. Have to keep at it tomorrow.

Today I got a tweet about a new release of BBEdit being out - 9.3. The release notes are extensive and shows this to be a significant update to the system. Wow. Pretty impressive.

I'm not sure about a lot of the new stuff, but the "maketags" argument is great as it means I don't have to worry about making my own ctags file. Very nice of them.

I got a nice little notice from LaunchBar that 5.0.2 was out with a few pretty serious bugs fixed. It's something I use every day, and while I'm not indexing Services a lot, it's nice to get the memory leaks fixed.

Today I've spent a lot of time trying to find performance where there was no guarantee that it should be found. I had a strong feeling that there had to be a better way, but I had no proof. I have this application that needs to talk to a legacy system through a DataSource connector (yeah, Windows) to get data out and into the app I inherited. Doesn't sound too hard. Yeah, right.

Well, this is complicated by the fact that there are a few ways to get at this data, and I was looking at different access schemes and thinking "If I could get the speed Excel has in getting the data, I'd be OK". So it became a quest for how Excel did it, and matching it's speed.

I started with the existing code - using an OleDbAdapter. This was taking a horribly long 130 sec. to get the data that Excel could return on my desktop box in about 12 sec. That factor of ten was killing me. I needed to run it on the VMs, but hey, they're supposed to be virtual machines and match the performance of my desktop - right?

So I tried an ODBC connector. That didn't get me anywhere because the methods to populate the .NET DataTable weren't implemented in the ODBC driver. After I passed this back to the developer that pointed me in this direction, he agreed that yeah, this wouldn't work. Nice.

Then I tried a more "bare bones" approach - getting the data at a low-level array and then pulling that apart to make a DataTable out of it. WHen I got that one into test, I realized that the time was even worse. Not the right direction to go in.

So finally I started running all the tests on all the machines I had at my disposal: my desktop, my Test VM, and the Production VM. The results were shocking.

so while I might see that the difference between a VM and a desktop is somewhat fixed for the Excel query, it's hardly fixed for the programmatic query.

Why the difference?

My best explanation is that VMs are horrible for anything that needs to use a disk. The two VMs have different disk subsystems and neither is really good. We are getting a new SAN, but that's going to be a few weeks away, still. The performance should then even out as all the VMs will be moved to the new SAN, but until then, we're stuck with what we have.

Additionally, the desktop seems to have consistent performance in either case. While this seems logical, it also seems to point to the fact that the Excel query is much less memory-intensive. I can see it pulling in the data in a stream. The code query has to get it all in a DataTable and then process it. I can see this being a big difference in the table sizes we're looking at.

What I'm going to try tomorrow is to get a plain desktop and try to set it up as the compute box to replace the production VM. This is not going to make me any friends in the support group as they hate having production apps on desktop boxes, but hey... this is an order of magnitude difference. We can try to get XP-compatible servers and replace the desktop with a server-room solution when we can get it in, racked and powered. But for now, the users are screaming and I need to give them a solution.

Amazing how things work out.

Saw this morning that VLC 1.0.3 is out. Since it's a core part of HandBrake and ripping DVDs, I had to upgrade. I'm a little surprised that the built-in auto-updating is not picking up these changes, but then, maybe they don't consider these to be significant updates.

This morning I saw that the Firefox team has released beta 1 of Firefox 3.6. Seems like quite a lot of little changes, but I'm not seeing the kind of speed jumps in JavaScript that would make it a big deal to me. However, it's nice to see the improvements. Maybe in a bit I'll give it a run, but for now, it's nice to know it's there, but I'll pass for today.

With the recent change of Google's home page to the version with the custom buttons, I've had a problem in that they do not respect the width of the browser and in fact, have a fixed minimum horizontal width to make things look nice. I'm not really interested in seeing more whitespace just so I don't have to see the scrollbar, so I was very happy with this hint about how to effect the zoom factor on the Safari page.

I created the file ~/Documents/defaultzoom.css to contain:

  body {
      zoom: 90%;
  }

and then went to the Preferences, 'Advanced' tab in Safari, and added this as the CSS page. It immediately resized the pages to exactly what I wanted. Very nice.

In general, I think there's a too much whitespace on most sites, and this zoom 'out' by default makes it easier for me to see more information in less space. Great.

Today has been a real up-and-down day. It started out very nicely when I was able to come back in after a day off helping friends in Indy and see that the work I'd done for the persistent state of the alerts I'd been working on last week was really rather good. I had a few typos in the code, and one logical mistake of not returning the value from a map look-up, but that was it. I was really very happy with the way it was working out.

But that happiness didn't last long.

I got an upset call from one of the bigger users and they were very unhappy about the state of the performance of the updates from the system I inherited. There's not a lot I could think to do about the issue, but I had to dig in and give it a go.

What ensued was a day long realization that not a single soul had solid understanding of several key components of data-access code that I was forced to use. It was frustrating to say the least, and because I made very little headway today, I know I'm not going to be out from under it tomorrow.

Yeah, it went from great to crappy in no-time flat.