Web appliCa TiOns Can grow in fits and starts. Customer
numbers can increase rapidly, and application usage
patterns can vary seasonally. This unpredictability
necessitates an application that is scalable. What is
the best way of achieving such scalability?
This article reveals 20 of the biggest bottlenecks
that reduce and slow down scalability. By ferreting
these out in your environment and applications, and
stamping out the worst offenders, you will be on your
way to hyper growth.
10 obstacles to scaling Performance
Performance is key to Web scalability. if you add
more customers, you want your application to
continue servicing them all equally quickly. Too
much latency will cause users to give up. You can
keep your application’s performance from degrading
by knowing all the ways it can get clogged up and
avoiding those bottlenecks.
1. Two-phase commit. Normally
when data is changed in a database,
it is written both to memory and to
disk. When a commit happens, a relational database makes a commitment
to freeze the data somewhere on real
storage media. Remember, memory
does not survive a crash or reboot.
Even if the data is cached in memory,
the database still has to write it to disk.
MySQL binary logs or Oracle redo logs
fit the bill.
With a MySQL cluster or distributed file system such as Distributed
Replicated Block Device (DRBD) or
Amazon Multi-AZ (Multi-Availability
Zone), a commit occurs not only locally, but also at the remote end. A
two-phase commit means waiting for
an acknowledgment from the far end.
Because of network and other latency,
those commits can be slowed down by
milliseconds, as though all the cars
on a highway were slowed down by
big loads. For those considering using
Multi-AZ or read replicas, the Amazon RDS (Relational Database Service)
use-case comparison at http://www.
ten-use-cases/ will be helpful.
Synchronous replication has these
issues as well; hence, MySQL’s solution is semi-synchronous, which
makes some compromises in a real
2. Insufficient Caching. Caching is
very important at all layers, so where is
the best place to cache: at the browser,
the page, the object, or the database
tier? Let’s work through each of these.
Browser caching might seem out of
reach, until you realize the browser
takes directives from the Web server
and the pages it renders. Therefore,
if the objects contained therein have
longer expire times, the browser will
cache them and will not need to fetch
them again. This is faster for not only
the user, but also the servers hosting
the website, as all returning visitors
will weigh less.
Details about browser caching
are available at http://www.iheavy.
Article development led by
Watch out for these pitfalls that
can prevent Web application scaling.
BY sEan hULL