

Let's make the web faster: Tools to discover and improve your site performance - mace
http://code.google.com/speed/tools.html

======
delano
For performance benchmarking, httperf is at the top of their list. I wouldn't
recommend it but only b/c the configuration parameters are very confusing for
anything but the most simple tests. For quick gut-checks, I prefer siege
(Apache Bench is viable too but it's quirky). For sophisticated or heavy duty
tests, I preferred using Grinder or Tsung (JMeter is a time sink). They also
recommend Pylot which I haven't used but Corey Goldberg is active on Twitter
and other places.

For monitoring they recommend mon.itor.us. They're pretty good but they don't
have a free plan. <http://browsermob.com/> is pretty cool b/c they use real
browsers and they can run your selenium tests.

Some free options for monitoring a single site: <http://wasitup.com>,
<http://pingdom.com> and <http://blamestella.com> (that last one is my product
and all the plans are currently free).

And remember: what you measure you get!

~~~
haribilalic
Mon.itor.us _is_ free. It's the free version of Monitis.

~~~
delano
Yes, but the monitoring interval is 30 minutes which is not useful in most
cases.

------
tyrmored
I've found trying to make your websites faster is kind of a drug. They can
just never be fast enough. You start with Google Page Speed, and before you
know it you're profiling your CSS for slow rules in Safari ...

For most database-driven applications though the real latency is almost always
in the database. You really need something like memcached to totally remove
the bottleneck. I think oftentimes frontend speed demons are trying to answer
the wrong question.

~~~
storborg
I totally agree that it's like a drug... eventually you'll start getting
excited about an request time improvement from 15ms to 10ms by tuning your
memcache client library...

Realistically, though, basic client-side optimization (e.g. expires headers,
minification and concatenation, unobtrusive javascript) is low-hanging
performance fruit that can make a website seem a lot faster with very little
work. Since, tuning a database-driven app takes a lot more skill and time, and
most people haven't even done the client-side stuff, Google focuses on that.

~~~
patio11
Backend tuning also involves a lot of black magic, whereas going down the
YSlow checklist and knocking things off _will_ improve your perceived user
load speed. If you don't gzip, gzip. Bam. Done. It will work. Tuning the
database, on the other hand, crikey -- how many chickens does one have to
sacrifice to become an expert DBA anyhow?

~~~
JoachimSchipper
I think the DB equivalent of turning on gzip is slapping an index on your
primary keys [EDIT: should be "on your primary data column"]. Not exactly
expert material, and quite useful.

~~~
patio11
I am unaware of a commonly used database where primary keys are not indexed by
default. Granted, on a good day I can spell SQL correctly, but it was my
impression that primary keys imply an index by definition. Can someone rectify
my understanding?

~~~
JoachimSchipper
Yeah, you're right. Call it slapping an index on the column holding actual
data. My bad.

(The reason that primary keys tend to be auto-indexed is simple: to verify
uniqueness, you need to check whether the primary key of the record being
inserted is already in any record. Doing this without indices would be
painfully slow.)

------
davidhorne
I agree front end is where the majority of the latency occurs. Luckily there
are automated solutions out there to tweak performance but my favorite is
<http://blaze.io> because they do all the performance adjustments in real-time
and you get the power of a leading CDN.

------
latch
Can someone shed some light on what JSLint has to do with performance?

~~~
aristus
JSMin (and other compressors) often cause terrible, hard-to-understand bugs in
sloppy code. Passing JSLint helps avoid a lot of those problems.

