目次を表示

CTE015 – Subscribe to the LANSA Image

Objectives

In this exercise you will subscribe to the LANSA Image in the AWS Marketplace so that the LANSA Stack may use that image. This image is called an Amazon Machine Image or AMI.

Note 1: This step is not required when using the LANSA Product Centre AWS account.

Before You Begin

Obtain access to the AWS console to use AWS Marketplace

Review the performance and pricing examples provided below.

LANSA WAM Performance and Pricing Guidelines

The Cloud Formation template instantiates a number of AWS resources into the LANSA Stack. There are a myriad number of ways you may configure your Stack but here are a few examples from which you may calculate approximately how much your stack will cost per hour.

• A rule of thumb is that each m3.medium Web server may handle 10 concurrent users.

• Keep the maximum CPU % utilization below 80%. Add more webservers if its greater than this.

• When the CPU % utilization is below 50%, the average response time will depend on the RDS instance type.

• And your application will perform differently...maybe radically differently. Its very important to load test your application. The Cloud makes this easy to do. So do it!

• A multi-AZ deployment is the recommended architecture so that there are the fewest single points of failure. The cost is 20% slower performance as half the transactions must travel outside the datacentre (AZ) to the other AZ to connect to the RDS. Although thats not strictly true... the same performance may be achieved by using more EC2 instances or a larger RDS instance and thus the cost of fault tolerance is increased hourly charges.

• Adding in a Multi-AZ RDS may slow it further as the RDS must take time to keep the Slave up to date.

• Its useful to keep the EC2 instance type small so that scaling out may be more finely adjusted. The EC2 instance type size may need to be increased if the CPU requirement for typical transactions is higher than the benchmark test. This is where its very useful to be using a load testing tool which mimics your expected transaction workload. You can gain insights ahead of time as to how your application may behave under various loads. And you may easily adjust the instance sizes to gauge the best combination for your application's needs.

• Starting many instances at once takes much longer to complete the MSI install as the DB access part has contention from so many instances publishing weblets at once. Its best not to do this. Specify 1 or 2 web servers and use the auto scaling group to scale up more instances as necessary. 

• Its very important to ensure that all instances have reached a steady state CPU % of 0 before using the instances. Use the AWS console to list in created time order, then select the last 12 or so and graph the CPU time - click on the small image to get more detail.

• micro instances e.g. t2.micro are a good solution if the application load is sporadic.

Benchmark Configuration

The following describes the benchmark configuration, unless otherwise noted below.

• AMI : LANSA Web Server 20150216-2103 (ami-992452a3)

• Windows Server 2012 R2 with all Windows updates applied

• Multi AZ Auto Scaling Group 

• SQL Server Web 11.00.2100.60.v1, Single AZ

• LANSA performance improvements in V14. 

• Tested 12th March 2015 with a beta version of Visual LANSA V14. 

• AWS Region ap-southeast-2 (Sydney), unless otherwise stated.

• Load test tool Loadster Workbench 3.5.6 running in 5 Regions - Virginia, Singapore, Ireland, Brazil, Sydney

• Benchmark includes select, insert, update and delete transactions with appropriate delays between transactions for each user.

• The Base Cost column provides indicative pricing. Only the EC2 instances and the RDS instance are included in the cost. There are other charges which are generally a small percentage of these costs which you will incur. You should monitor the costs closely to ensure its within your budgetary constraints. RDS costs do not include data storage costs and, in particular, neither Provisioned IOPS increased charges. Auto scaling may also increase the number of web servers running to handle an increased load, further increasing the costs.

Note that little difference was seen between db.m3.large and db.m3.xlarge for the benchmark. So this would indicate that its not worth spending extra for db.m3.xlarge. Its unclear as to why this is so and why moving from db.m3.large to db.m3.2xlarge which is 4 times the price yet gives 6 times the performance. If the instance types are compared, apart from doubling CPU and memory for each step, db.m3.2xlarge has High network performance. So it seems that this is the factor which allows the dramatic improvement in throughput for db.m3.2xlarge. Of course this comment is purely in the context of this benchmark. Another application may experience different behavior.

目次を表示