Improving Performance with RoundCube Webmail

There are many contenders in the market of web-based email clients, few distinguish themselves as much as Roundcube . Although I harbor within myself a profound loathing for any product whose sole star feature is the fact that it uses AJAX, Roundcube has done a great job of using it in such a way that truly streamlines performance and also makes setup a breeze. A similar product by AfterLogic called "MailBee" also markets itself on its AJAX mechanisms however is in my opinion quite a let down in both performance and usability for the 199$ basic edition price tag. Zimbra webmail is also AJAX based however requires at least 1 GB available memory just for the development installation , production requires in upwards of 2GB.

The only issue I found with Roundcube was the performance factor. Here I have gathered together and outlined several tips that helped me get the most out of this webmail suite.

Note to ISPConfig Users: I found that it was best to install roundcube manually and create a manual virtual hosts entry. Otherwise, the database will not be properly configured and virtusertable will not properly be used. Resulting in an inability to save identity information effectively

1. Configuration

Assuming you are installing Roundcube on a different machine as the webserver.

$rcmail_config['enable_caching'] = TRUE;
$rcmail_config['skip_deleted'] = FALSE;


Otherwise it would be best to leave caching off, caching stores all emails in the DB - is best for few accounts and those having difficulty with IMAP connections. - by MarcB

2. Caching Images

Although I haven't personally tried this, here is a patch to place in your images/.htaccess to speed up the loading of images - by seansean


Index: roundcubemail/skins/default/images/.htaccess
===================================================================
--- roundcubemail/skins/default/images/.htaccess (revision 0)
+++ roundcubemail/skins/default/images/.htaccess (revision 0)
@@ -0,0 +1,5 @@
+### activate mod_expires
+ExpiresActive On
+### Expire .gif's 1 day from when they're accessed
+ExpiresByType image/gif A86400
+ExpiresByType image/png A86400
\ No newline at end of file



Although I can't remember where I heard this, but its been said that you can convert the png's to gif files and then save them in gif format as PNG's. Doesn't sound right, but apparently leads to huge speed improvements by bypassing PNG loading

3. Code Optimization

There is a client side optimization and a server side optimization. For the server side , you would use an opcode cache - there is a tutorial for xCache and a tutorial for APC on Ubuntu. If you decide to install APC from source I will say that if you have php5 to run phpize5 instead of phpize and pass php-config5 instead of php-config to ./configure for a modest performance boost.

Javascript Optimization

The total JS for roundcube is absolutely scary - and honestly is my biggest criticism of the package. Although its interface animations and AJAX implementation patterns are implemented quite gracefully, the code and methods used to achieve that effect are another story. The total JS for roundcube is 156kb. You can cut that down to 96KB by using an Javascript Optimization/Compresion utility. I used Dojo ShrinkSafe. Once you get the final file (after adding the app.js, common.js and googiespell.js). You will have to edit some of the source to use the new file (I added common.js last so the result was common.compressed.js). Put this file in lib/js

You can run from the webmail root

grep -R "app.js" .

to find all references to app.js, likewise with common.js
in program/include/main.inc change the lines

$OUTPUT->include_script('program/js/common.js');
$OUTPUT->include_script('program/js/app.js');

to

$OUTPUT->include_script('program/js/common.compressed.js');

And finally find all references to googiespell.js using the same command as above and comment them out as it has now been included in common.compressed.js

4. Optimize Apache

If you are running apache, you may want to optimize your server configuration, and also a2enmod (enable the modules) mod_deflate and mod_cache.

5. Optimize your Mail Domain Setup

This got me. Even with all the above modifications , I was still getting 50 seconds to login. I eventually figured it out though, I had given RC the address of my mail server - and I wondered why I couldn't just say localhost to skip name resolution. Then it hit me. Name Resolution. Please ensure that in your /etc/hosts (c:\windows\system32\drivers\etc\hosts) that along with

127.0.0.1 localhost.localdomain www.mydomain.com

That there is also an entry for whatever mail server you are accessing with RC.

127.0.0.1 localhost.localdomain www.mydomain.com mail.mydomain.com

Upon changing that, the login time went from 50.35 seconds to 1.7 seconds

Good Luck

Provider Oriented Architecture vs. Protocol Oriented Architecture Vs. SOA

With all the recent buzz concerning the possible secret malicious and evil intentions of the contact management software Plaxo - I thought it was time to break in with some input on why I believe Plaxo is inherently evil - not in design, nor practice - but in concept. Plaxo is the living embodiment of a "Provider Oriented Architecture" where the benefits surround a single company or provider of a service as opposed to a protocol or actual paradigm of contact management methodology. Instead of converging adherence to a protocol or standard - if they had their way there would be ever increasing conversion rates throughout the market to their specific service.

The evil nature of Plaxo rests in its orientation and intention to draw the market into its domain by getting everyone to contribute to their user-contributed content base and eventually get everyone to use their service - which from a business sense would sound just and fair if only the end uses for this type of content were not so blatantly sick and perverted in concept. No one wishes to say it - but its gotta be said - Plaxo maintains personal contact information for all of its users - although its terms of use may say differently (they are also apt to change at any point in time) what other way is there to make money with thousands upon thousands of users' personal information? Its EVIL!

What I would propose is an open protocol and personal information management paradigm that circumvents the need for any type of corporation centered service to operate - similar to RSS and falling short of the complexities it would take to implement OpenID based solutions. RSS is a "Protocol Oriented Architecture" and has demonstrated its continuing success over the years - it is not a methodology centered around a company - nor is it necessarily solely centered around SOA (at least in the depraved corporate buzz word sense which has been so rampantly abused in recent times) - rather its centered around the fact that it remains malleable for many use-cases beyond the protocol's initial application to news. Likewise - I would propose to create an open identity protocol without all the complexities of OpenID. I was thinking if everyone had an email address - then the provider of the email address could be their authorization provider.

1. User signs up at a provider (e.g. gmail - email providers would be ideal)
   
2. User sets up contact information distribution settings
   

• Public Contact Information - contact-info - User sets up password or public access

This would be for the same applications as plaxo - to get what information user@gmail.com has set up to be public - the information would be requested from "user:contact-info@gmail.com" in either a blank message or protocol formatted message specifying what fields are being requested regardless - only the information user has set to be public will be released.
In the password protected model, the user would provide the password to the requester so that the requester would be able to access the information.

• Private Account Information account-info - User sets up password

For applications where you sign-up for many services - but don't want to fill out information again and again - you could set up multiple tiers for this type of authorization - some tiers releasing specific information - some tiers releasing modified protected information (such as a temporary email address for registration purposes only- integrated with the authorization / email service). The service being signed up for sends a request with the user provided password to "user:account-info@gmail.com".

Benefits of a Protocol through Any Provider Paradigm

By releasing the protocol from the grip of a specific provider, you enable the user to be completely free to go with whatever provider maintains the best implementation of the protocol - its more democratic.
Migrations would be simple - as providing the highest authorization to the new provider to transfer all lower information dissemination tiers.
Service management made easy - User Oriented Services.
Since the end application would be communicating with the identity authorization provider , the provider would have a list of services for which the user is signed up. The user could pipe these services together within his provider's sandbox into new services in the style of. user:mashup@provider.com - alternately (of course this would exactly work on the gmail platform - however might work where a provider also provides hosting for users) user.provider.com/?somemashup

What you could do with a User Centric Protocol Oriented Architecture

What if you were to route their current location service fed from their nextel phone available as a constantly updated JSON latitude longitude feed known as "jps" with a presentation service called "cartographer" which takes latitude and longitude and feeds them to yahoo, live, and google maps. user.provider.com/?jps>latitude,longitude>cartographer to get a current map of the user at any given point in time. The user would have registered their jps service through their user:account-info@provider.com or along the same URL instead of Email paradigm user.provider.com/?account-info - and also registered for cartographer via the same method. Instead of going to cartographer's site or the jps site - the user could go to the mashup and pipe parameters explicitly through the piping service. ?jps>latitude,longitude>cartographer. Optionally, the presentation service could be available as a feed of image urls and could be piped through another service - like a service that pools images from a list of sources (cartographer and flickr) into a flash river animation. user.provider.com/?((jps>latitude,longitude>cartographer>map-url),(flickr>url-stream))>riverpool


Wouldn't that be cool? Wouldn't a protocol oriented internet be cooler - simpler and easier than a venture-capital Plaxo centered internet?