The following software is needed to run QueueMetrics:

All said software should be already installed and working on your machine before attempting to install QM.

QM was tested on various distributions of Linux, on Windows 2000/XP and many flavours of Unix.

If you use a RPM-based distribution (e.g. Red-Hat Linux, CentOS, Trixbox) automatic installation using the yum package manager is available.

QueueMetrics is a web based application, so it does not require any software to be installed on the client machine but a fairly modern web browser.

QM is also a multi-user application, meaning that many users can use share the system at the same time; each user is identified by its credentials and not by its physical location.

The following web browsers have been successfully tested with QM:

A number of users have encountered minor annoyances using versions of Firefox before 1.0, mostly on Unix environments.

All versions of Mozilla seem to share a common problem when trying to access multiple user sessions from the same browser instance. You should not therefore use Mozilla to access multiple times to QM; results might be unpredictable.

The most common case is to install QM on the same server running your Asterisk instance. This will be fine in most cases, but in very heavily loaded servers running huge analyses it might be possible that QM will end up competing for RAM, CPU and disk I/O with the Asterisk system. In this case, QM should be installed on a separate server and log files should be replicated (or MySQL storage used, Section 17, “Monitoring clusters with QueueMetrics” ) to minimize impact on the Asterisk server.

In most cases - like mid-sized call centres up to 20 agents on line - it will usually be okay to have everything on the same production server.

It will be fine to have MySQL run on a separate server from the main QM installation.

Installing QM is easy and only takes a few minutes. If you run a RPM -based Linux distribution, see below for automatic installation.

If you encounter any problems with this setup, you should point your browser to http://127.0.0.1:8080/queuemetrics/dbtest for a JDBC tester page.

wget -P /etc/yum.repos.d http://yum.loway.ch/loway.repo
yum install queuemetrics

2.4.2. Using the JDBC tester page

The main source of problems when installing QueueMetrics is to correctly set-up the JDBC connection to the MySQL database. In order to ease the installation process, there is a test page available at the URL http://127.0.0.1:8080/queumetrics/dbtest

The test page will look like the following figure:

If all tests show the OK status, then you are ready to start QueueMetrics. If any test should fail, the web app will tell you the reason of the failure and possible workarounds.

If all tests are Okay, it’s a good idea to click on the link that checks that you have the latest version of the database and updates it in case it’s necessary.

In this case, for example, one of the tests fails:

It is very important that you restart the servlet container after tweaking with the JDBC configuration; otherwise your changes may work in the DBTest page but might not be seen by QueueMetrics.

If you run QueueMetrics on a publicly-accessible machine, you may want to disable the DBtest utility - you can do so by setting a configuration property. This will also inhibit showing technical data in the licence page.

If you choose to update from a previous working version of QueueMetrics:

2.5.2. The database update utility

QueueMetrics ships with an utility that makes it very easy to check and upgrade an existing database to the latest version used by newer versions QueueMetrics. Before running the update utility, make sure you have a backup of the QM database!

You can access it directly pointing your browser to http://127.0.0.1:8080/queuemetrics/dbtest/

Once you access the DB updater, it will check and update the database and then optimize it for maximum access performance. This may take a while if you have a lot of queue_log data loaded into it.

QueueMetrics ships with a limited evaluation key that lets you use the system freely with up to two agents. If you need to evaluate with a larger call center, you will be sent a temporary key that will process as many agents as needed. The same happens when you decide to buy the product.

The key is a single long hexadecimal sequence with minuses in the middle and looks like the following string:

012345678-0987564D-3C082EF8-012345678-0987564D-3C082EF8

The length of the key may vary according to the features needed.

Once Loway Research sends you the temporary or official key, follow these steps to install it:

<init-param>
  <param-name>LICENZA_ARCHITETTURA</param-name>
  <param-value>...........</param-value>
</init-param>

Insert your licence key within the param-value tag, all on one line, exactly as it was sent to you - Save the modified file - Restart your servlet container - Login to QM as usual using your browser - Click on the "Licence" label to see your current licence.

2.6.1. License expiration notification

QueueMetrics will notify users on the Home Page when the license is about to expire; this helps preventing downtime in case a license actually expires without renewal.

	Tip
	It is possible to turn off this additional notification by setting a configuration property.

The default session timeout value for QueueMetrics is 30 minutes. This means that if the application is left idle for more than 30 minutes by a user, the resources associated with the user session are reclaimed and the user session expires. If the user tries to continue, he will have to log on again.

It is possible to change the inactivity period that will result in a session timeout by changing the session-timeout parameter in web.xml, expressed in number of minutes:

<session-config>
  <session-timeout>30</session-timeout>
</session-config>

If changing this parameter, it is important to keep in mind that real-world users will only seldom use the "Log off" button and will usually rely on closing the browser window when they terminate using QueueMetrics. As the amount of data stored in memory by QueueMetrics can be quite large (runs of tens or hundreds of thousand calls are quite common) they will be using up RAM until the session times out.

Each user accessing QM should have his own user and password. The administrator can easily setup multiple accounts from the administrative interface. All user activity is tagged to the user performing it, so it’s a good idea to give an account to each person accessing the system. Accounts can be created, blocked and revoked in a matter of minutes.

Each feature that QM offers is enabled by a special key, as if there was a padlock protecting it from unauthorized access. The administrator gives each user a key ring that specifies which locks the user can open, and therefore what the user can do. A list of keys used in QM is available in Appendix B, Security keys.

To ease the burden of administering multiple users, keys can be grouped into classes. Each class offers the additional advantage of giving the key ring a label, so that it’s easier to see whether an user is an Administrator, a User or an Agent by looking at the label and not at the very keys s/he holds.

Individual keys can be granted or revoked individually to handle special cases, in addition to the ones anyway present in the user’s class. For more information, see Section 18, “Editing QueueMetrics settings”.

A list of default users provided with the standard QM installation and their default passwords can be found in Appendix A, Default users.

To understand QueueMetrics’ memory needs, you must consider that the memory requirements are roughly proportional to the width of the analysis and to the number of required events to track. You may think of it as the number of calls plus the number of agent events, i.e. agents logging on and off and setting pauses on and off.

Calls can be restricted by the queue filter, but all agent events in the required time window are tracked. This gives you an idea of the memory usage.

Though the actual memory requirements depend considerably on the actual content of your analysis and the exact brand and version of Java virtual machine that you are running, you should expect to be possible to track circa 80,000 calls and 40,000 agent events with a standard 64 megabyte Sun Java VM and Tomcat running.

You can of course start your servlet container with more memory in order to allow more room for larger analyses. The standard way in Tomcat is to pass additional Java parameters is to store them in the environment variable JAVA_OPTS before starting Tomcat.

Typing:

JAVA_OPTS="-Xms256M -Xmx512M"
export JAVA_OPTS

And then starting Tomcat will start up a Java virtual machine that has 256 megabytes of available memory and can use up to 512 megabytes. Consider that this memory is shared between all QueueMetrics users and all Java web-apps, so the more the better.

Consider also that Java will never return this memory to the system free memory pool, even when it stops using it. The only way to have this memory returned to the system memory pool is to stop the Java VM and restart it. Therefore, it’s a good idea to perform a scheduled restart of the servlet container, to avoid possible memory leaks and to reclaim now-unused memory to the main pool.

As a last note, the memory footprint of a Java VM may be quite larger than the memory you give it as Java heap space, as it will need RAM space for the VM itself and all its required libraries. Overheads of 50-100 megabytes are not unheard of, depending on the Java Virtual Machine in use.

Disk I/O required by QueueMetrics is directly proportional to the queue_log size as it is read from scratch every time you ask for a full analysis. Even if you only care about what happened yesterday between 3 and 4 PM, your 50-megabyte queue_log will be read entirely. As the queue_log usually don’t get too large even in the largest installations, this is usually a feasible strategy.

The big advantage of using MySQL as a storage medium is that the queue_log rows are indexed when importing, so only relevant rows are extracted and transferred to QueueMetrics. This should speed things up a bit for the largest installations. Also with MySQL you can put the database on an entirely different server in order to avoid disk I/O problems with the local system running Asterisk - see Section 16, “Storing queue data on MySQL” for complete details.