Six simple things you can do to assess saas apps performance

• Tweet

• Tweet

Ben Kepes has an intriguing post about the extent to which you might wish to put a presentation onto one of the web sharing sites like SlideRocket or Slideshare. It’s intriguing because he brings up the thorny problem of access on less than stellar network connections:

A large proportion of presentations are delivered while mobile and hence can’t rely on plentiful internet connectivity. Ah I hear you say, that’s where some sort of offline access such as Google Gears kicks in. Well yes, but unfortunately, this generally breaks the very differentiators that online presentation software vendors use to justify their existence.

Ben is correct in the purest sense of the word but in doing so opens up another can of worms. If you can’t rely on web connectivity while mobile – or as in his case at an upcoming conference – then how can you rely on web apps period? It is one of the things that service application providers don’t often talk about, preferring instead to skew the argument towards the safety measures in place once your data is ‘in flight’ or stored on remote servers. The latter points are often well made but there is no avoiding the fact that if your connection goes down then you’re up the creek without a paddle.

Conversely, this is one of the issues the on premise vendors use to bat the saas providers over the head. But what are the chances you won’t be able to get a decent connection? It’s a topic I’ve mentioned before. I was extolling the virtues of saas to a practice when they told me that their local exchange is due for upgrade sometime in the 2010 timeframe but the max right now is around 4MBPS on download. That sounds awesome but it is often the upload link where the real delays occur. I’m lucky to get 0.25MBPS uplink. Abysmal by today’s standards but that’s life. I can double it up with an extra line and a bit of finagling with the network. Not that’s a long term or even desirable solution but it can work. If I’m traveling around the mountains chance are I’ll hit numerous dead spots on the 3G network. It’s irritating but what can I do when at the mercy of the large network providers? Nothing much it seems. We’re all in that same boat to a greater or lesser extent.

This is where the web apps providers can do a lot of work to make life easier. When I was in London recently, SAP showed me how they’d reduced transaction page load times for Business ByDesign by restricting what’s normally loaded to 10KB. That may mean nothing to most people but even on a terrible hotel connection the service ran very quickly. Part of the trick is to ensure that the machine on which you’ll want the app to run is optimized for that application.

SAP does a credible job in ensuring that its customers get the best performance they can and has given plenty of attention to ensure that in the design stage, developers are always thinking about the customer experience. That sometimes leads to bland looking screens but who cares that much when you’re looking at row and column?

What can you do as a potential user of online services and are worried about performance? There’s a few things, many of which are common to any network whether in-house, at a data center or on the Internet:

1. Optimizing your network connections to the Internet should be job number one. Crabby connections will never allow you to get the best out of any service. If you don’t know how to optimize then get a specialist network engineer on the case because you might have hardware and/or software issues to address.
2. Do some rough calculations to figure out the likely loads you’ll be placing on the network. You can keep at as simple as saying that you’ll have X number of users simultaneously entering Y number of journals/invoices/purchases and that you’ll likely be downloading Z number of bank transaction data items per minute/hour. Get the network engineer to think about what that will mean to network load for your network configuration.
3. Ask your shortlisted accounting service providers to give you assurances about what happens to data in flight if the network goes down on you or you lose the connection in some way. You need to find a rollback position so that you can easily determine what, if any data was lost. Fast operators can get ahead of the network locally so this is an important procedural issue you should consider.
4. Running plenty of control tests to see how quickly screens refresh is a good way of telling you the data has been processed. Not all software is created equal so once you know you’re working with a given baseline connection you should be in a position to check performance in a near standard manner. The good news is that most of the new breed of applications are optimized in some way for performance but you should be able to spot those services which run well and those where you have concerns.
5. Before discarding any potentially poor performers, check to ensure that you’ve been doing things the ‘right’ way. For instance, one system I tested recently had a glitch at login running Firefox 3.5 browser on a Mac. The same problem didn’t exist in Safari webkit.
6. Bring issues up with the provider because there could be something you’re missing – like a tweak to the machine about which you were unaware or, as I found, a browser incompatibility that can be overcome another way.

Anything blindingly obvious I’ve missed?

Of course none of this will avail you anything if the connection suddenly blows up but then data centres and on premise networks are hardly what I would call 100% reliable.

As an aside, I’ve been asked to do a 20-30 second intro at an upcoming conference in San Francisco. Except I’ll be in Spain on a Skype link. I’ve recorded something on video just in case the tech doesn’t cut it. Heh…

Tagged as: google, Mozilla Firefox, Safari, SAP, SlideRocket