Skip to end of metadata
Go to start of metadata

Release 3.1

Refer to the KC 3.1 Test Drive Online Help topic here:  

Release 2.0

The following printable documentation covers KC 2.0 Requirements for Server, Supporting Application Software, Database, Embedded Mode, Unit Test Suite, and Configuration Parameters:

Release 1.1.1

Requirements for an installation of the Kuali Coeus Research System vary greatly due to institution size and practices. Throughput, archival strategy, logging level, and frequency of log purges are examples of specific factors that lead to variation.

Development environments will use much less in the way of resources (4 GB space, 1+ CPU, and 2 GB memory recommended).

Required Software

The below configuration was scaled to 50 simultaneous users with minimal to no performance degradation.

Component

Memory

CPU

Space

Configuration Recommendations

Notes

Database

2+ GB

2+

8+ GB

 

 

Oracle 10.1+

 

 

 

  • Oracle Memory Manager Settings
    • sga_max_size: 400 MB
    • sga_target_size: 325 MB
    • db_cache_size: 0
    • shared_pool_size: 0
    • java_pool_size: 0
    • large_size: 0
  • init.ora
    • statistics_level=typical

If allocating separate temp space, we recommend you give at least 1GB.

Servlet 2.4 / JSP 2.0 Compatible Servlet Container

2+ GB

2+

40+ GB

  • Tomcat Memory Allocation
    • -XX:MaxPermSize=256m
    • -XX:PermSize=128m
    • -Xms768m
    • -Xmx1g

All of our testing has been on Tomcat 5.5

The below configuration was used to support 10-15 simultaneous users with minimal to no performance degradation. (Upward scaling of this configuration was not tested.)

Component

Memory

CPU

Space

Configuration Recommendations

Notes

Platform

2 GB 667 MHz DDR2 SDRAM

2 GHz Intel Core 2 Duo

150 GB

 

These are also the recommended minimum hardware requirements for developers.

Mac Mini - OS X 10.5.2

 

 

 

 

Database

512 MB

2 GHz Intel Core 2 Duo (shared)

8 GB

 

 

Oracle XE (running under parallels desktop)

 

 

 

 

No special configuration required when using XE for development.

Servlet 2.4 / JSP 2.0 Compatible Servlet Container

 

2 GHz Intel Core 2 Duo (shared)

 

  • Tomcat Memory Allocation
    • -Xms256m
    • -Xmx256m

All of our testing has been on Tomcat 5.5

  • No labels

7 Comments

  1. Anonymous

    Why don't you support an Open Source database?  MySQL or others?

    Seems contradictory to have a community application that uses proprietary database technology.

    1. Check the Mission and then the Technology Proposal pages and you will notice that Kuali Coeus is based on the existing Coeus Electronic Research Administration system which uses Oracle and that MySQL support is planned.

  2. What components of the KC application stack can be run in parallel to allow for load balancing and failover redundancy? Apache?  Tomcat?

  3. According to the KC & COEUS Development Merger Timeline MySQL support was projected to be available in Nov 2009.  Is it safe to assume that the timeline is correct with MySQL support?  This is a follow up to the March, 2009 inquiry above.  Thank you.

  4. Anonymous


    According to what I heard in presentations at Kuali Days VIII they plan to have MySQL support in version 2.0 which was estimated to be available April 2010.

    Chris Thompson

    email: cthompson@moderas.org
    phone: (518) 698-2446
    web: http://www.moderas.org

  5. Anonymous

    The problem here is that MySQL support doesn't really provide the level of sophistication that an enterprise database needs, particularly if Oracle had been used before.  A better choice for a truly open source database to support would be PostgreSQL or Firebird SQL.  Both are truly 'free' (as in beer) open source databases, and have had support of stored procedures, triggers, views, etc. for decades that MySQL is just now starting to offer.  In addition, with MySQL being now owned by Oracle based on their purchase of Sun, its debatable if MySQL will stay open source or somehow be merged into the overall Oracle proprietary software architecture.  I agree entirely with the previous poster that it is contradictory to the entire open source principles to offer the freedom in software source code, yet force a user into a closed or risky database path.  There's just no sense in this given that there are plenty of alternatives out there.

  6. The core of the architecture is database agnostic.  There are certain instances where all databases cannot do things in exactly the same manner.  MySQL (being as previously mentioned one of the least sophisticated of the open source offerings in many respects) provides an excellent "least common denominator" of functionality.  For the portions of database requests that must be handled differently, there are both Oracle (with little doubt the most sophisticated) and MySQL examples from which anyone is free to modify/replace these components with ones conforming to the database of their choice.  It is beyond the scope of the project to provide these components for every available database and this type of customization is more suited as a community contribution, while allowing the core project team to focus on providing more functionality in both the infrastructure and research administration aspects of the software.