I think I understand what is being discussed here, but I would like to suggest a different way of going about it. The basic problem: IMAP latency is the cause of most of the slowness inherent to roundcube. Roundcube already supports caching, but caching always fails on the first lookup (so whenever you have a new email). In my personal situation, I know it takes about 10 seconds to get a new email with roundcube, and I suspect the IMAP server is at fault. However, I don't control the imap server, I just happen to host my own copy of roundcube linked to it.
What if we have a daemon that runs in the background, checking the server for new emails, and then placing them in the database? Basically, have the database cache update as soon as the information is available, instead of as soon as the information is requested. This could significantly cut down on the latency of roundcube, as my database response is very fast This daemon could even be optional, because if roundcube finds the data isn't in the database as expected, it will proceed to request the data as normal. Through this method, you could hide almost all of the IMAP server latency.
Is this worth the effort to implement? Questionable. You could make the argument that roundcube isn't at fault, that you just need to improve your IMAP server. However, the IT department might think the IMAP performance is adequate because most email clients hide it quite well since the download the messages as soon as they are available, and them store them locally for future access. If roundcube implemented this functionality, it would hide the IMAP performance shortfalls just as well.
Rob
On Tue, 6 Feb 2007 23:16:54 -0600, "Brennan Stehling" brennan@offwhite.net wrote:
Yes, I am missing something for performance. Maybe I could have selected a different DBD implementation when I built Cyrus. But when it does pull messages from the IMAP server I can see a significant delay.
If it is IMAP and it is unavoidable that is fine, but if there is a different way to query the IMAP server from the PHP side which is more efficient I would like to know what could be done. Has anyone else noticed a bit of a performance delay when pulling new messages or is it snappy for everyone?
Brennan
On 2/6/07, Eric Stadtherr estadtherr@gmail.com wrote:
Brennan,
PHP is essentially a CGI scripting language, designed to process HTTP requests and generate responses. Using it to implement some kind of persistent server would be at odds with this design.
If you want a full-time server with durable in-memory state for each client, a JSP/Servlet architecture would be more appropriate. There was a webmail project called JWebMail http://jwebmail.sourceforge.net/ that attempted to do this a few years ago, but I don't think it's been maintained. I started playing with it before I discovered RoundCube, but it was far enough out of date that it would have been a significant effort to pick it up and run with it.
RoundCube already caches messages in MySQL (or another relational database provider) to avoid round trips to the IMAP server. The assumption there is that the MySQL server is located in close proximity with the web server, and therefore has lower communication latency than the (possibly remote) IMAP server.
Finally, attempting to examine the actual mbox or maildir storage from the PHP script would be counterproductive. The raison d'être of the
IMAP
server is to encapsulate the details of the mail storage and retrieval.
Striving for faster performance is an excellent pursuit, but deviating too far from the fundamental architecture of the application has its own cost...
-Eric
Brennan Stehling wrote:
I am not terribly familiar with the lastest in PHP.
One concept I am considering is a way to keep the state current on the server for the webmail user. Currently the PHP code is only run when there is a request, but it would be helpful to have something running on the server continually which can respond to events in real-time.
Here is the idea.
A user logs into the system and that updates a timestamp for their date of last activity. Each time the RC webmail client looks for new messages it would update this timestamp. The service running on the server would be away of active sessions and watch their related IMAP accounts for new activity.
When a new message does arrive it can pull the summary data and place it into the MySQL database so that when the webmail client looks for an update it can just query the database and not MySQL.
And when it does pull the updates from the server it will also just hit the database for the summary data and only use the IMAP server when pulling the full message.
Has anyone seen PHP run on the server-side continually as a service? How would we go about implementing that?
Also, what facilities would PHP have to monitor a directory of files for updates? Will it just have to poll the directories and files for the last update date? Since PHP is largely just meant for web applications I doubt it has a file system monitoring feature.
-- *Eric Stadtherr* estadtherr@gmail.com mailto:estadtherr@gmail.com
-- Brennan Stehling http://brennan.offwhite.net/blog/ http://www.smallsharptools.com/
!DSPAM:1694,45c960e162625986172424!