Tony McGuckin – IBM Software Labs and Mark Gargan from IBM Support presented a great p. Xpages performance is all about maximising CPU and Memory consumption. So what is the problem? CPU helps scalability – memory supports contention. Then there is the network – so browsers send and receive requests to a server. Caching can help.

Xpages is based on JavaServerPages – which gives us Stateful Web Application, a component based architecture and six phase lifecycle. Service Side state requires resource. Each Tag in the component can request independent information. This is on top of the css, content and controls them selves.

Six phase life cycle

Request –>  Restore View –> Apply Request Values –> Process Validations –> Update Model –> Invoke App –> Render Response

The first an last phases are System Level responses – the others are specified in your application – its your code. The Render Response and Request can have an impact on performance – it can take time for the browser to render larger components. This can be helped by compression technologies over the wire. The main goal appears to avoid using these phases if they are not required – as this wastes CPU cycles.

Tooling

Tools you can use: -

• Firebug – firefox extension – very useful client side tool
• PageSpeed – another firefox tool
• YSlow – debugger from Yahoo – gives you recommendations
• Speed Tracer – Google Chome – need to enable it – the most powerful client side profiling tool available at the moment
• XPages Profiling Tool – IBM provided – not available yet – sits on the server and monitors load of Xpages – should be on OpenNTF in the next couple of weeks. It allows you to do function - point loading and runtime loading analysis – this allows you to profile and optimise the servers side

Server Side Optimisations

Avoid other lifecycle phases – use Get not Open Page/Post Request – or links with parameters. Gets avoid the other five phases. For example view links create an open page link with a query string. You just get the page you want from the URL you have created – rather than handing a request for a document to the server to figure out which document to return. This can reduce the load on the server – but it also improves the responsiveness of the application. Page Validation is another area – if you want to cancel a page or navigate away from it – you can avoid the other five phases. This is controlled by an option on the event tab of the component action. Partial Execution – restricts the lifecycle execution for that control so you don’t have to process the whole page or view – there is also a ExecID – this allows a control to execute other controls on the form – so it gives you the control over what gets updated.

Data cache optimisation – views are saved in case of a postback request – for example you may want to page through the view. THis ensure that the same data is posted back – its consistent for the user. This has a side effect – data saved consumes memory – there is also extra processing to manage this. There is a dataCache property – which can be set to full , id, or nodata. The id options allows you to minimise this resource by just maintaining enough information to rebuild the view. This needs to be tested – as some use cases will require full datacacheing – but most will only require ids.

Server Page Persistent – by default – 4 xpages are stores to aid retrieval for navigation back. This improves server performance by saving the server from how to re-render those pages. However – there is a cost – it can be paged to memory or disk – the application dictates what this strategy should do. For a high through put – this should probably be disk – or you could put the last page in memory and the rest to disk. This can improve the scalability of applications. This is a database setting.

Browser Side Optimisations

Less is More – more objects means more memory usage. Also break pages up – Header, Navigation, Content, Footer – this allows you to control execution at the appropriate level. Use Get rather than pose. Declaring data sources has an over heard – do not pre-emptively declare them . @Functions may be quicker – display contents of a small view - @DBColumn can be used with <xp: repeat>

use '# reather $ this controls whether its instantiated straight away. Use the correct tags – xp:dive for simple containers – xp:panel for editable data only. there is also a compute: read only attribute. Use ScriptBlocks for client side javascript. Manage your scopes. Use in moderation and use the shortest lifecycle scope. Application Score default 30mins session scope – life of user session – view scope for life of the view.

Network/Web Optimisation

Generate less requests / bandwidth. Cache should be set for long period (365 days is default). Images – JPEG for detailed images – PNG for simple. GZIP does not help. CSS use external styling – this allows it be cached –. Combine CSS – larger is better – don’t use complex ids. CSS Sprites – background images can be combined – reduces the network requests.

The guys gave a very compelling  demonstration showed an optimised site required 7 requests and 281 ms rather than 17 requests and 830 ms. The page was more responsive – and the server didn’t get stressed. The takeway from this is that optimising XPages applications is a critical part of any application development cycle – you can really affect user experience and server scalability with this technology by poor application design or optimisation.

Mark Dixon