> 1. Get a multi-cpu box. If your company doesn't test on a box with That's good advice and I'll bring it up.
> 2. Write a client that can hammer your server app from > across the network. > Just completely slam it for several days. The more random > the data and the > more diverse the data you send the better. If you can add a > feature to your > server that will save "transactions" (in your case they don't > sound like > real transactions) so your test client can "replay" the data that'd be > great. Just record several weeks worth of data and play it > all back at > once. Yes, that's how I test. That's pretty much how we do test, but it doesn't seem very rigorous to me. > 3. Move your model over to IOCP (yes guys, I'm still riding the IOCP > bandwagon). Here's the general way I'd run your process (if > possible this > way, I don't know the nature of your data). I'd memory map > in a huge file > then issue a whole set of reads to read from your driver and > put the data in > consecutive chunks in the file, when the file starts getting > full I'd open a > second file and get ready to issue the reads on it, as the first file > finally fills up I'd issue all the reads to fill the second > file. Because That's pretty close to how we're running already! > BTW, what do you mean by "weak code" that you fixed? Either > it works right > or it doesn't. If you found room for error and a resultant > crash, then this > isn't weak code, it's faulty code. And unless you can find > another such > fault in your code and you can't reproduce the problem by > doing the testing > in 1 and 2 above, I'd write it off. Well, by "weak code", I saw something that looked like it could have a hole in it, but I wasn't sure that scenario could actually happen. Still, it wasn't good code, so I improved it. I didn't call it a "bug" because I wasn't sure it either caused the bug or could cause a bug. (Although, since the user hasn't complained again, maybe it was the problem after all!)
