Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Optimizing Your Cloud Applications in RightScale


Published on

RightScale User Conference NYC 2011 -

Rafael Saavedra - VP Engineering, RightScale

Performance tuning applications in the public cloud is both easier and harder than on your own server hardware. It's much easier to scale up and scale out in the cloud but you generally don't have much (if any) control over the hardware. With public cloud, you take the building blocks offered by the cloud infrastructure and design the application architecture to scale based on the capacity planning requirements and scalability testing results. In this session, we'll talk through our experiences scaling and performance tuning the RightScale platform in the cloud and share tips for sizing, auto-scaling, monitoring, and troubleshooting large-scale cloud deployments.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Optimizing Your Cloud Applications in RightScale

  1. 1. Optimizing Your Cloud Applications in RightScale<br />Rafael H. Saavedra - VP Engineering, RightScale<br />June 8th, 2011<br />
  2. 2. Introduction<br />3-tier application architecture<br />Vertical & horizontal scaling<br />RightScale monitoring and cluster graphs<br />New Relic RPM<br />Support for optimizing DB performance<br />Miscellaneous <br />Agenda<br />
  3. 3. Multi-tenancy<br />Shared resource pooling<br />Geo-distribution and ubiquitous network access<br />Service oriented<br />Dynamic resource provisioning<br />Self-organizing<br />Utility based pricing<br />Cloud computing characteristics<br />
  4. 4. No upfront investment<br />Lowering operating costs<br />Highly scalable<br />Easy access<br />Reduces business risk and maintenance costs<br />Cloud computing advantages<br />
  5. 5. 3-tier application architecture<br />Load balancers<br />A farm of application servers<br />Master-slave <br />
  6. 6. Instance size (vertical scaling)<br />Instance autoscaling (horizontal scaling)<br />Server arrays<br />RightScale support for performance optimization<br />ServerTemplates are configured to capture performance data<br />CollectdRightScripts<br />Hardware & OS monitoring data<br />Specialized plugins – MySQL, HAProxy, Apache, NgInx, IIS, etc<br />Monitoring graphs: individual, cluster, stacked, heat maps<br />Alerts & escalations<br />New Relic RPM<br />Cloud performance optimization<br />
  7. 7. Compute units vs memory vs cost<br />Scaling up – spectrum of instance sizes<br />
  8. 8. Server arrays provide horizontal scaling <br />
  9. 9. The array scales up or down based on performance votes<br />Tags allow scaling on an arbitrary decision set<br />Decision threshold controls reaction time<br />Sleep time allows new resources to have an impact<br />Scaling can be time dependent<br />Detailed setup instructions:<br />Fast response to changes in load conditions using alerts <br />Allocation of servers to availability zones based on weights<br />Deployment-based so configuration is consistent <br />Arrays can be pre-scaled to support anticipated demand <br />Server arrays provide horizontal scaling <br />
  10. 10. Cluster monitoring<br />Individual graphs<br />Good for a dozen servers<br />Displays all standard graphs with full detail<br />Stacked graphs<br />Displays the contribution of many servers to a total<br />Great to see the sum and variability of activity in a cluster<br />Difficult to make out individual servers<br />Examples: requests/sec, cpu busy cycles, I/O bytes/sec<br />Heat maps<br />Displays a bar for each server<br />Great to see uneven distribution across servers<br />Great to quickly spot performance problems across many servers<br />Difficult to read absolute values or see the total cluster activity<br />
  11. 11. Cluster monitoring<br />Current cluster monitoring: one graph per server<br />
  12. 12. Stacked graphs<br />Each color band shows contribution of one server<br />Servers are stacked on top of one another<br />
  13. 13. Heat maps<br />Each horizontal strip shows one server<br />The color shows how “hot” the server is running<br />
  14. 14. Heat map with 100 servers<br />
  15. 15. Stacked graph of the same 100 servers<br />
  16. 16. Cluster monitoring architecture<br />Architecture<br />Monitoring front-end serverspull data from storage servers<br />Up to 100 servers on one graph(to be increased)<br />monitoring<br />storage<br />servers<br />monitoring<br />front-end<br />servers<br />your servers<br />
  17. 17. Real-Time App Performance Analytics<br />Supports Ruby, PHP, Java & .Net<br />SQL & NoSQL performance<br />Web transaction tracing<br />Performance notifications<br />Availability monitoring<br />Scalability analysis<br />New Relic RPM <br />
  18. 18. New Relic RPM<br />Direct access from RightScale dashboard<br />
  19. 19. New Relic RPM<br />Historical statistics over a period of time<br />
  20. 20. New Relic RPM<br />Distribution of the most time consuming requests<br />
  21. 21. New Relic RPM<br />Statistics about response times from different countries<br />
  22. 22. New Relic RPM<br />Detailed response times by browser<br />
  23. 23. An expensive query<br />The N+1 query problem<br />Finding patterns in similar requests<br />New Relic RPM – 3 Examples<br />
  24. 24. Optimizing DB performance<br />RightScale MySQLServerTemplates<br />Configuration files tailored to instance size<br />innodb_buffer_pool_size<br />key_buffer_size<br />thread_size<br />sort_buffer_size<br />The never ending task of identifying current bottlenecks<br />Disk seeks<br />Performance of disk operations<br />Scale up when working set cannot fit in memory – avoid active swapping<br />Constant monitoring of performance graphs, logs and query<br />Schema considerations<br />
  25. 25. Schema considerations<br />Lookups need to be indexed<br />Sorting requires an index<br />Joins need to be done on indices<br />Become slower as tables grow<br />Compounded indices should be used consistently<br />Do not abuse indices<br />Each index requires a disk write<br />Compact tables if they become fragmented<br />Deleted rows do not remove the corresponding index entries<br />
  26. 26. Monitoring DB performance<br />Standard collectd statistics<br />User vs wait time (disk operations)<br />Performance of disk operations<br />Scale up when working set cannot fit in memory<br />MySQLcollectdplugin<br />Monitor INSERT, SELECT, UPDATE operations<br />The breakdown of read operations can indicate missing indices<br />Monitoring /var/log/mysql-slow.log file<br />Identify slow queries<br />Use MySQL EXPLAIN command to identify query plan<br />
  27. 27. MySQLCollectdPlugin<br />Uses MySQL SHOW STATUS command to collect statistics<br />A large set of counters that are divided into 10 categories<br />Connections<br />IO Requests<br />Select Rates<br />Read Rates<br />Key Rates<br />Commands Rates<br />Query Cache<br />Tables<br />Memory<br />Misc.<br />
  28. 28. MySQLCollectdPlugin<br />Uses MySQL SHOW STATUS command to collect statistics<br />
  29. 29. Mysql-slow.log & explain command<br /># Time: 101006 23:30:11<br /># User@Host: prod[prod] @ domU-12-31-39-0F-D0-C1.compute-1.internal []<br /># Query_time: 7 Lock_time: 0 Rows_sent: 1 Rows_examined: 19785<br />SELECT * FROM `ec2_elastic_ips` WHERE (`ec2_elastic_ips`.ec2_instance_id = 6810144) LIMIT 1;<br />mysql> explain select * FROM `ec2_elastic_ips` WHERE (`ec2_elastic_ips`.ec2_instance_id = 6810144) LIMIT 1 G <br />*************************** 1. row ***************************<br /> id: 1<br />select_type: SIMPLE<br /> table: ec2_elastic_ips<br /> type: ALL<br />possible_keys: NULL<br /> key: NULL<br />key_len: NULL<br /> ref: NULL<br /> rows: 33332<br /> Extra: Using where<br />1 row in set (0.00 sec)<br />
  30. 30. MySQL performance depends on locality<br />Wait time should be minimum when working set fits in memory<br />Performance degrades once wait time is significant<br />wait time insignificant<br />user time dominates<br />
  31. 31. MySQL reads graphs<br />Read-random-next represents a table scan<br />Read-next represents an index scan<br />
  32. 32. Misc load testing using httperf<br />RightScale provides ServerTemplates in the marketplace<br /><br />Tutorial on httperf setup and configuration<br /><br />
  33. 33. Questions?<br />Rafael Saavedra - VP Engineering, RightScale<br />June 8th, 2011<br />