系统性能测试的方法:
In my ,
I mentioned the factors that affect web performance. Now that we know
what we need to measure, we come to the harder problem of figuring out
how to measure each of them. There are different methods depending on
how much control you have over the system and the environment it runs
in. Additionally, measuring performance in a test setup may not show
you what real users experience, however it does give you a good
baseline to compare subsequent tests against.
Web, application and database servers
Back
end servers are the easiest to measure because we generally have full
control over the system and the environment it runs in. The set up is
also largely the same in a test and production environment, and by
replaying HTTP logs, it's possible to simulate real user interactions
with the server.
Some of the tools one can use to measure server performance are:
-
- Apache Benchmark. Despite its name, it can be used to test any kind
of HTTP server and not just apache. Nixcraft has a good .
- from HP labs is also a good tool to generate HTTP load on a server. There's an about using it. I prefer httperf because it can be configured to simulate real user load
- Log replaying is a good way to simulate real-user load, and a few people have developed to replay an apache log file. The first one uses httperf under the hood.
- To
measure database performance, we could either put profiling code into
our application itself, and measure how long it takes for our queries
to return under real load conditions, or run benchmarks with the actual
queries that we use. For mysql, the mysql benchmarking suite is useful.
- MySQL Tuner
is another tool that can tell you how your live production server has
been performing though it doesn't give you numbers to quantify
perceived performance. I find it useful to tell me if my server needs
retuning or not.
The above methods can also be used to measure
the performance of remote web service calls, though you may want to
talk to your remote web service provider before doing that.
I won't write any more about these because there are a lot of articles about server side performance measurement on the web.
DNS, CDNs and ISP networks
Measuring
the performance of DNS, CDNs and your user's ISP network is much harder
because you have control over neither the systems nor the environment.
Now I mentioned earlier that DNS is something you can control. I was
referring to your own DNS set up, ie, the hostnames you have and how
they're set up. This is not something we need to measure since no user
will use your DNS server. All users use their ISP's DNS server or
something like OpenDNS and it's the performance of these servers that
we care about.
DNS is the hardest of the lot since the only way
to measure it is to actually put a client application on your users'
machines and have that do the measurement. Unless you have really
friendly users, this isn't possible. It is an important measurement
though. A paper on
[Jung et al., 2002] shows that around 20% of all DNS requests fail.
This in turn adds to the overall perceived latency of a website. In the
absence of an easy way to measure this performance, we'll try and
figure it out as a side-effect of other measurements.
With ISP
networks, the number we really care about is the user's effective
bandwidth, and it isn't hard to measure this. All you need is a
resource of fixed, known size, placed on a server relatively close to
the user. You then measure how long it takes the user to download this
resource and that gives you the user's effective bandwidth. The details
are a little more complicated though, because the first request will
invariably pay the price of DNS lookups and TCP slowstart. This can be
mitigated by using multiple resources and requesting them sequentially.
A second problem is that if the resource is too small, users on high
bandwidth connections may download it too quickly to get a noise-free
measurement. If it is too large, however, users on slow connections may
never comlete the download. We get around this problem by progressively
downloading larger resources until we have a good measure of time. All
of this can be accomplished using javascript on your web page, so it's
an unintrusive way of measuring user bandwidth from the user's point of
view. The number you get will be affected by other things the user is
using the network for. For example, if they're streaming video at the
same time, then bandwidth measured will be lower than it should be. We
could do multiple measurements at different times of day, but there
could be other noise at other times so we can never fully trust the
number we get. We just use it as a ballpark figure.
We can also
use this method to get an order of magnitude of DNS time by comparing
the difference between the first request and the second request for two
uncached resources of the same size. Since only the first pays the
price of a DNS lookup with the ISP, the difference should tell us what
this lookup time is. It will also include some line noise,and there's
also no way for us to tell if the host name lookup was already cached
by the browser or not.
Now to measure bandwidth, we need to get
that resource relatively close to the user so that the bandwidth of the
whole internet doesn't affect it. That's where CDNs come in, and
measuring a CDN's performance is somewhat similar.
We could always use a tool like or to do this measurement for you, or you can hack up a solution yourself in Javascript. You need to figure out three things:
- The IP of the CDN closest to the user
- The user's geo-location which you can figure out from their IP address
- The time it takes to download a resource of known size from this CDN
It's
that first one that's a toughie, but the simplest way to figure it out
is to just ask your CDN provider. Most CDNs also provide you with their
own performance reports.
Page content and user interaction
YSlow, , and
are good tools for measuring and analysing the performance of your page
content. They can measure and analyse your page from your development
environment and suggest improvements. They do not, however, measure
real user perceived performance, however this is something we can do
with Javascript.
We primarily need to measure the time it takes
to download a page and all its components. Additionally we may want to
time how long certain user interactions with the page took. All of
these can be accomplished by reading the Date() object in javascript at
the correct start and end times. What those start and end times are
depend on your application, but we'll look at one possible
implementation in a later post. Once you have the timing information
that you need, it can be sent back to your server using a javascript
beacon. We'll go into more detail about this as well in a later post.
This post has already run longer than I'd hoped for, so I'm going to stop here and will continue next time.
阅读(451) | 评论(0) | 转发(0) |