{"id":862,"date":"2012-06-18T17:30:20","date_gmt":"2012-06-19T00:30:20","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Polarion-Performance-amp-Scalability-2012\/ba-p\/380703"},"modified":"2026-03-26T05:31:53","modified_gmt":"2026-03-26T09:31:53","slug":"polarion-performance-scalability-2012","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/polarion-performance-scalability-2012\/","title":{"rendered":"Polarion Performance & Scalability – 2012"},"content":{"rendered":"

by Nick Entin<\/EM><\/p>\n

Note (2013-04-26): There is an updated version of this article \u00bb<\/SPAN><\/SPAN><\/A><\/SPAN><\/STRONG> <\/EM><\/p>\n

In this article I will describe the critical performance factors of the Polarion platform, scalability pitfalls and limitations, and recommendations related to capacity-planning your production environment, all based on several scenarios that are representative of our install base.<\/p>\n


\n

System Configuration Landscape<\/H2>
\nPolarion is a web-based application. Clients interface with it through a supported web browser. Consequently, Polarion can be accessed via LAN, WAN (e.g. company-internal inter-office networks), Internet or VPN.<\/p>\n

\"Polarion<\/A>
Basic Polarion System Architecture<\/DIV> <\/DIV>
\n

Application Architecture<\/H2>
\nPolarion is built on top of a number of open source frameworks and APIs. All of these components have their own performance and scalability characteristics, only some of which are relevant to Polarion, due to the way these components are used by the Polarion platform. Some factors may not even come into play except in very large, or very heavily stressed environments.<\/p>\n

\"Polarion<\/A>
Polarion Application Architecture<\/DIV> <\/DIV>
\n

Principal Layers<\/H2>
\n
\"Principal<\/A>
Principal Layers<\/DIV> <\/DIV>
\n

Platform Components<\/H2>
\n

Apache HTTP Server<\/H3>
\nApache is the de facto<\/EM> web server solution, rivaled only by IIS on Windows platforms. It is extremely robust, and powers some of the largest web sites on the Internet.<\/p>\n

Scalability and Performance<\/SPAN><\/p>\n

There are no known issues related to Apache as a performance bottleneck for Polarion.<\/p>\n

Recommendations<\/SPAN><\/p>\n

The Polarion installation procedure installs and configures Apache for you. To avoid unnecessary performance degradation or system downtime, it is recommended that you don\u2019t deviate from this configuration unless you have very specific reason for it, and then only after consulting with your Polarion Support Team.<\/p>\n

Polarion also interprets folder permissions in Subversion to determine if a particular user has read and write access to a document or work item. The more complex the access<\/EM> file is, the more time and memory Polarion may take for the processing. If your access<\/EM> file is quite complex (thousands of rules) in handling permissions to sources, and less relevant for Polarion, you may switch off parsing of the file by Polarion.
\n

Subversion (SVN)<\/H3>
\nSince its initial launch in 2004, Subversion<\/A> has quickly become the leading version control solution. It is now widely used in organizations of all sizes worldwide. Polarion uses Subversion to store almost all of its configuration and data. (Exceptions include trend and reporting data, as well as log files.)<\/p>\n

Scalability and Performance<\/SPAN><\/p>\n

One of Subversion\u2019s key strengths is also its primary performance bottleneck. Uploading large change sets to the repository consumes network traffic and data will be queued if there are many requests.<\/p>\n

That said, Polarion change sets are typically in the range of kilobytes, which is far from being heavy lifting for Subversion.<\/p>\n

Subversion has no proven upper limit as far as repository size is concerned. The Apache Foundation uses a single repository for all of its projects (including Subversion itself, as well as the Apache Web Server project), which consists of well over 1300K revisions (as of June 2012 – see http:\/\/svn.apache.org\/repos\/asf\/<\/A>).<\/p>\n

Subversion v1.7.x<\/SPAN><\/p>\n

Apache has released version Subversion 1.7, in which performance was highly optimized by changing the working copy format and using simpler HTTP (sometimes referred to as HTTPv2<\/A>) protocol.<\/p>\n

Since Polarion doesn\u2019t use working copies and connection is practically permanent between Polarion and SVN, those improvements don\u2019t have significant impact on Polarion (tests show 1-5% improvement). Nevertheless, if you also use Polarion\u2019s SVN repository to  host your source code, and your developers frequently access it, then it makes sense to use SVN 1.7.x. This version is now bundled with Polarion.<\/p>\n

External Repositories \u2013 SVN and Git<\/SPAN><\/p>\n

Polarion 2012 offers the possibility to attach multiple source code repositories to one Polarion project. Among supported systems we list Subversion and Git. Those repositories are scanned for new revisions that should be linked to corresponding Work Items for traceability purposes. When a link is recognized, a user may open a corresponding commit via an external SVN or Git browser. A very good connection between Polarion and those repositories is not mandatory \u2013 the slower\/less reliable the connection is between those servers, the longer it will take before linked revisions will be shown in the Polarion UI. However, you\u2019re ensured that nothing gets lost.<\/p>\n

Recommendations<\/SPAN><\/p>\n

The key factor for optimal SVN performance is to limit the amount of processing that is done in the various commit hooks on the Subversion repository itself in order to boost the operations\u2019 performance. Any non-trivial automation should be implemented to run out-of-process of the commit itself whenever and wherever possible.<\/p>\n

Subversion requires ultra-fast access to its file system. Anything other than physically attached storage is strongly discouraged. In other words, the best performance may be only achieved with SVN repository stored on the same server as Polarion or on comparable fast NAS solutions.<\/p>\n

Be aware that Polarion and SVN use a lot of small files, so performance of the disc subsystem is crucial. Also note that operating systems work with caches of the file system, and you need to reserve enough RAM for OS caches related to the file operations. As rule-of-thumb, we recommend to reserve \u00bd of server RAM for Polarion while leaving rest for OS caches if you have more than 8GB RAM available on the server and work with big projects.
\n

Apache Lucene<\/H3>
\nPolarion stores all of its (XML) data, and its configuration in Subversion. This means we have to bridge the gap between not having a database back end, and being able to query and quickly retrieve and filter data. Apache Lucene<\/A> is a powerful indexing framework, and Polarion uses it to implement what we affectionately refer to as “The Index”, which is what the Polarion platform uses for all of its read operations.<\/p>\n

Scalability and Performance<\/SPAN><\/p>\n

Lucene has built-in mechanisms to balance fast in-memory storage with on-disk overflow to limit the memory footprint of larger data sets. Beyond that, there is no known upper limit to what Lucene can handle. It scales in an almost perfectly linear fashion when increasing the number of concurrent requests.<\/p>\n

The critical performance factor for Lucene is the number of returned results. To mitigate this, Polarion makes heavy use of lazy loading whenever possible.<\/p>\n

Recommendations<\/SPAN><\/p>\n

Encourage all users to narrow the scope of their queries to extract more relevant (and therefore a smaller number of) results.
\n

SQL Layer<\/H3>
\nPolarion 2012 introduces a new indexing mechanism, which allows more sophisticated querying, including joined queries and historical search. This mechanism is natively combined with Lucene in such a way that simple queries might be run against Lucene while more complex ones run against the SQL database.<\/p>\n

Scalability and Performance<\/SPAN><\/p>\n

Polarion uses an embedded H2 Database<\/A>, which is proven by the open source community to be fast and reliable SQL storage. It doesn\u2019t add significant footprint to Polarion\u2019s memory consumption, but does add significantly to storage requirements \u2013 approximately 5-10 times more than Lucene takes.<\/p>\n

During initial reindex of the repository after updating an older version to Polarion 2012, database population may take significant time \u2013 as much as 1-2 days, depending on size of repository and how many revisions of Polarion documents and work items already exist in it. This process can be safely interrupted – it will continue automatically after server restart. Before the historical index is fully populated, access to baselines and historical searches may be limited.<\/p>\n

Recommendations<\/SPAN><\/p>\n

Review any Traceability matrices and reports written for Polarion 2011 or previous versions. These can possibly be optimized for better performance using the new SQL support in macro queries on work items, replacing Lucene queries that perform poorly.
\n

LiveDoc\u2122 Documents<\/H3>
\nSince their inception in version 2011, Polarion’s artifact-aware LiveDoc online documents (“Documents”) have gained significant attention in the fields of Requirements Management and Quality Assurance & Testing. They combine the familiarity and ease of use of office documents with the ability to contain granular artifacts like requirements and test cases (“Work Items”) that are tracked and managed with automated process workflow.<\/p>\n

Scalability and Performance<\/SPAN><\/p>\n

Work items contained in a LiveDoc document are stored separately from other work items in a project, and are treated differently because of the added constraints of the LiveDoc concept. As a result, Documents containing less than 5,000 work items are well supported, while exceeding that number might degrade performance significantly.<\/p>\n

Polarion 2012 SR1 addresses several cases better than in previous releases. Performance of server and client in particular is optimized to support up to 1000 comments per document without significant degradation of performance. The release also adds optimized functionality for merging of concurrent modifications to one document, allowing structural changes to be done in different sections of the document without raising an overwrite conflict.<\/p>\n

Recommendations<\/SPAN><\/p>\n

No single Document should contain more than 5,000 Work Items.
\n

Overall Performance and Scalability<\/H2>
\nThis topic needs to be looked at from two separate yet related perspectives: load and volume of data.
\n

Load<\/H3>
\nWhen looking at Polarion as a whole, you will notice it scales almost perfectly linearly on Dual Core-CPU platforms. When moving to 8 CPU cores, the application essentially scales infinitely, for all practical intents and purposes.<\/p>\n

\"Load<\/A><\/p>\n

The graph points out that 80% of save operations with 100 concurrent users actively working with the server will be served in less than 4 secs on one Intel i7 CPU platform. * If there are 100 users changing work items every 5 minutes, statistically computed there will be 80% probability that less than 5 save operations go in parallel.<\/SPAN>
\n

Volume<\/H3>
\nAs long as Polarion\u2019s data remains within the parameters set out earlier in this document, scalability of volume is limited to memory (RAM) consumption, and manifests itself as a largely linear relationship between number of projects in one repository and Polarion\u2019s overall memory footprint.<\/p>\n

\"Volume<\/A><\/p>\n

\"Parallel<\/A>
Parallel Processing<\/DIV> <\/DIV><\/p>\n

Recommendations<\/SPAN><\/p>\n

The amount of work items in the repository has low impact on Polarion’s performance, and scalability is not affected unless you often query all work items at once.<\/p>\n

The number of open projects has a high impact on memory consumption, while project configurations, permissions, roles and other information is kept in memory for performance reasons. We recommend:
\n