Scotch on the Rocks 2011 (Day 1 PM)

Continuing from my Day 1 AM post, here are some notes from the sessions I attended on the afternoon of Day 1.

Session 4: The Road to Sanity – sorting out your legacy applications

(David Stockton, Intergal)

This session was pretty much a sales pitch for Integral’s suite of products, FusionReactor, FusionDebug and the forthcoming FusionAnalytics.  Some audience members did not seem to be too happy about this, but I found it useful as I don’t have any more than a passing acquaintance with any of these products.   David described how the three products offer differing levels of insight into what’s happening on your ColdFusion or Railo server.

FusionReactor is a server monitor which allows you to monitor your server and identify problems with stack traces.  It can send notifications when problems are detected, and has a crash protection feature which can help keep your server running when it runs out of resources.  There is an plug-in architecture allowing feature such as disk-space monitoring to be added, and an AIR dashboard application.

FusionDebug is a ColdFusion debugger (the fastest available apparently) which allows you debug CF code without having to rely on CFOUTPUT and CFDUMP to see what is going on.  It features things like conditional breakpoints, expression watching and auto-stepping, and works seamlessly with Eclipse-based editors.

FusionAnalytics is an upcoming product focussing more on Business Intelligence information (are you meeting SLA targets for uptime, for example).  It alows for the identification of hotspots and informs capacity planning through the monitoring of resource trends.  Server performance is given a score relative to previous performance, and indications of why the score has changed are given.  It’s possible to drill down into historic issues to see what was going on at the time.

It seems that the pricing for FusionAnalytics has yet to be set, as Intergral were keen to get an indication from attendees of how much they’d be prepared to pay for such a product!

Session 5: Scaling CFML applications

(Gert Franz, Railo)

(The original programme had “What’s coming in Railo 4” in this slot, but I guess that content was shifted to the Day 2 Keynote.  From my point of view this was actually a more interesting topic)

When thinking about scalability, there is often an assumption that clustering is the answer. Gert’s experience is that this is not always the case.  His advice boils down to: tune your applications first, then cluster but only if you really have to.  Clustering can introduce extra difficulties such as session management, additional single points of failure and file synchronisation).

When troubleshooting performance, first look at the application as that’s often where the problem lies.  Gert suggested considering the following:

  • Is a framework in use? – they often contain much general purpose code that may be unnecessary
  • Does the application do unecessary things
    • not caching
    • retrieving rows and columns from the database that are not needed
  • Use of Query of Queries – no optimization/indexing so performance can be poor
    • If Q of Q must be used, do integer comparisons first

Outside of the application, consider JVM tuning and patches, both of which can bring performance improvements.  Generally though, prevention is better than cure so when coding:

  • Don’t do stuff you don’t need to
  • Use caching
  • Consider noSQL databases
  • Index your database
  • Use struct caching rather than query caching

In certain circumstances, clustering might be inevitable (If the SLA mandates it or if high availability is required), but it may not always be possible (dependencies on external resources, Access databases!).

Gert then ran through some of the possible clustering scenarios (What is clustered – webserver? app server? database?  What type of clustering – elastic, static or implicit) and their pros and cons.  He suggested that where possible several small instances perform better than one large one, and threw in the idea of virtual servers.  There are a lot of possibilities in this area!

Finally, Gert ran through some of the potential pitfalls of clustering, including:

  • Concurrency  – sessions, locking, database records, race conditions
  • File storage
  • Configuration synchronisation
  • Context related files (a Railo issue only?)

I left this session with a few good ideas on performance tuning, but a feeling that I wouldn’t want to have to specify a clustered solution due to the multitude of  different options available.

Session 6: The Pen is Mightier than the Keyboard

(Robert Rawlins, Weboffins)

This was apparently Robert’s first conference presentation, though if he hadn’t mentioned it, I’d never have known. He presented with a natural flowing style making good use of visuals to reinforce the points that he was making rather than working through lists of bullet points.  I was reminded of Aral Balkan, who impressed me greatly last year.

Robert started with a comparison of the Toyota Prius and the Volkswagen Golf Bluemotion as an example of why design should not be driven by technology, but by the needs of real users, and went on to say that we need a common means of communicating with those users during the design process.

He outlined his technique of using simple hand-sketched wireframes and storyboards as a tool for user communication.  These can be quick and easy to create, and invite discussion and facilitate evolution.  The hope is that users will feel less inhibited from commenting on a hand-drawn sketch than something that looks like it has taken weeks to produce.  Rob showed an example of a storyboard from the movie Taxi Driver to illustrate that great artistic talent is not necessarily required in these early planning stages, and pointed out that stencils are available for a neater finish.  He also noted that when confronted with a blank page, the temptation is to start with logos, titles, navigation and so on.  This should be avoided as these elements are secondary to the design of the user experience.

Follow-up post