« February 2004 | Main | April 2004 »
March 24, 2004
postgres furthered...
While not to add more gas to the fire here, Joseph Scott took some time to try and prove or disprove my findings over on his blog. Very cool, minor comments on it though:
- My tests were done using gettimeofday() because each connection was done via the C codebase, not directly in PHP where you also get added overhead of parsing time and connection hashing. As a side, the PHP microtime() function just calls gettimeofday() with a little additional math to micro-ize it ( tv_usec * 1000000.00).
- I wanted to ensure that each connection was being freshly established, not following the PHP hash to see if one connection currently exists or not. To do this any and all connection timings were done in the PHP-4.3.4/ext/pgsql.c:557 or there about. The same was done for the mysql and mysqli systems. This could explain why the significant difference was found in the PHP *_pconnect() tests, which often are essentially the same C code as connect (only one gets added to an internal PHP hash.
I'm not trying to suggest that there are flaws in Joseph's method, rather it's interesting to note despite the differences in approach the results are rather similar (minus the *_pconnect() testing).
Thanks to everyone who have provided constructive criticisms via email and comments.
Posted by Dan at 05:30 AM | Comments (0)
March 22, 2004
postgres ... turtle or hare?
I've been working on some PHP code for use in a postgres database system. The code already supports both MySQL and Postgres, but there is a significant speed delta between the two in very basic things.
Discrepancies between query speeds isn't really what interests me. I know that due to architectural differences, MySQL is going to be slightly faster in a low traffic situation, with my (untested) assumption being that it will degrade to something similar to Postgres performance under high traffic yields. The big issue has become connection time to Postgres via a TCP socket in PHP. Using my own laptop as a test case, I'm running 7.4 postgres, a copy of Apache v1.whatever, and PHP 4.3.4 and receiving connect times of 19.88902* ms or larger (degree of variance is about 3%), while running MySQL the connection time is significantly lower. Why?
Looking through the ext/pgsql PHP code I haven't found any significant deviations that would suggest a reasoning for the time differential. That has left the use of the postgres libraries as the major barrier. Having read through the postgres mailing lists, the biggest suggestion is that I shouldn't be killing my Apache processes too quickly (not a valid reason in this case) to benefit from pconnects (duh). Outside of that I haven't found much of any reasoning or analysis on the subject.
* All times have been created through the addition of gettimeofday() calls before and after the PQconnectdb() call. Calls to zend_hash_update did not significantly influence the timing.
[EDIT: corrected function call name from PGconnectdb to PQconnectdb. Added category]
Posted by Dan at 04:31 AM | Comments (9)
March 18, 2004
Spammy comments
Well joy of joys, I've finally sat down and figured out why my install of MTBlacklist wasn't working. It is now working, thank you said comment spammers for giving me the motivation to make things works. Issue with install was a mis-configuration on my server end, not allowing the pm files to be loaded. This has been corrected, and those responsible have been sacked.
Posted by Dan at 04:23 AM | Comments (0)
March 15, 2004
Leaving on..
To quote a little John Denver right now...
Leaving on a jet plane, don't know when I'll be back again..
I woke up early this morning/last night in hopes of starting to sync my clock to new time zones a bit. Packing is never fun, nor is doing all that laundry I've been putting off.
Spent some time talking with Eric who seems to now be in charge of doing what has tenetaviely been called "Son of EROS", since EROS has now been all but mothballed. We've been working on trying to figure out a good acronym that would spell out ERICOS, since the naming process is one of the hardest this project might take awhile.
Looks like Brian has uploaded a collection of fixes to ext2fs. If you're using it, it might be a good idea to upgrade.
Via jwz a link to Greg Deocamp's amazing site. At one time in the past he was a member of EBN, an amazing piece of multimedia performance art. Worth checking out some of his newer videos he's put together. Unfortunately the site seems to be extrodinairly slow so be patient.
Elivs has left the building...
Posted by Dan at 07:14 AM | Comments (0)
March 10, 2004
More blobs
It seems that yet again, another DB2 user created a patch to support BLOBs in PHP. Unfortunately, the patch uses a type, SQL_BLOB, that only exists in DB2 land. The first reaction of course is, well why not preface the code with #if defined(HAVE_IBM_DB2) #endif markers, creating a DB2 specific area. My real issue with this is that it creates DB2 specific functionality, wherein users will expect to see the same functionality on ABC database as well. Yes the code already has plenty of sections that do this, but I'm attempting to slowly remove such requirements from the codebase.
Actually, I don't blame the DB2 community for using this method. Not only does it seem to be clean and relatively easy, it does work for them. I just believe there has to be a way in pure ODBC language to reproduce this so that all may bask in the glory that is BLOB support.
Posted by Dan at 06:46 AM | Comments (0)