These are the architectural components governing Compiere's architecture Performance & Scalability:
Volume:
Compiere handles transaction through its persistence layer which maps, secures and authenticates transaction consistency from dictionary meta data to database
The Compiere persistency engine is optimized for high volume OLTP environments. For example, Compiere uses anonymous keys with the default settings of NUMBER(10) in the database and Java int. This restricts the system to 999 million records per table. If this is not sufficient, you can without code changes switch to Java Big Decimal and increase the scale of the ID column in the database to the maximum supported by the database. Along with performance scalability, Compiere provides rigorous security and roles based access options. For example, the system can restrict users from creating queries with a defined number of records. Long running processes can be executed in background or stared via scheduler thereby optimizing CPU performance.
Database:
Compiere uses a central database and is in production with Oracle Database Grids and database clusters. Compiere manages transactions via a central service, eliminating the need for application developers to manage their transaction. This increases uniformity and stability. Compiere is available on Oracle and EnterpriseDB (PostgreSQL) with prototypes on DB/2 and Microsoft SQL Server.
Application Server:
Compiere can utilize any number of individual application servers, application server clusters and also Oracle Application Server Grids. Each individual application server can be specialized for certain tasks or run in parallel to other application servers (e.g. multiple accounting servers). This allows for the IT infrastructure to scale up with the needs of the business application. In addition to JBoss, Compiere was implemented with the Oracle Application Server and IBM WAS - and the web container also runs on stand alone Tomcat.
Communication:
Compiere uses the most efficient communication protocols for performance, allowing users to use more secure protocols where needed. This implies that Compiere is not bottlenecked by proprietary messages buses or connection pipes thereby allowing scalable integration in a heterogeneous environment.
This information is based on a distributed environment and somewhat based on our own internal assessment (Oracle 10g database, 4GB apps server with Jboss and a client server environment):
Processing 20,000 invoice lines takes about 3 minutes; You can process about 150,000 GL journals per day with no degradation in system performance.
Tests simulated 150 concurrent users w/o problems. I believe the application is scalable to higher number of concurrent users though we don't yet have formal benchmarks. Our production instance runs Compiere, with global users (about 7000 registered) accessing it 24 x 7
So far so good - how can you verify this yourself?
Compiere has a test program, where you can generate any number of products, business partners and orders and even process the orders. So, with very little effort, you can see, how Compiere performs with a few million products, business partners (customers, vendors) and orders.
In your test Tenand, go to the Tenant window and select "Beta functionality" - then (after re-login) start the process "Volume Test". You could even start the process via command line:
org.compiere.tools.VolumeTest noBPartners noProducts noOrders noLinesPerOrder
