Aerospike aer . o . spike [air-oh- spahyk]
noun, 1. tip of a rocket that enhances speed and stability
Aerospike:
Maximizing
Performance
Improving Performance
© 2012 Aerospike. All rights reserved. Confidential Pg. 2
Network
Aerospike Nodes
Clients
Clients:
• CPU
• Network
• Storage
Aerospike Nodes:
• CPU
• Network
• Storage
Network:
• Network throughput
Improving Performance: Client
➤ CPU
 Loads placed on the CPU vary by language and
application. Easily seen through the top command.
For example, if your application creates random
data, this can take a lot of CPU resources to create
the data.
© 2013 Aerospike. All rights reserved. Confidential Pg. 3
Improving Performance: Client
➤ Network
 Number of connections. Some languages do not
relinquish connections easily. Use “netstat” to find
how many connections are open.
 Bandwidth. Use the sar command to find the
bandwidth usage (e.g. “sar –n DEV 10 10”).
 Transactions per second. This is more subtle, but
most servers have a problem exceeding 90,000
transactions per second due to context switching
limitations. This can most easily be seen by using
“top” and hitting the “1” key. If the percentage of
software interrupts is greater than around 30%, you
are probably hitting this limit.
© 2013 Aerospike. All rights reserved. Confidential Pg. 4
Improving Performance: Client
➤ Storage
 Depends on how data is generated, but disk is a
common bottleneck.
 If reading from file, check disk performance
 If reading from database, check on how fast data can be pulled
from the database.
© 2013 Aerospike. All rights reserved. Confidential Pg. 5
Improving Performance: Network
➤ Long delays due to multiple network hops
between client and server.
➤ Saturated network device (switch, router)
These generally require conversations with the
network admin, but are rarely the issue.
© 2013 Aerospike. All rights reserved. Confidential Pg. 6
Improving Performance: Aerospike Node
➤ CPU
 Easily seen through the top command.
Very rarely the issue
© 2013 Aerospike. All rights reserved. Confidential Pg. 7
➤ Network
 Number of connections
 Bandwidth
 Transactions per second
These are as with the client
© 2013 Aerospike. All rights reserved. Confidential Pg. 8
Improving Performance: Aerospike Node
Calculating Bandwidth Requirements for
Replicated Writes
One consideration in estimating network
bandwidth requirements is that writes
are replicated. So the bandwidth
required for writes must be multiplied
by the replication factor (usually 2).
1. Write sent to row master
2. Latch against simultaneous writes
3. Apply write to master memory
4. Apply write synchronously to
replica(s) memory
5. Queue operations to disk
6. Signal completed transaction
7. Master applies conflict resolution
policy – rollback / rollforward
© 2012 Aerospike. All rights reserved. Pg. 9
master replica
➤ Storage
 Check on disk utilization with iostat.
 Check to see what the performance on the SSD is
like with the ACT.
 Sometimes RAID controllers will be saturated. With
many Aerospike use cases, this will happen with
IOPS before bandwidth.
© 2013 Aerospike. All rights reserved. Confidential Pg. 10
Improving Performance: Aerospike Node
There is rarely a single possible solution. The best
choice will vary. Here are some possible
remedies.
➤ Increase the number of nodes/clients
➤ Increase the number of SSDs
➤ Use faster network equipment
➤ Place servers in closer network proximity
➤ Change equipment (e.g. network, RAID controllers)
➤ Balance load across multiple cores
© 2013 Aerospike. All rights reserved. Confidential Pg. 11
Improving Performance: Remedies

Aerospike: Maximizing Performance

  • 1.
    Aerospike aer .o . spike [air-oh- spahyk] noun, 1. tip of a rocket that enhances speed and stability Aerospike: Maximizing Performance
  • 2.
    Improving Performance © 2012Aerospike. All rights reserved. Confidential Pg. 2 Network Aerospike Nodes Clients Clients: • CPU • Network • Storage Aerospike Nodes: • CPU • Network • Storage Network: • Network throughput
  • 3.
    Improving Performance: Client ➤CPU  Loads placed on the CPU vary by language and application. Easily seen through the top command. For example, if your application creates random data, this can take a lot of CPU resources to create the data. © 2013 Aerospike. All rights reserved. Confidential Pg. 3
  • 4.
    Improving Performance: Client ➤Network  Number of connections. Some languages do not relinquish connections easily. Use “netstat” to find how many connections are open.  Bandwidth. Use the sar command to find the bandwidth usage (e.g. “sar –n DEV 10 10”).  Transactions per second. This is more subtle, but most servers have a problem exceeding 90,000 transactions per second due to context switching limitations. This can most easily be seen by using “top” and hitting the “1” key. If the percentage of software interrupts is greater than around 30%, you are probably hitting this limit. © 2013 Aerospike. All rights reserved. Confidential Pg. 4
  • 5.
    Improving Performance: Client ➤Storage  Depends on how data is generated, but disk is a common bottleneck.  If reading from file, check disk performance  If reading from database, check on how fast data can be pulled from the database. © 2013 Aerospike. All rights reserved. Confidential Pg. 5
  • 6.
    Improving Performance: Network ➤Long delays due to multiple network hops between client and server. ➤ Saturated network device (switch, router) These generally require conversations with the network admin, but are rarely the issue. © 2013 Aerospike. All rights reserved. Confidential Pg. 6
  • 7.
    Improving Performance: AerospikeNode ➤ CPU  Easily seen through the top command. Very rarely the issue © 2013 Aerospike. All rights reserved. Confidential Pg. 7
  • 8.
    ➤ Network  Numberof connections  Bandwidth  Transactions per second These are as with the client © 2013 Aerospike. All rights reserved. Confidential Pg. 8 Improving Performance: Aerospike Node
  • 9.
    Calculating Bandwidth Requirementsfor Replicated Writes One consideration in estimating network bandwidth requirements is that writes are replicated. So the bandwidth required for writes must be multiplied by the replication factor (usually 2). 1. Write sent to row master 2. Latch against simultaneous writes 3. Apply write to master memory 4. Apply write synchronously to replica(s) memory 5. Queue operations to disk 6. Signal completed transaction 7. Master applies conflict resolution policy – rollback / rollforward © 2012 Aerospike. All rights reserved. Pg. 9 master replica
  • 10.
    ➤ Storage  Checkon disk utilization with iostat.  Check to see what the performance on the SSD is like with the ACT.  Sometimes RAID controllers will be saturated. With many Aerospike use cases, this will happen with IOPS before bandwidth. © 2013 Aerospike. All rights reserved. Confidential Pg. 10 Improving Performance: Aerospike Node
  • 11.
    There is rarelya single possible solution. The best choice will vary. Here are some possible remedies. ➤ Increase the number of nodes/clients ➤ Increase the number of SSDs ➤ Use faster network equipment ➤ Place servers in closer network proximity ➤ Change equipment (e.g. network, RAID controllers) ➤ Balance load across multiple cores © 2013 Aerospike. All rights reserved. Confidential Pg. 11 Improving Performance: Remedies

Editor's Notes

  • #2 FastestBest uptimePredictable performanceconsistency