A rule of thumb.

There has been a long standing rule of thumb when deciding how many instances to give a map service to give optimal performance. Finding this information has sometimes been hard although surprisingly when asked for this information the other day, and failing to find it, I decided to see if it was on the new resource centre. Fortunately the is a page on services performance.image

http://resources.esri.com/enterprisegis/index.cfm?fa=performance.app.services

Here it not only gives the ‘rule of thumb’ for the number of instances for a map service (2.5 * #CPUs) but also a whole series of information about the relative performance of each service type and the factors that will specifically effect the performance of any map service.

With 9.3.1 it becomes a bit easier to automatically determine why a service might be slow either through using the new .MSD service type and the map services publishing toolbar or using the old school mxdperfstat script.

The Perils of Synthetic Tools

Of course any synthetic tool will only give you a level of guidance, any proof would have be got through actually performance testing any solution during development, preferably as early as possible. Such tests and examples are given in two recent ESRI whitepapers, the High-Capacity Map Services: A Use Case with CORINE Land-Cover Data and Best Practices for Creating an ArcGIS Server Web Mapping Application for Municipal/Local Government.

Both documents cover the optimum use of data and their effect on how an application performs. The former in terms of a high scalability site but with information that can be applied to all sites, especially in terms of the recommendations about using file geodatabases for large performance gains. The latter document is important as it shows how a workflow can be mapped to making choices in implementation of an ArcGIS Server architecture, map and geoprocessing services for a medium sized authority.

A Good Guide

Guidance like that available in these two documents and on the Enterprise Resource Centre in general, whilst not indicative of how every site will perform, gives a good grounding in the pitfalls to avoid when translating user requirements to any specific solution architecture. With any performance and architecture though its important that you think of not only the performance now but also the performance implications of any site growing over time. Without any analysis of the capacity requirements of your site, you really don’t know how long your current performance will be applicable. It should be remembered though as is said so eloquently on this Ted Dziuba’s site ‘unless you know what you need to scale to, you can’t even begin to talk about scalability.’

Understanding your current performance requirements and your short to medium term load requirements, and potential spike points, will mean that you can concentrate on worrying about the right parts of your application in terms of performance and stop worrying about those areas that might never become a problem. The book ‘The Art of Capacity Planning’ gives a good overview about how to tackle monitoring your sites performance over time, what to worry about, and when.

97 Things

97 Things CoverI’ve been reading 97 Things Every Software Architect Should Know on and off for the last few months. Not only does the book come with it’s own website where you can make comments on the pearls of wisdom within it’s pages. It also helped me understand that the problems I’ve faced in Architecture over the last year are very common and that architecture whilst not exactly an art will never be a science either. In terms of the content there are three main items that stand out for me within the book.

1) Don’t put your resume ahead of the requirements.

There is sometimes a relentless pressure towards the new with technology. The lure of ‘shiny shiny’ is sometimes too much for both developers and architects and decisions about what to use is often made based upon what is cool rather than what is needed.

Now often new technologies are there to plug known problems or gaps with existing technologies (ArcGIS caching technologies is a good example of a new technology which was introduced for scalability reasons). It is often the case though that there is no good reason to choose a new method over an old method beyond the need to try something new

When evaluating new technologies especially cutting edge ones, you should always be checking out whether it really is the correct solution for your project, battling with new poorly understood and documented technologies might cause more problems than they solve in the long run.

If though a project is going to run a number of years, or have a lifespan which doesn’t include a technical refresh within 5 years or so, then it is always good to evaluate the new as they might still be supported into the future and most issues can be assumed to be quashed in the meantime.

2) It’s never too early to think about performance.

I love this one. When developing software even in a continuous integration environment, it’s all about functional requirements. It’s all about does it do this, does it break when I do that. Often though when all said and done, user acceptance is often done on how the application feels. How long does is take to load? Does the UI look right?

These non-functional requirements are often poorly defined to be tested against. The result, major overruns in projects when the delivered application fails performance or scalability testing during user acceptance. The solution, test performance as near to the start of a project as possible, in order to determine whether the new geoprocessing task you have added to the application is quick enough under load or brings the whole server farm to a grinding halt.

There are a number of ways of doing this, but as there is test driven development to catch bugs, there can be performance driven development to catch performance or architectural issues that might cause problems down the line when the system is delivered. This becomes increasingly important in a system that might be integrated into an enterprise workflow or service bus, where the nature of the performance issue might cause other services to be diminished.

I can never stress to people the importance of performance testing in any project, I can also never stress to people the way that performance testing can become a fixation. There lies a future post I’m afraid!

3) Chances are your biggest problem isn’t technical.

As we know there are many ways to skin a cat (sorry to those cat lovers out there). There are also many ways to deliver technical solutions, there are so many technologies and architectures out there to solve all sorts of problems that there is usually no excuse to not overcoming a technical hitch. What you can’t do is solve all of the non-technical problems as easily.

I mentioned in the last section about non-functional requirements. These are usually the key points that can make or break a solution and are thought up by real people! Sometimes these might be seen as impossible more likely they are seen as not fully defined to deliver too. In the main, all sides of any solution want it to succeed, at the minimum cost in both terms of money and time. If this understanding is the start of every conversation then any of the non-technical or people problems, ‘should’ be easier to solve.

Remember if you see a requirement that says the system ‘should have pretty maps’ run for the hills.

The book has many more great points, many of which I’ve seen happen on projects or will now be especially aware of!