PHP scheduled jobs?
brennan at offwhite.net
Wed Feb 7 02:50:17 CET 2007
Yes, my concern is that parsing the IMAP files is intensive especially
once a mailbox gets big. As I use RC I notice that when it looks for
updates it takes a while. It would be helpful to find a way to speed
up the status update.
What I would like it to do is add the header data to the database
which will be used most of the time so that it is faster. When it
does find new messages in IMAP I would have it return a response right
away asking the client to check again soon for the updates. Then once
the response is sent it would collect the new messages and place the
header data into the database so it is quickly accessible when the
next status update comes in.
I use to do a lot of work in Perl and it did not have a way to release
the current connection and continue with processing without delaying
the client. Can PHP do something like that? Could PHP start an
external process to run the update?
One way to check for updates is to check the files the IMAP server
uses. On FreeBSD with Cyrus IMAP it is located at
/var/spool/imap/users/<username>. That will obviously different for
each IMAP server so it will not be an automatic fix for every
installation. Is there a faster way to check to just ask the IMAP
server if there are new messages? If so the after processing could
preload the header data into the database.
Sorry for the random thoughts...
On 2/6/07, Arnór Heiðar <arnorhs at gmail.com> wrote:
> The default setting in php.ini for a script's max runtime is 30 seconds,
> which doesn't really give that much space..
> What I'd find interesting would be some sort of a permanent connection, . I
> haven't looked much at the IMAP library roundcube uses, but it seems it
> should be easily possible to implement a pconnection to the server... so I'd
> think the idea was doable...
> What's wrong with sending out a request every minute or so? I know a couple
> of sysadmins that would like to keep the connection count down on their
> server... IMAP is server intensive stuff as it is..
> just some thoughts..
> On 2/6/07, Brennan Stehling <brennan at offwhite.net> 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.
> > --
> > Brennan Stehling
> > http://brennan.offwhite.net/blog/
> > http://www.smallsharptools.com/
More information about the Dev