Database Reference
In-Depth Information
80/20 read/write ratio as shown in Figs.
6.5
-
6.7
. Hence, it is a good strategy to
distribute replicated slaves to places that are close to users to improve end-to-end
throughput.
The performance variation of instances is another factor that needs to be
considered when deploying a database in the cloud. For throughput trends of 1 slave
at 50/50 read/write ratio with configurations of different zones and different regions,
respectively, if the configuration of locations is the only factor, it is expected that the
maximum throughput in different zones in Fig.
6.3
would be larger than the one in
different regions in Fig.
6.4
. However, the main reason of throughput difference here
is caused by the performance variation of instances rather than the configuration of
the locations. The 1
st
slave from the same zone runs on top of a physical machine
with an Intel Xeon E5430 2.66 GHz CPU. While another 1
st
slave from different
zones is deployed in a physical machine powered by an Intel Xeon E5507 2.27 GHz
CPU. Because of the performance differences between physical CPUs, the slave
from the same zone performs better than the one from different zones. Previous
research indicated that the coefficient of variation of CPU of small instances is
21% [
208
]. Therefore, it is a good strategy to validate the instance performance
before deploying applications into the cloud, as poor-performing instances are
launched randomly and can largely affect application performance.
Replication Delay
Figure
6.8
-
6.13
show the trends of the average relative replication delay for up to
4 and 11 slaves with mixed configurations of three locations and two read/write
ratios. The results of both figures imply that the impact of the configurations of
the geographical locations on replication delay is less important than that from
the workload characteristics. The trends of the average relative replication delay
respond to an increasing workload and an increasing number of virtualized database
replica servers. For most cases, with the number of virtualized database replica
servers being kept constant, the average relative replication delay surges along
with an increasing workload. Because an increasing workload leads to more read
and write operations sent to the slaves and the master database, respectively, the
increasing read operations result in a higher resource demand on every slave, while
the increasing write operations on the master database leads to, indirectly, increasing
resource demand on slaves as more writesets are propagated to be committed on
slaves. The two increasing demands push resource contention higher, resulting in
the delay of committing writesets which subsequently increasing replication delay.
Similarly, the average relative replication delay decreases along with an increasing
number of replica servers as adding a new slave leads to a reduction in the resource
contention and hence decreasing the replication delay. The configuration of the
geographic location of the slaves play a less significant role in affecting replication
delay, in comparison to the change of the workload characteristics. We measured
the 1/2 round-trip time between the master in
us-west-1a
and the slave that uses
