Parallel Homepage Rendering Explained

[wallymarx]

Parallel Homepage Rendering is a new feature introduced in the Spring 2010 Stable 2 release. The following information was created by Pat Casey, Service-now.com Principal Architect:

Overview
Home pages are one of the most commonly visited forms within the Service-now.com application because of their ability to collect and display large amounts of information on a single screen. This same information density, however, can mean that homepages render more slowly than most other application forms.

Prior to Spring 2010 Stable 2, a homepage with 4 gauges on it would generally take about four times as long as rendering just one of those gauges as a report. The bigger the home page, the longer it would take to render the homepage.

Starting in Spring 2010 Stable 2, the instance's application server now uses a revised parallel rendering algorithm to speed up home page rendering. In testing, the average performance benefit is between 20% to 50% depending on the page in question, although there are edge cases where there is less improvement.


How Parallel Rendering Works

Typically a homepage (or any form within the instance) is rendered in sequence by a single thread. For a home page with four cells on it, each of which takes 1 second to render, the basic logic would be something like this:

•Time 0: Start rendering cell 0
•Time 1: Cell 0 finishes, start cell 1
•Time 2: Cell 1 finishes, start cell 2
•Time 3: Cell 2 finished, start cell 3
•Time 4: Cell 3 finishes, all done

The cells are rendered one after another, and each waits for the previous cell to complete before beginning.

With the parallel rendering engine enabled, up to four threads are allowed to cooperate on the rendering of a home page. The basic logic in this case would be:

•Time 0: Thread 0 starts cell 0, Thread 1 starts cell 1, Thread 2 starts cell 3, Thread 3 starts cell 4
•Time 1: All four threads are done rendering, collect the output and send it back to the user

Impact

If every cell takes the same amount of time to render and there was no threading overhead, this could theoretically lead to home pages completing in 1/4 the time, but in practice an improvement of 20-50% is more expected.

Parallel rendering will almost always be faster than serial rendering, but there are a couple of cases worth understanding where the benefit might not be obvious

•On a home page where one cell takes dramatically longer than all the other cells, running in parallel won't dramatically change rendering time since we're only as fast as the slowest cell
•On a home page with a large number of "trivial" cells, the overhead of running in parallel tends to offset any performance gain, so 'easy' home pages generally run with similar number before/after
•Typically the best performance improvements are on large home pages where database time is a significant component of rendering time

Parallel rendering generally does neither more nor less work than serial rendering in that the same number of cells are rendered. As such, aggregate application and database server load over time is materially unchanged. However, in certain acute cases application server CPU loading will increase beyond what is observed during a serial load. For instance, if sixteen users all load their homepages simultaneously, the application server CPU will have increased load, but the overall time to return all sixteen home pages will remain roughly constant.

Parallel rendering uses additional database connections above and beyond the usual "one per running transaction" model the instance normally uses, since each rendering thread may have its own open connection. In testing, this has generally not been shown to be a problem, but for instances with unusually small database connection pools, bumping the size of the database connection pool may be necessary to realize any increase in performance increase performance.

Tuning Parameters

These properties can be added to change the parameters of this functionality:

•glide.ui.homepage.parallel -- whether or not parallel rendering should be used (default true)
•glide.ui.homepage.parallelism -- number of threads that should cooperate on rendering any given homepage (default 4)

Supporting wiki page can be found at : http://wiki.service-now.com/index.php?title=Parallel_Homepage_Rendering