{"id":1282,"date":"2010-07-01T19:59:28","date_gmt":"2010-07-02T02:59:28","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Polarion-Performance-amp-Scalability\/ba-p\/380645"},"modified":"2026-03-26T05:36:44","modified_gmt":"2026-03-26T09:36:44","slug":"polarion-performance-scalability-2","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/polarion-performance-scalability-2\/","title":{"rendered":"Polarion Performance & Scalability"},"content":{"rendered":"

Introduction<\/H2>
\nThis document will describe the critical performance factors of the Polarion platform, scalability pitfalls and limitations, and recommendations related to capacity-planning your production environment. It will do so based on a few scenarios that are representative of our install base.
\n

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

\"\"<\/P><\/p>\n

Application Architecture<\/H2>
\nPolarion is built on top of a growing 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, because of how 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

\"\"
\n

Platform Components<\/H2>
\n

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

Scalability and Performance<\/H4>
\nThere are no known issues related to Apache as a performance bottleneck for Polarion.
\n

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

Subversion<\/H3>
\nSince its initial launch in 2004, Subversion[i]<\/A> has quickly become the de facto solution for version control in organizations of all sizes around the world. Polarion uses Subversion to store almost all of its configuration and data[ii]<\/A>.
\n

Scalability and Performance<\/H4>
\nOne of Subversion\u2019s key strengths is also its primary performance bottleneck. Subversion uses a strict transactional commit model, which means only one commit transaction can be processed by a repository at one time. This means that if the repository is experiencing heavy write traffic, write requests are queued and processed one at a time.<\/p>\n

That being said, Polarion change sets are typically in the range of kilobytes, which is far from 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 900k revisions[iii]<\/A>.
\n

Recommendations<\/H4>
\nThe key factor is to limit the amount of processing that is done in the various commit hooks on the Subversion repository itself 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.
\n

Lucene<\/H3>
\nPolarion stores all of its  (XML) data (and configuration) in Subversion. This means we have to bridge the gap between not having a database backend, and having to be able to query and quickly retrieve and filter data. Lucene[iv]<\/A> is a powerful indexing framework, and Polarion used it to implement what we affectionately refer to as \u201cThe Index\u201d, which is what the Polarion platform uses for all of its read operations.
\n

Scalability and Performance<\/H4>
\nLucene 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.
\n

Recommendations<\/H4>
\nUsers are encouraged to narrow the scope of their queries to extract more relevant results.
\n

Microsoft Word\/Excel<\/H3>
\nThe one exception to the storage model (XML in Subversion) is the LiveDoc feature, where work items are stored in Word and\/or Excel documents, which are in turn stored in Subversion.
\n

Scalability and Performance<\/H4>
\nBecause to Polarion, the document is a single entity that may contain many work items, every time the document is updated, all of its work items need to be refreshed in the index. As a result, there is a scalability concern related to the number of work items contained in a single LiveDoc Word or Excel document, as well as the overall size of each LiveDoc document file.
\n

Recommendations<\/H4>
\nPolarion recommends that you limit the number of work items in a single LiveDoc to 1000 for Excel, and 500 for Word. The size of any LiveDoc should not exceed 20MB.
\n

Polarion Modules<\/H3>
\n

Scalability and Performance<\/H4>
\nWork items contained in a module are stored separately from other work items in a project, and are treated differently because of the added constraints of the module concept. As a result, modules with more than 1,000 work items are only supported when auto-suspect links are disabled (using the \u201cspeedup\u201d property, see manual for details).
\n

Recommendations<\/H4>
\nNo single module 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.
\n

\"\"<\/P>
\nThe graph points 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 mins, statistically computed there will be 80%probability that less than 5 save operations go in parallel.<\/EM><\/p>\n

 
\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<\/SPAN> and Polarion\u2019s overall memory footprint.
\n

\"\"<\/P><\/p>\n

Reference Customer Installations<\/H3>
\nThe following are examples showing a range of customer installations. Examples are for the purpose of illustrating what kinds of numbers you may need to be thinking of when planning your own installation\u2019s scalability.<\/p>\n

Customer \u201cA\u201d<\/STRONG>
\n