Don't Worry About Performance!

There was a statement made a number of years ago in an ISWG (Integration Services Working Group) meeting which, to summarize, said "Don't worry about performance, we'll take care of that".  While that is probably going to be the epitaph of at least one person, I think it is time to set the record straight.

Worry about performance.

OK, now that we've gone 180 degrees it's time to put some parameters around this.

• Don't worry about things over which you have no control.  The speed of a DCOM call is something you have no control over, neither is the time required to create a connection for a connection pool, the time required to retrieve session state, nor the time required to process an HTTP request.
• Do worry about things over which you do have control.  While you can't do anything about the speed of a DCOM call, you can control, to an extent, the number of DCOM calls that you make.  Less chattiness is better.  While you do not have control over the speed of the resources, you have control over how effectively you use those resources.

The UAT and Production environments into which your application will eventually move has a myriad of interconnected pieces that, together, create the environment in which your application will exist.  While you cannot control those resources you control how you use them.  <Al Gore>  Ineffective use of resources and our unwavering dependency on technologies that produce greenhouse gases is threatening our livelihood and our very planet.</Al Gore>  Ineffective use of resources in any ecosystem is bad, whether that ecosystem is our planet, or our clustered production environment.  Infinite resources are not available and never will be, but effective use can be made of existing technology:

• Up until the late 1990's the computers on board the Space Shuttle flight deck were Intel 8086 chips.
• The original Xbox had a 733MHz CPU with 64MB of memory and yet it could (still can) outperform peoples desktops.
• Mission critical systems have been designed with, when compared to modern technology, primitive means.
• The first spreadsheet I used, Visicalc, ran on a 1 MHz processor.

All of these examples show that you can make something run well in limited circumstance, but you have to want to.

Identity Theft

I guess I can say that I am now a statistic.  You know, one of those millions of people who have been the victims of identity theft.  Let me tell you the story.

When I got home from work on Monday I noticed that I had supposedly been sending out emails from eBay account at lunch.  Within 15 minutes of the start of the emails I received an "A26 TKO Notice: Restored Account" from eBay UK stating that:

It appears your account was accessed by an unauthorized third party and used to send unsolicited emails to other community members, including email offers to sell items outside of eBay. It does not appear that your account was used to list or bid on any items.

The first thing I tried to do was log into my account.  Well, something either eBay UK did or something the hacker did was change my password.  I tried to enter in my answer to the Secret Question, but that didn't work either as the information on my account had been changed.  Following the various prompts on the eBay site I ended up sending them an email telling them what had happened and what the next step should be.

A couple of hours later I got another email that I apparently sent out eight hours after the first round.  Not content to sit by and wait for the email process to work its way through the system I then started scouring the eBay site for a phone number to call.  You know, that is one of the hardest things I had to do!!!!  I followed all the usual routes and ended up with forms to fill out.  I never did get a phone number, so I had to use their "Live Help" facility.  (My reluctance to go with this approach was due in part to a 45 minute wait on the weekend for "live help" from another company, which never even connected with a human being.)  In the case of eBay, however, the wait was less than two minutes, they told me my position in the queue (started at number 5) and the approximate wait time. 

The person who was on the other end of the chat could have been anyone, anywhere in the world.  The fact of the matter is, they looked at the information on my account, the notes they had sent to me and knew that I needed to talk to the Account Security division.  Within 30 seconds I was "chatting" with someone else who had the power to help.  Two minutes later things were fixed and that included changing the password on my account to a "stronger" password.

Was it brute force hacking of my account and password?  Not if this article is correct.

This particular episode was rather benign in that all that really happened was that some emails got sent and I had to change my password.  It could have been worse.  Much worse.  Think of that the next time you sign up for a web site.  Or, more importantly, think of that the next time you are building an externally facing application.  What are you doing to safeguard the information that you keep on your clients?  What are you doing to protect their safety?  Can you honestly say that you've done your best?

Creative Juices

One of the best things to do, in order to keep the brain alert and creative, is to read different things.  In the same vein, writing is a good therapeutic use of brain cells.  It keeps the neurons working and allows you to be more creative in your job.

To that end, I would like to introduce National Novel Writing Month.  In essence, you are being challenged to create a novel (50,000 words) in less than a month. That's 1500 words per day.  You are considered a "winner" if you actually succeed at getting in 50,000 words.  They don't have to be perfect, you just need to try.

In this case it is definitely the journey which is important, not the final product.  By pushing yourself to reach this goal you are going to be exercising a variety of different areas of your brain.  You will need to be creative to come up with a plot (and subplots), with characters that you empathize with and the words that tie all of this together.

So, how does this help you in the IT field?  I think you would be amazed at how much it will help.  People talk about "thinking outside the box" in order to get something done.  The problem isn't so much thinking outside of the box, it's understanding where the box is in the first place!!!  As you start writing the novel you will be able to see the box that you have created around your novel and this insight, this new vision that you've gained, can help you see the boxes that surround your problems.  Being able to see something is the first step in being able to avoid it or, in this case, think outside of it.

Are you suddenly going to see everything in a new light?  No, but by constantly stretching and pushing your own mind you will see the limitations (the box) that you have put around yourself.

The Dark Side of Objects

The Dark Side of Objects?  (Luke, I am your father.) 

Sometimes you need reins on developers and designers.  Not because they aren't doing a good job, but because if you don't you may end up in a quagmire of objects that no one can understand. Objects are good, but they can be overdone.  Not everything should be an object and not everything lends itself to being objectified.  Sometimes a developers goes too deep when trying to create objects.

When I was learning about objects I had a great mentor who understood the real world boundaries of objects:  when to use them, how to use them and far to decompose them into additional objects.  Shortly after having "seen the light" with regard to objects I was helping a young man (okay, at my age everyone is young) write an application which was actually the sequel to the data entry application I mentioned in the previous note.  He needed to do some funky calculations so he created his own numeric objects.  Instead of using the built in Integer types he decided that he would create his own Number object.  This number object would have a collection of digits  When any calculations needed to be done he would tell one of the digits the operation to be performed and let that digit tell the other digits what to do.  Well, this gave him a method whereby he could perform any simple numeric operation (+-/*) on a number with a precision of his own choosing.  He spent weeks on perfecting this so that his number scheme could handle integers and floating point numbers of any size.  It was truly a work of art. 

And weeks of wasted time.

What he needed to do was multiple two numbers together or add up a series of numbers.  Nothing ever went beyond two decimal points of precision and no amount was greater than one million.  These are all functions built into the darn language and didn't need to be enhanced or made better.  The developer got carried away with objects and objectified everything when it didn't or in this case, shouldn't have been done.

Knowing when to stop using objects is just as important as knowing when to use objects.

Long Running Web Services

OK, the world is moving to web services.  I know that.  You know that.  So what more is there to discuss?  PLENTY!! For instance, how long should it take for a web service to complete?

Well, that's kind of a tricky question.  It basically comes down to "what is the web service doing?"  Some things should come back quickly.  Darn quick, in fact.  For instance, if you ask a web service, "What is the name of the person associated with this identifier?" you should be getting a response back in milliseconds.  If you are asking a web service "What course marks did this student get in high school?" you should be getting a response back in milliseconds.  If you are asking a web service "What are the names of all of the people associated with this school district?" you should be getting a response back in milliseconds.

What?  Getting the names of hundreds, potentially thousands of people, in just milliseconds?  Are you nuts?

Read carefully what I wrote "... getting a response back in milliseconds."  A perfectly valid response is: "Thank you for your request.  It is being processed and the results will be made available at a later date."  Web services should not be long running processes.  If they are long running or have the potential to be long running, then you need to implement some sort of callback mechanism to indicate when processing has finished.  This callback mechanism may be an email, a call to another web service with the results, depositing the results in a queue to be picked up later or even a combination of these methods.  Indeed, there are literally dozens of ways to get the response back to the caller.  What is important to understand is that you do not create a web service that has the potential to run for a long period of time.  Ever.  I'm serious about this one.

Other than the fact that you are probably going to hit the HTTP timeout, COM+ timeout, or cause an excessive number of locks to be held in the database, why other reasons could their be?  Well, imagine from a Denial of Service perspective.  If one call to this web service can generate so much synchronous work, what would 10, 100, or even a 1000 simultaneous calls to this web service due to the underlying server?  Crash it?  Cause it to perform so slowly that everyone gets timed out?  Bring down the back end database?  "But, Don, this is going to be an internal web service only.  What's the problem?"  Depending upon which survey you read, anywhere from 10% to 50% of all attacks on web sites are from insiders.  Imagine a disgruntled employee and what damage he could do to the system with just a little bit of knowledge.

While this topic is ostensibly about web services, we should not create any service (COM+, Web, WCF enabled) that takes a long time to execute.  If you are in the least bit confused about whether something should be synchronous or asynchronous in nature, the odds are it should be asynchronous.  Err on the side of caution.

Hubris

I mentioned a solution architect yesterday and how they needed to be the person with the vision, the person that led the team to final solution.  Well, there is one character trait that a lot of solution architects have that needs to be understood and managed.

Hubris.

Defined as "excessive pride", many solution architects are unwilling to admit they are wrong and will go to any lengths to avoid admitting that they made a mistake.  Sometimes these mistakes can be trivial and sometimes they can be the smallest of decisions that has the biggest of impacts.  Case in point: on a very large project I was working on the solution architect decided that the default order the client had been using for the past 75 years was not right.  So, in the system that we were using he decided that we should change the order of the day, month,and year in the fields that we displayed on the screen.   Yes, that's right, instead of YYMMDD or MMDDYY, he chose a new way of ordering the parts of the date.

This may seem trivial, but we were using a code generator to build the cod and another tool to help create the CICS screens (yes, it was a very old system).  As a result, we had to customize the tool to make it work properly.  OK, it was up to me to make it work properly.  Oh, yay.  Suffice to say that we spent significantly more time on making our dates work out than we would have if we had followed, not just what the client had previously used, but a format that was in use in North America.

No one could convince him he was wrong.  No one at all.  He was convinced that he was right and the rest of the world was wrong.  I know what you're thinking, Don, was he really wrong?  Wasn't this sort of decision part of his job?  I would agree with you, but for those of you old enough to remember, the Y2K scare in the IT field was a big thing.  Imagine a solution architect in the early 90's designing a system where you were unable to enter the century!!!!!  We (okay, me again) had to devise complex schemes that would accurately take a 2 digit year and add the correct century to it.

Solution architects are good, sometimes absolutely necessary, but they are also prone to making very silly mistakes.

The Good Old Days

Why is it that the good stories start with "When I was younger ..."?

Anyway, when I was younger I was working on project to replace an aging mainframe based system with a new web based application.  The web based system utilized the existing database and a new database to create a whole new system that greatly increased the functionality and usability of the entire product.  One of the response time requirements we had was not with regard to individual screens, nor with regard to specific business processes, but with the length of the transaction in the database.  In order to get as much throughput as possible and minimize the amount of locking the requirement was that the new system operate in much the same manner as the old system and provide an average database transaction length of no more than 0.4 seconds.

400 milliseconds.

That is not a lot of time no matter how you look at it.  This 400 millisecond period was the average length over the course of a business day, but did not include any batch or asynchronous processing that occurrred.  This helped us out considerably because we had a lot of short transactions which lowered the average and a smaller number of longer transactions that raised the average.

Man, did we suck when we went live.  Over 2000 milliseconds for the first week and this did not include any of the deadlocks or timeouts that occurred. It took months, actually 18 of them, before we had things down to not just 400 milliseconds, but an average of just over 300 milliseconds. New hardware on the mainframe helped, but so did the fact that we worked really hard at lowering that average and we understood that anything that was going to take a long time was immediately turned into an asynchronous process or even part of a batch run that night.

The users understood this change in philosophy.  In order to get good online processing for everyone involved there was a need to do things asynchronously or in batch.  Processing something in the middle of the day, when everyone is using the system, is not always necessary.  Even if a short turn around is desired, asynchronous processing can be a valuable alternative.

Funny, but this seems remarkably similar to yesterday's note about web services and performance.  See, everything old is new again.  The problem isn't new, but the technology is.  The solution isn't new either, but the will to implement it might be.