Series:
(Disclaimer: The
manuscript is my personal view and is not affiliated to any groups or
organizations)
As there is no benchmark of various Cloud components as
of yet for your app, it is vital to judge the capacity of different individual
components. One way of choosing components on Azure to start with good capacity
size VMs as an example web servers could start with an A3/4 machine, app servers
with A6/A7, and data repository servers with D4. Note that don’t use basic A’s
as they can’t participate in basic scalability functions such as availability
set. Conspicuously through the usage of dev and test environments the capacity
is already a known factor although with a wide range guesstimate.
Use/setup an environment that looks close to production. Start
testing from bottom layer to top layer. The more granular the test is, the
better the capacity plan (scale unit) is. But this process also takes time and
the level of preparation need not be same
as needed for an on-prem prod deployment where procurement of hardware (for
capacity) relies on these tests.
Prepare a data migration strategy. Though it is not
directly related to the live performance metrics but as a byproduct of the
performance preparation, the strategy would assists in switching live traffic
to Cloud. However, in this preparation phase, you could determine the connectivity
and the network requirement. Check if there is a need to have a temporary network
private link between your existing datacenter (hoster or elsewhere) and Azure.
Check the database performance while importing the data. Scale up or scale out the
database to meet the need. Use monitoring tools (FogLight for Oracle,
etc.) provided by database vendor along with OS tools (sar, iostat, vmstat,
etc.) to determine the capacity. At times you might discover previously
uncovered performance bottlenecks and potential bug. It can be argued if this is
the best opportunity to address them, but at the least log the findings in
backlog. Do a quick explain query to find the importance of the bugs. This
covers the bottom layer.
Prepare a strategy to fine tune the application layer
infrastructure. If you are using a java based app servers (tomcat, jboss,
websphere, weblogic, etc.) keep the same jvm configuration as is. Conduct
an endurance test to find out if the Azure VMs meet the need. Use profilers
(JProfiler, etc.) and OS tools to find out potential bottleneck. Inspect JVM
for potential tuning. Tune up young generation, tenured, and perm space. Tune
up heap space, etc. But with latest JVMs it is often the case that you gain a
little, nothing, and at times deteriorate the performance with custom setting.
Thus one way to start is to tinker the already used jvm args.
Infrastructure for web layer could be tested similarly to
the application layer infrastructure, though the layer is less complex than
that of app layer.
At times conducting autonomously each layer might not be
possible, but do your best you can. Prepare a distributed load test environment
in Azure in the same VNet as the VMs exists. Tools like JMeter, BadBoy, Visual
Load Testing service, Sleneium, HQ (previously Mercury) LoadRunner, etc. or
existing tool set could be used. Keep in mind and take into consideration the
induced latency if the tools are run outside Azure infra.
Get necessary procedural paper work in place to conduct a
load test. Note that Azure might treat load test as DoS as it can’t
differentiate between load test and malicious traffic J
Notes:
1.
Attempt to test infrastructure of each layer
autonomously.
2.
Use vendor specific tools and OS tools.
3.
Catalogue performance bottlenecks and bugs
discovered. Address the critical one right away.
4.
Conduct end to end endurance test.
5.
Prepare load test bed (strive to set that up in
Azure.)
6.
Notify Azure of load testing intention.
7.
Conduct load test.
8.
Fine tune and repeat the steps.
Additional material (don’t get overwhelmed!!! Material
might not add too much of value at this juncture):- Fundamentals of Web Application Performance Testing (http://msdn.microsoft.com/en-us/library/bb924356.aspx).
No comments:
Post a Comment