PHP scheduled jobs?

[Brennan Stehling]

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 at 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 at gmail.com <mailto:estadtherr at gmail.com>
>


-- 
Brennan Stehling
http://brennan.offwhite.net/blog/
http://www.smallsharptools.com/