Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Heard on .NET Rocks!: Indy Racing League : Page 2

In episode #109 Matt Mannion from Clarity Consulting talks about the application his company developed with and for the Indy Racing League in Indianapolis, IN. Using Visual Studio .NET 2003 and VB.NET they were able to develop a great application for managing real-time racing data and reporting.


advertisement
Continued...
Carl Franklin: That's interesting. Now, the operator console, is this a Windows' application or a Web app or what? Matt Mannion: That's a WinForms app, as well. It's only got one user, basically. It's the folks in the timing and scoring booth.

Carl Franklin: And were you guys writing directly with ADO.NET just to SQL server over TCP/IP, or you were using Web services, or what did the transport look like? Matt Mannion: No, we didn't use a Web service. We just basically were using ADO.NET.

Carl Franklin: Okay. And how much was that SQL server working? How did it perform? Matt Mannion: The SQL server performed outstanding. It was powered on a pretty nice-sized server; but it's pretty taxing, because while the one application is shooting in these 80,000 to 100,000 rows, we have got anywhere from 40 or 50-plus users hitting this thing with about a half-second refresh rate to get the latest results back. So the results on the screen are never more than a half-second old. So in the timing, it was actually pretty quick from the track from the transponder to the SQL and then back up to the viewer.



Richard Campbell: I was just thinking, you must have another glob of code sitting there monitoring the transponder and, as data is coming in, writing it to the database. And then you're just straight polling against the database to see the data as it comes in. Matt Mannion: Right. Those were two disconnected processes; and there was one application that was running, just collecting it off the track and shooting it into the SQL server, and then there was our application sitting on top of the SQL server, just pulling data off every half-second for each client.

Richard Campbell: So the main thing you guys worked on was the presentation side of this. The feed stuff worked? Matt Mannion: Correct. The infrastructure for the data feed off the track, and the transponders were already in place.

Richard Campbell: That's nice. Carl Franklin: I like this quote from Jon Koskey. It says initially, he was concerned that the increased volume of aggregate data could be an issue in the server's performance. "In a typical race, we will feed 80,000 to 100,000 records into the database, in addition to a lot of outgoing information. We are serving up 300 to 600 simultaneous connections per second." he says. "We were a little worried about how SQL Server would handle that volume; but as it turns out, we were running at less than 20% of processing power." That's awesome.

Matt Mannion: Yeah, and we tested that back in Indianapolis when we were building the application. What I did was, I used an application-center test act, and basically, we just put up a Web page that was just calling in to that results viewer's method and stored proc. And I just loaded up several hundred clients just hammering away on that thing, and I put performance monitors up on the SQL Server box and tuned the query that way and just let it fly. And before we even got out to the track, we knew that that thing was going to perform real well. Richard Campbell: This is a Smart Client app, right? This is not a Web-based app.

Matt Mannion: It's not Web-based. It's Windows' form application; and it was a Smart Client application, because they really wanted the ability to push updates out to the teams without having to disrupt them or visit each team and station and install an update. Richard Campbell: Yeah. I guess all these teams are independent entities, they've got their own gear, and you need to work with what they've got.

Matt Mannion: Correct. We publish minimum standards that they need to have in order to run the application, and after that, they just show up with whatever they want. And as you pointed out, it could be a Tablet PC, it could be a Desktop or whatever. And then there are so many different players they are dealing with, because beyond the crew, then they have the media. They are all looking at this, so they are running it. The manufacturers come in, and they want to see how their tires and motors and what-have-you are performing out on the track so they come in and they want to look at results, so they are looking at it. So a lot of times, you don't even know who is coming in on each race. So it was very difficult to coordinate those updates.

Richard Campbell: All these different bits of data about specs on the car, state of the tires and all those kinds of things are coming regularly via the sensors on the track. Matt Mannion: Right. Well, the performance of the car is coming through the track, and then they can interpret what that means.

Carl Franklin: Yeah. I was going to say, some of the data gets inferred from just the raw data and the ratios. Richard Campbell: Yeah, because I know I have read lots about racecars having telemetry systems; but I wasn't sure that the track data was part of that same telemetry, or if they are separate things.

Matt Mannion: A lot of times, it's separate. The car owners themselves might put monitoring systems and sensors in their cars themselves. They are only privy to that. Richard Campbell: So then, they have detailed data of their car; but when it comes to official track-performance figures, the track is in control of that.

Matt Mannion: Correct. The results that come out of the system are the official results published by the IRL. Richard Campbell: And everybody is using wireless for it. I am just wondering how well the wireless network held up under all those machines and all those connections?

Matt Mannion: You know what? When we were out at Phoenix, surprisingly, there was one little glitch at one end of the track that just on the way down—you know how the figure runs all the way down the straightaway there? Folks on the far ends were having a difficulty; but they actually were able to remedy that. And for the most part, it runs real well. Richard Campbell: Wow! So, I mean, a bunch of access points, or just one really powerful antenna?

Matt Mannion: They actually had one other relay point on the track at the race I was at. Carl Franklin: I've got a really interesting question, and I don't know if you can specifically address this yourself. But do you remember? What were some of the specific problems they were having with the Flash Java version that were solved or are non-issues in the .NET version that you wrote?

Matt Mannion: Well, there were issues on both ends of it. There were issues from the developer perspective that we already talked about, just the difficulty in maintaining it. And given the way the race season runs most of the year, they have very little time to be back in the office and modifying their applications, where they are back out on the road and doing a race every month? So they really don't have a big window in which to do these application changes. Carl Franklin: I also read in the case study that there were some problems with the different versions of the JRE caching on the client or on the server or something? There were some issues with versioning that couldn't be solved.

Matt Mannion: Yeah, they ran into some issues with that; and they had issues with, like, a middle tier that actually sat between their SQL server and the Flash application, and they had issues with that, as well. And then the other problem they had was, they just couldn't customize it. So like I said, there were, like, 40 or 50 data points that you can look at; and with the Flash application, you had to look at all of them.

Carl Franklin: You know, Richard, as I am reading the case study and listening to the story, I get the distinct feeling that this is, like, the perfect application to write. It's not mired in lots of complex business objects and lots of rules and extremely large, complex architectures. It's a simple, data set-centric ADO.NET app. Richard Campbell: But it's velocity-sensitive. I mean, the timeliness of the data is critical. And it's got to be very customizable. There is more data than you can possibly, reasonably look at; so you need to be able to sort it in the form you need to see that.

Carl Franklin: But I guess what I am saying is, it seems like it is made for that model. Like, the whole .NET data set-centric programming model really just is, like, a no-brainer in this situation. Richard Campbell: Well, and the kicker is the offline stuff.

Carl Franklin: Oh, yeah, totally. That's great. It's the kind of application that I wish I could get to write once in a while, you know. (Laughter)

Matt Mannion: It was a real fun application to write, because as we were building this, we had a simulator there in the office that would run with a videotape of historical races; and as the video was running, in the background, we can simulate the data coming through for those cars. So it was just fun to do. The only thing was just the time frame within which we had to do it. But other than that, you're right. It was just a classic WinForm app: dataset, bind to a grid. The thing that made it difficult was all the functionality they wanted in the grid.

Richard Campbell: In five weeks.



Carl Franklin is a frequent contributor to CoDe Magazine.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap