Expansion Diary Part 1

I just got news that our company will be nearly doubling in size over the next six months!  There's a lot to do in preparation for this, so I figured it would give me something to blog about :)  Let the madness begin!

Basically, our company runs using our intranet application which we've developed in-house over the last few years.  It's all ASP based, with plenty of COM objects, ActiveX Controls, includes, and spaghetti code all over the place.  The back end is SQL Server (started with v7, now at 2000).  We're in the midst of a total re-write in ASP.NET.

I couldn't be more terrified :)  Let me explain.  Our company is one of those where you just "get the job done" and think about it later.  What I mean by this is "if it works, great - let's move on to the next project."  Very little (read "no") time has been given to performance monitoring, profiling, optimization, etc.  If something runs slow we tune it up a bit and move on.

We've got a few things that always make us wonder, like the calls every now and then where someone is complaining that the system is slow.  It's pretty random.  There have been times when every day at around 2pm the system gets REALLY slow.  The funny part is - we never figured out why - and it stopped happening - and we still couldn't figure out why.  Now please understand, I'm not just a dummy with no clue how to troubleshoot things.  We did all of the basics, asked lots of questions, etc.  The problem just magically "went away" before we found the cause.  Then, our company culture led us to simply say "oh well good - now we can move on to the next thing!"  That, I'll admit, is probably dumb :)

So, now I've got a situation where I need to be prepared to handle a PILE of new users in six months time.  Now, I'm concentrating on making that happen.  All I've got is the most basic of plans, which I'll outline here:

1) Find out which pages the sales guys access the most.  The expansion is mostly sales people.

2) Optimize those pages as much as possible.

3) Somehow establish a baseline of user activity, and keep it up to date.

4) Understand how to make use of the baseline data over time to predict capacity/performance.

My biggest fear in this whole thing is that there are so may gray areas when it comes to the performance of an intranet application.  When something is slow, is it because the SQL Server is returning data slowly?  Is it because IIS is slow?  Is there a network bottleneck?  Once we worked most of a day on something only to find out our DNS server had problems.  Ugh.

Wish me luck!

Print | posted on Wednesday, January 14, 2004 7:17 AM

Feedback

# re: Expansion Diary Part 1

left by Justin at 1/14/2004 10:03 PM Gravatar
Good Luck! I deal with most of those same problems too, writing web based intranet apps with no real time for stress testing (not that I would have the capabilities to do so if I had the time but thats beside the point.) I am constantly debating whether to fix a problem or try and get the next feature out the door.

Justin

# re: Expansion Diary Part 1

left by AjarnMark at 1/15/2004 6:19 PM Gravatar
Stress testing? Is that where you keep testing and re-testing your application, all the while getting more and more stressed? I'm familiar with that! :) Of course, I made others really stressed when I plugged in the MS WAST tool and let it bang away at the server.

Travis, you're right on the money when you say it's your corporate culture that is the driving issue. That "make it work good enough and move on" attitude is more often found in small companies than in big ones, but seems to pop up more as everything in life gets sped up.

I'll be interested to read how things go for you. BTW, you might want to write a couple of timing routines that you can slip into your code (I'd put them in a common INCLUDE file to be called when desired). Then start putting them into your pages with some sort of system flag they check to decide whether to display the times. I'm imagining something that you'd call to establish a start time, then later a stop time, and of course the difference. Then you could put these around your DB calls to see how long they are taking, and also at the top/bottom of each page to see how long the page takes to get served. When you want to see the outputs, flip your system flag and voila! they appear on your page. That's sort of a poor-man's way of locating your bottlenecks.

Good luck!
Comments have been closed on this topic.