Recently I had opportunity to obtain a Gmail account (thanks James). For those you living under a rock it's the latest fad as far as free e-mail is concerned from the same people who brought us Google. The biggest attraction of Gmail is the 1,000 megabyte storage box and saner(?) monetization model that will rely upon the same text ads you may have seen near Google's search results, rather then big bulky banners and/or popup variations. At this time the system is in beta stage, so to get an account you first must be invited by an existing member, but only some members can invite (I am not one of them, so don't bother asking). While my initial plan for this account was to use it as the handler for mail comming to my @php.net account, which now a days comprises mostly of spam and windows viruses. Rather then have my server perform slow analysis on some 2-3 thousand messages, I'd let Google's Gmail do it for me.
Since most of the e-mail going to that account ended up being removed by spam filters, which seem to be quite good the account ended being rather empty, which seems rather wasteful.
So, I've come up with a quick utility to make use of at least a small portion of the available space for backup purposes. To accomplish this task I wrote a small PHP script that can be used to backup files to Gmail and then quickly retrieve them back if and when you need them. I trust that Gmail servers are fairly reliable, and this offers an excellent offsite backup that is extremely fast (I can max out my connection on download 300k/sec) and accessible from anywhere internet is available. Given that you do have 1gig of space quite a few things can be backed up
.
If you want to try it for yourself here is the script itself:
Plain Text Highlighted PHP Source
P.S. The script can probably be optimized to run a little faster by removing regex and making cURL use Keep-Alive, but given that most of the time is spent retrieving the file that is not a big concern at the moment.
Yey! Yet another stable release of FUDforum is out.
A bit more of e-mail fine tuning, this time aimed at making sure all mail clients can properly parsed encoded e-mails. Updated Chinese & French translations and the English translation undergone major grammatical revisions. The poll can now be position anywhere inside the message via the use of the {POLL} tag. Stricter URL session checks etc... All users are encourages to upgrade.
A friend of mine gave me a good idea of making a wrapper around the sendfile() syscall that can be used for very quick data transfers between socket and file descriptors. This syscall in some instances can replace 3 other syscalls (seek, read, write) when you need to write a portion of 1 file into another file. Another words a very neat functionality that I could see myself using in my own applications, such as the message file compactor for FUDforum who's entire job is to seek and write data from one file to another. Further tests have shown that this syscall can also be used to create a much faster copy() that compared to PHP's current copy mechanism is about 2x faster, not a bad improvement if I do say so myself.
However, when it came to testing the code in my primary development box it just would not work, neither would any sendfile example I could find on the net that dealt with transferring data across two files. After much searching on Google, IRC and reviewing the relevant kernel sources I've discovered the problem. It appears that as for Linux kernel 2.6.X sendfile() syscall can only be used to transfer data from a file descriptor to a socket descriptor. The so called "misfeature" of allowing data transfer between two files has been removed, while I could not find any reported problems about it in 2.4.X kernels where it can work with 2 file descriptors. The frustration is further escalated by the fact that sendfile() man page does not acknowledge this little tid-bit of information and only the very recent version even documents the EINVAL error code returned, ARGHH!!!
I am still quite curios as to why this functionality was removed, since even after much searching I was not able to find the reason for it, only the fact that it was removed sometime in the 2.5.X kernel series.
There are a number of tricks that you can use to squeeze the last bit of performance from your scripts. These tricks won't make your applications much faster, but can give you that little edge in performance you may be looking for. More importantly it may give you insight into how PHP internals works allowing you to write code that can be executed in more optimal fashion by the Zend Engine. Please keep in mind that these are not the 1st optimization you should perform. There are some far easier and more performance advantageous tricks, however once those are exhausted and you don't feel like turning to C, these maybe tricks you would want to consider. So, without further ado...
Continue reading "PHP Optimization Tricks"