Find and fix 15 performance bottlenecks

Suffering slowdowns? Our experts have the experience to help you find the problem -- and offer a little advice on how to fix it, too

1 2 Page 2
Page 2 of 2

The final, crucial step is to execute a round of stress tests with the new patches in play. Quite often, patches prove problematic only under heavy loads.

No. 11: Keeping your cool

It might seem obvious, but environmental problems in server rooms and wiring closets can have a deleterious affect on overall network performance. Hot servers aren’t happy servers, and the same goes for network hardware. Make sure your datacenter isn’t making the mercury sing, and install environmental sensors to keep it that way.

On a related note, it’s always a good idea to leverage the server-management utilities that may have come with your servers. Dell’s OpenManage and HP’s Insight Manager provide very pertinent information regarding the health and well-being of your server infrastructure, including whether or not it has a fever.

No. 12: Reining in mirroring and replication

Slowdowns often plague enterprises that use mirroring or replication for high availability or disaster recovery between locations. If you have many locations or many database tables -- or a lot of transactions or journaling that needs to stay in sync between multiple locations -- watch out, because the performance loss can be dramatic.

If possible, run your mirroring and replication activity across separate WAN “pipes” to keep it isolated from production traffic. Your network design team can assist with a viable topology. At the same time, go over the configuration (star topology, for example) you intend to use to support mirroring and replication. Vendor representatives and the network design team can provide useful input on constructing a configuration that will prevent network saturation.

Configuration aside, mirroring and replication products -- such as XOsoft’s WANSyncHA Oracle or High Availability Linux Project’s Heartbeat -- usually provide options to control timing and traffic flow between sites. Some products enable you to schedule syncing activity during off hours, whereas others let you activate syncing tasks only if a particular threshold is reached. Use those controls; that’s what they’re there for.

No. 13: 'My cable modem is faster'

A shared T1 was once immeasurably fast to most folks. Now, it’s less than half the bandwidth most of us have at home.

Are users complaining that their broadband hookup at home is faster?  Well, guess what? A cable connection may be just what you need at work. Buying an asynchronous business-class cable circuit to coexist with a T1 can ease the Internet connection burden substantially. Source-routing at the network core directs regular Internet traffic from within the network to the cable connection while pushing higher-priority traffic through the T1 circuit, giving you the best of both worlds.

Traffic-shaping at the Internet circuit is definitely worthwhile, and many firewalls are integrating this capability, removing the need for more hardware. Blocking or limiting applications deemed “frivolous” at the firewall can help, and deploying a proxy server -- even a transparent proxy -- can also be beneficial, albeit a bit of a chore. Implementation of an AUP enforcement product such as Websense can also control unchecked Internet usage.

If your corporate Web site runs within your network, moving it to a colocation or managed-hosting facility might be a viable option to increase throughput of your Internet circuit. Colocation costs are dropping, and monthly rates on servers suitable to run most sites are quite reasonable. Removing that draw from your link may produce noticeable performance improvements. Of course, gathering metrics on your Web site’s used bandwidth is a must before you make any decisions.

No. 14: Estimating future speed

One of the trickier tasks is projecting infrastructure requirements in the face of constantly evolving business demands. Most people start with capacity planning tools, such as TeamQuest’s View and Modeling products. No tool alone, however, can accurately predict the nature of tomorrow’s workload.

A little sleuthing is needed. Put on that detective hat in a sandbox, staging, or fail-over environment and do some proof-of-concept work.

Create a virtualized, grid-type environment and replicate a representative sample of workload. From this exercise you’ll obtain and use numbers to extrapolate the overall change in infrastructure performance if the topology were to undergo a wholesale change. Execute baseline performance tests that detail today’s workload. Then execute load tests that mimic the addition of the expected number of transactions in six months or an increase in the number of users over time.

Even if testing resources are not as plentiful as those found in production, you can still run tests that mimic the type of infrastructure changes required to meet business demands and get reasonably good numbers. With this information you should be able to project when to add resources to keep performance on track.

No. 15: Profiling to maximize performance

Be proactive in preventing performance bottlenecks by including a mandatory profiling step in the latter part of development, specifically during the software lifecycle. Profiling your applications and Web services will uncover whether your code is efficient.

A profiling tool analyzes and provides reporting on a number of the attributes in your code during its run time. Among other things, it can tell you which sections of code are taking the longest, how effectively you are using processor resources, and how your code is using memory, including reporting that illustrates where you may have a memory leak in your code.

If you use any of the major IDEs, such as Visual Studio or WebSphere Studio, profiling tools are included. If your development tools do not currently include profiling facilities, there are a number of third-party offerings, including Compuware’s DevPartner, YourKit, InfraRED, and J-Sprint.

During development, you’ll likely want to execute profiling locally to gain a general understanding of how your code is performing. Although profiling tools may differ slightly in their approach, profiling locally entails starting an agent or collection process on your machine. Then, exercise the application as your users would, stop the agent or collection process, and analyze the results.

If your code will be distributed across multiple platforms, consider profiling in a distributed fashion during the staging process.

To accomplish this, you’ll need to start agents or collection processes on each of the machines where your code will run. After exercising the code, most profiling tools will combine data from all of the agents or collection processes identified in the profiling session. Analyzing the data from all the distributed agents or collection processes will yield an end-to-end illustration of your code’s efficiency. Use that map as a basis for your tweaking, and better performance will result.

Copyright © 2005 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
How to choose a low-code development platform