OroCRM is a web application which runs on a server. Users interact with the application via a web browser on any computer or mobile device that have access to the internet or the network where the server is hosted.
Resources configuration depends on the data size and number of active users and integrations. Typical setup could be done on a single server with minimum 2 CPU cores, 2GB RAM and a fast hard drive (SSD is recommended). The application could scale to multiple servers and a separate database server based on the expected load.
Linux distributions (RedHat, Ubuntu, Debian, CentOS) are recommended for the production setup. Windows 7 and above and Mac OS X can be used for the development environment.
Oro applications are compatible with most web servers with PHP support, but we recommend the following configuration:
Web server configuration recommendations are well described in Symfony documentation
Few updates to default PHP configuration settings should be done in php.ini for the web server and CLI:
If you have xdebug installed:
By default, max_execution_time value equals 30 seconds. In case of using the Schema update option, it is recommended to increase this value.
Latest version of mariaDB may be used at one’s own risk. Oro applications are not tested with mariaDB and thus the correct operation cannot be guaranteed.
If you are using an HDD instead of an SSD, please pay attention to the following configuration settings:
innodb_file_per_table = 0 wait_timeout = 28800
More optimization recommendations could be found in MySQL official documentation. See [Optimizing InnoDB Disk I/O] for more information.
MySQL Collate and Charset
The default MySQL character set utf8 uses a maximum of three bytes per character and contains only BMP characters. The utf8mb4 character set uses a maximum of four bytes per character and supports supplemental characters (e.g. emojis). It is recommended to use utf8mb4 character set.
Using utf8mb4 might have side effects. MySQL indexes have the default limit of 767 bytes, so any indexed fields with varchar(255) will fail when inserted, because utf8mb4 can have 4 bytes per character (255 * 4 = 1020 bytes), thus the longest data can be 191 (191 * 4 = 764 < 767). To be able to use any 4 byte charset, all indexed varchars should be at most varchar(191). To overcome index size issue, the server can be configured to have a large index size by enabling sysvar_innodb_large_prefix. However, innodb_large_prefix requires some additional settings to work:
- innodb_default_row_format=DYNAMIC (you may also enable it per connection as in the config above)
- innodb_file_per_table=1 (see above performance issues with this setting)
More details about switching to utf8mb4 are available online.
Enterprise Edition Software¶
Enterprise edition is built to support better scale and performance. It is compatible with additional software configuration that allows to achieve these goals.
PostgreSQL uuid-ossp extension should be loaded for proper doctrine’s guid type handling. In order to enable it, connect to the database server and run sql query:
CREATE EXTENSION "uuid-ossp";
- Git is the recommended version control system and could be used for application source code management
- Node.js could be used for more efficient JS assets minification
- Xdebug could be used as the debugger tool but it is recommended only in the development environment
- xdebug.max_nesting_level above 100 should be used
- Tidy PHP extension should be installed to make sure that HTML is correctly converted into a text representation
- Redis – could be used for more efficient application caching. Supported versions of Redis from 2.0 to 3.2
On the client side, Oro applications could be used with most of the graphical browsers on any operating system. Recommended and supported browsers: