Live from TSSJS – Testing in the Cloud with Andrew

This afternoon I’m live blogging from TheServerSide Symposium, attending “Breaking all the Rules:  The Myth of Testing and Deployment in the Cloud” presented by fellow CodeRanch Andrew Monkhouse.

1.  CodeRanch History
Andrew opens his talk with a discussion of CodeRanch performance, traffic, and memory usage.  He mentions there have been serious issues in the past that haven’t temporarily brought the performance of the website down to a crawl.  CodeRanch uses a fork of JForum (2008) and staffs around 20 developers among 150 moderators, all volunteer participants, to build a custom community-based forum.

CodeRanch developers use a number of test strategies including smoke tests, load tests, and stress test.

2. Redeploying in the Cloud
The focus of Andrew’s presentation will be to demonstrate how CodeRanch would function in the cloud.  He has allocated a “small EC2 instance” (1.7GB memory, 1 compute unit, moderate I/O performance) within Amazon’s cloud that is useful for quick set up, but extremely small for practical use and reliable testing.

3. Benefits of the Cloud
The cloud provides a relatively clean environment in which it is ‘cheap’ to add extra servers, at least compared to running a local test server which may be allocated for additional processes.  Also, tests can run by anyone, anywhere, which is great for a distributed developer team, since Amazon allows you to assign rights to additional users.

You can easily create, set up, and desotry Amazon Machine Images (AMI), so you do not need to get it right the first time.  Lots of backup storage options, depending on your needs.

4.  Dangers of the Cloud
Testing in the Cloud can be difficult.  First off, it is hard to get absolute numbers because of the nature of the underlying change in hardware happening within the cloud.  Second, calibrating results is difficult.  Also, developers have to remember to shut down servers after they are down with them else other developers will run out of resources.  Finally, network traffic does cost money so testing can be expensive, although hardware is cheaper in cloud.

5.  Test Setup
The performance tests were set up into 3 servers, in part because it turned out to be cost effective to set it up this way based on the individual server options.

  • Application Server running CodeRanch
  • Database Server
  • JMeter Test Server

JMeter was used at the testing suite software given its large variety of features, options, and plugins.

6.  Test Analysis
Andrew discussed some items to keep in mind when testing the server and understanding the results:

  • It is quite possible for the Test Server to have greater load than the Application server, so be sure to monitor all your servers!
  • Try different graphs, they may tell you different things
  • JMeter plugins are your friend, they will help you identify problems with your application server and/or test set up.
  • Don’t forget about ramp up times

7.  Where do we go from here?
Automated weekly performance tests using the latest code base.  Add more stress tests.  Andrew comments there are no plans to move the CodeRanch to the cloud at this time given that we require full-time administrators since we don’t have a dedicated, paid team of administrators.

Conclusion
Andrew presents a compelling argument why you should be testing your applications within the cloud.  It provides a sanitary environment in which to perform a large variety of tests across multiuple servers.  I’ve heard arguments of moving application servers to the cloud, but this is the first time I’ve heard it suggested to migrate all automated testing to the cloud.

Live from TSSJS – Spring Messaging with Mark

I’m live blogging from “Message Driven Architecture with Spring” by Mark Fisher at TheServerSide Java Symposium.  Mark talks about how Spring messaging involved with the idea simple POJOs, similar to JMS.  Mark’s examples involve RabbitMQ, as one of the more recent and powerful messaging providers.  Below are some notes for this talk.

1.  AMQP
Mark introduces Advanced Message Queuing Protocol, AMQP for short, protocol as an alternative to standard JMS messaging but with a richer feature set including an advancing system of binding for filtering/routing of messages.  Also, AMQP templates are very similar to JMS templates.  Mark presented a number of slides with code examples of AMQP using the templates.

2.  MailSender
Mark presents MailSender, which can be used to send simple mail massages. 

3.  Lifecycle Management
The Spring SmartLifeCycle has been created in Spring 3.0 to help facilitate auto-start and graceful shutdown of listeners with the rest of the application.  This feature includes an optionaly isAutoStartup() attribute which can be used, for backwards compatibility and maintenance, to disable this feature.  By graceful shutdown, the components are stopped in the reverse order of startup, as needed.

4.  Task Execution
Create managed and pooled tasks that don’t need to be started manually (a big no-no)

5.  @Async
Async was added in Spring 3.0 that uses the @Async annotation for executor framework.

6.  Task Schedule
Built-in framework in Spring 3.0, no longer requires Quartz scheduling plugins and similar structures.  Supports recurring and cancelable tasks.  The @Scheduled(“*/5 * 9-17 * * ?”) annotation allows developers to build cron-like schedule tasks.  There is also an alternative solution to externalize the schedule information in XML so it’s tied to the code and the code does not require import statements for the annotations.  Finally, it supports meta-annotations that uses the @Scheduled annotation but points to XML reference in another location.

7.  Message Publishing Interceptor
Send message a by-product of another event.

Conclusion
Mark covered a large variety of material in a very short time, so I wasn’t able to write all the important points from his slides.  He did demonstrate a number of really useful features available in Spring 3.0 and showed how messaging in Spring has really grown to a more mature development platform.  He presentation was especially good because he managed to include demonstrations of the code alongside the spec information.

TheServerSide Java Symposium – Preview Week

TheServerSide Java Symposium 2011 Jeanne and I will both be presenting talks at TheServerSide Java Symposium in March. In preparation for the conference, we will be providing sneak peaks of talks this week on the blog.

I’m giving a lecture entitled “GWT Roundup: An Overview of Google’s Web Toolkit and Hybrid Integration” which provides a review of GWT for old and new GWT developers alike. It also covers many of the new features released in GWT 2.0 and 2.1. I will also be speaking as part of a panel hosted by Cameron McKenzie called “Client Side Development Smackdown” .

Jeanne’s presentation is called “Throw Away All The Rules. Now What Process Do You Follow?” and is about what processes are important if you aren’t being forced to follow any. It uses the CodeRanch forum conversion project as an example.

It’s not too late to register for TheServerSide Java Symposium 2011. We hope to see you there!