Database Reference
In-Depth Information
significantly. If you are using Amazon Web Services, you get a few of these graphs
for free in the Web console just for having an instance running.
When making changes, you should have a control machine as well as an ex-
perimental machine. One method for testing changes is to have a query or a script
run on both the control machine and the experimental machine and compare their
response times. The problem with this method is that when running a query under
normal circumstances, you will likely be using both of the nodes as coordinator
nodes, and the response will be cached for one of the two queries by the node re-
sponsible for the data. If caching isn't on for Cassandra, you may get the file sys-
tem cache. There are a number of variables here, and even though there are ways
around many of them, there might be an easier (and possibly better) way to meas-
ure the effectiveness of your changes within your application or cluster.
Testing in Production
A lot of performance optimization testing can be done in production. Although
making changes in a production environment goes against conventional wisdom
(and might even make you feel a little uneasy), Cassandra is built to be fault toler-
ant. There are obviously certain circumstances when this is not possible, and even
when it is, it should be done with extreme caution. If you have a three-node cluster
with an RF of 1, testing performance changes in production is probably not a good
idea. If you have a six-node cluster with an RF of 2 or more that is not running at
capacity, you can stand to lose a node and recover if you make a mistake. If you
make too big a mistake, it might even be better to pull the node out of the cluster
and start from scratch by re-bootstrapping it.
On the whole, Cassandra is intended to be a resilient system. If one node goes
a little funky and becomes too slow to respond, the FailureDetector will remove it
without your having to do a thing. In this respect, Cassandra can protect you from
yourself. The general idea is that you can take chances within reason as long as
you are aware of what chances you are taking.
Tuning
Cassandra has a lot of knobs that can be twisted and turned to get different per-
formance characteristics for different types of workloads. These settings apply to
all different stages of the architecture and have varying impacts based on the types
of workloads you are seeing.
