Performance

Overview
Tuning

Tuning

Speeding up page loading

HeartCore does not have a timer feature as it is a web application. However, it still needs to control publishing time or other time-related processes. Therefore, it writes current time into a database every time a page is accessed and the page is published at the right time. The database writing process is executed whenever a page is accessed from both user side and administrator side and then the scheduler starts to perform the publishing process. This could cause performance slowdown. Generally, the writing process takes longer than reading process.

HeartCore allows you to disable the database writing process in order to speed up page loading.

Edit the “/config.static.jsp” file and uncomment the "myconfig.setTemp("scheduled_next", "");" line as below.

// Configuration - Features - Publishing

//myconfig.setTemp("scheduled_next", ""); // !!!!! disables scheduled publishing/expiration functionality

↓

// Configuration - Features - Publishing

myconfig.setTemp("scheduled_next", ""); // !!!!! disables scheduled publishing/expiration functionality

The writing process into a database will no longer be executed.However, since the scheduler is now disabled, scheduled publishing is not available. So, you need to setup cron job instead.

Use "wget" to access “/webadmin/publishscheduled.jsp” every minute or every five minutes.

wget http://localhost//webadmin/publishscheduled.jsp

For Windows, please use batch processing.

Database Connection Configuration

HeartCore provides three configuration options for database connection. They vary slightly depending on the OS and language you use, but you can choose from three options: “direct connection”, “{ODBC} {JDBC} connection” and “DataSource connection”.Performance decreases in the following order.

DataSource connection
{ODBC｝｛JDBC｝connection
direct connection

So it is better to use “DataSource connection” if possible. When “DataSource connection” is used, you can enable connection pooling and other controls.“DataSource connection” performs several times better than “direct connection” if they are compared simply.

Fater content saving process

You may feel that saving a content item on the HeartCore administration page is slow. This is because link checking is executed when you try to save it. As default, all the links including both internal and external links used in the content item are to be checked. It is no problem as long as the external links exist, but if one or more of them are broken and no longer exist, the saving process will not be completed until 404 errors return. In some internet connection environment, it will take quite a long time.

To prevent this, edit the “/config.static.jsp” file and uncomment any of the following lines.

//myconfig.setTemp("checklinks_domains", "yourwebsite\\.com");

⇒only check links for a domain name ending with the given regular expression

//myconfig.setTemp("checklinks_domains", "
(yourwebsite\\.com|otherwebsite\\.com|thirdwebsite\\.com)");

⇒only check links for domain names ending with the given regular expression

//myconfig.setTemp("checklinks_domains", "-");

⇒do not check links

Disabling the link checking functionality will drastically reduce the time required to save content items.

Connection pool configuration

This section describes about database connection pooling.Note: The example given here is for reference purpose only and needs to be adjusted to suit your server configuration. This example assumes MySQL database is used. You can modify “web.xml” and “server.xml” files and HeartCore configuration according to the following procedures.

Add the following context element at the bottom of “server.xml” file which is present under Tomcat conf directory.

<Context path="" docBase="ROOT" debug="0" reloadable="true" crossContext="true" allowLinking="true">
<Resource name="jdbc/heartcore" auth="Container" type="javax.sql.DataSource" maxActive="100" 
maxIdle="512" maxWait="10000" username="username" password="password" 
driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://127.0.0.1:3306/DBname?useUnicode=true&   
characterEncoding=UTF-8" removeAbandoned="true" removeAbandonedTimeout="300" 
logAbandoned="true" validationQuery="select 1" testOnBorrow="true" testOnReturn="true" 
testWhileIdle="true" timeBetweenEvictionRunsMillis="10000" minEvictableIdleTimeMillis="60000"/>
</Context>

Please note that you can replace “heartcore” in [Resource name="jdbc/heartcore"] with any name. Also, “username” and “password” should be replaced with proper values required to connect to your database.

Parameter Descriptions
Parameter	Description
Context path=""
docBase="ROOT"	Means the document root is “ROOT” folder
debug="0"	Output information level for debugging
reloadable="true"	Setting this to “true” enables reloading and the changes will be immediately updated.
crossContext="true"	Setting this to “true” enables to access a different context using ServletContext.getContext() method.
allowLinking="true"	Setting this to “true” enables symbolic links./td>
Resource name="jdbc/heartcore"	Java Data Source Name
auth="Container"	Specify whether the web Application code signs on to the corresponding resource manager programmatically, or whether the Container will sign on to the resource manager on behalf of the application.
type="javax.sql.DataSource"	Specify JNDI resource class type, interface type.
maxActive="100"	The maximum number of active connections that can be allocated from this pool at the same time. Setting this to “0” makes it unlimited.
maxIdle="512"	The maximum number of connections that should be kept in the pool at all times. Setting this to “0” makes it unlimited.
maxWait="10000"	The maximum number of milliseconds that the pool will wait (when there are no available connections) for a connection to be returned before throwing an exception. Setting this to “-1” makes it unlimited.
username="meniu"	The connection username to be used to connect to the database
password="menip"	The connection password to be used to connect to the database
driverClassName="com.mysql.jdbc.Driver"	The fully qualified Java class name of the JDBC driver to be used
removeAbandoned="true"	Setting this to "true" can recover db connections from applications that fail to close a connection.
removeAbandonedTimeout="300"	Timeout in seconds before an abandoned(in use) connection can be removed.
logAbandoned="true"	Setting this to “true” enables to log stack traces for application code which abandoned a Connection.
vatddationQuery="select1"	The SQL query that will be used to validate connections from this pool before returning them to the caller. If specified, this query does not have to return any data.
testOnBorrow="true"	The indication of whether objects will be validated before being borrowed from the pool. If the object fails to validate, SQLException will be thrown.
testOnReturn="true"	The indication of whether objects will be validated before being returned to the pool. If the object fails to validate, it will not be stored in the pool and will be dropped.
testWhileIdle="true"	The indication of whether objects will be validated by the idle object evictor (if any). If an object fails to validate, it will be dropped from the pool.
timeBetweenEvictionRunsMiltds="10000"	The number of milliseconds to sleep between runs of the idle connection validation/cleaner thread. It dictates how often idle, abandoned connections are to be checked, and how often idle connections are to be validated.
minEvictableIdleTimeMiltds="60000"	The minimum amount of time an object may sit idle in the pool before it is eligible for eviction.

- Caution -

A library which implements connection pooling like DBCP provides a class with wrapped actual Connection object. When the close() method of the wrapped class object is called, the connection will be returned to the pool without the actual connection being closed. And if there is any unclosed (forgot to call close() method) connection, it will not be returned to the pool. When the maximum number of connections is exceeded, additional requests that require a database connection will be halted until a connection from the pool becomes available. Thus that causes no response. As for unclosed connections, the actual connections will be closed by the finalize method during GC. However, the finalize method is not implemented for DBCP wrapper object and such connections will never be returned to the pool.

- Solution -

DBCP has a mechanism that recovers abandoned connections. If “removerAbandoned” is enabled, a reference to the connection will be stored in a “trace” list when a connection is removed from the pool. And stackTrace information for the connection will be logged. When the number of connections removed from the pool gets close to the “maxActive”value, the thread requiring a connection traces connections which are not used for a certain period of time and returns such connections to the pool by calling close().

Add the following to “ROOT/WEB-INF/web.xml” file.

<resource-ref>
        <description>MySQL Datasource</description>
        <res-ref-name>jdbc/heartcore</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
</resource-ref>

The connection pooling is now enabled.

Configure database connection in HeartCore configuration section.

Go to Configuration > System > Database > Database Connection, and select “MySQL Database Server - Java Data Source” option.

Databse connection options

Lastly, go to Database Connection input field at the top of the page, and change “username”, “password” and data source to the proper values defined in the “server.xml” respectively.

Database connection

Apache-Tomcat integration

You can improve performance regarding Apache-Tomcat integration by editing “server.xml”. Note: The example given here is for reference purpose only and needs to be adjusted to suit your server configuration.

Edit the port=”8009” part.

<Connector port="8009" maxHttpHeaderSize="8192" maxThreads="600" minSpareThreads="25" 
maxSpareThreads="100" enableLookups="false" redirectPort="8443" acceptCount="100" 
connectionTimeout="20000" disableUploadTimeout="true" protocol="AJP/1.3" />

This helps to improve performance.

MySQL tuning

MySQL used to be an open source database software, and two different editions appeared after the acquisition by Oracle. One is free and open source Community Edition and the other is commercial Enterprise Edition. There is basically no distinction between the two, however only Enterprise Edition provides the MySQL thread pool plugin, which is used to maximize performance and reduce overhead. This makes HeartCore performs 20 or 30 percent faster than Community Edition. We recommend you to use commercial Enterprise Edition as it provides support service as well.

Please use InnoDB and add the following thread pool setting to [mysqld] section in [my.cnf] file.