LAMP with PHP5: When a Singleton is Not Quite a Singleton · 5 September 2007, 21:13
After a few days of puzzling over why my little singleton PHP5 data access layer was continuing to produce leftover database connections and produce more than just one connection (which is what I would expect a Singleton pattern to create!), I learned the following, mostly from this PHP manual page and user comments (one of the best features of the online PHP manual pages!):
http://us.php.net/manual/en/features.persistent-connections.php
- Even with a singleton class and mysql_pconnect, you will have multiple connections open on the server if you use a multi-process web server like Apache (as opposed to a single instance, multi-threaded server like IIS or Apache in it’s multi-threaded worker mode) as MySQL connection links are not shared between web server instances.
It would seem this could somehow be resolved by using shared memory for those connections, but I know that has it’s own problems and adds complexity.
- In your my.cnf file, if you do not set wait_timeout to some reasonably low number of seconds, those leftover persistent connections can hang out for a LOOOOONG time.
— Max Schubert
Have the Spaghetti-ists All Migrated To PHP? · 12 August 2007, 21:32
I have been doing an increasing number of web site development jobs in PHP lately; the vast majority of the jobs have been enhancements to existing sites.
In the late 90’s I did a number of these kinds of jobs for perl/CGI driven sites. Many of them were written in such sloppy / unstructured perl code that I would either end up aborting the job (if the client did not have the money to pay for a full refactoring) or I would rewrite from scratch.
I thought that with PHP the situation might be different since so many things are so easy to do with PHP and surely developers would have more time to focus on program structure / design.
No. Same situation as with perl, I take over many spaghetti code projects and spend time either refactoring or rewriting from scratch. Often clients I work for are unpleasantly surprised to hear that the sites they had made will now cost them even more because the code was not written in a way that would make it easy for someone else to maintain / enhance.
This is not a rant about PHP developers in general; there are many PHP projects, especially on www.sf.net, that are very nicely written and that are easy to maintain and extend.
I guess the bottom line is that some things never change as much as I hope they would as software development ages and matures.
While it is nice to get paid to refactor (I really enjoy refactoring), I would prefer to spend my time developing new features and have refactoring just be a minor part of adding revenue-generating code to a site or project.
— Max Schubert
PHP: Often "lite" Is Just Right · 12 August 2007, 21:02
I have been a software developer for a little over ten years now; in that time I have written software using a wide variety of languages. With most languages, the key to fast success seems to be finding the right (i.e. most widely used, most idiomatic) frameworks or libraries to use.
I find that with PHP I am often developing on memory or I/O starved platforms; for these situations the “right” frameworks tend to be too memory and/or CPU intensive for the hardware (or VPS) that is hosting the application. More often than not in these situations I use an Extreme-style of JIT infrastructure development approach.
For example:
- Create a lightweight DB wrapper class to make DB queries easy
- Create a simple data-holder class to centralize and make retrieving application configuration settings easy.
- Create a lightweight display framework that separates the app header, footer, and page layout into separate files.
As a project / site grows I add to these libraries to fit the needs of the site. If it gets large enough to warrant more beefy hardware, RAM, and disks, then I look at converting to PEAR libraries and larger frameworks, which tends to be fairly easy as I already have class wrappers for most functionality in place at that point.
— Max Schubert
PHP 5.2.3: an old bug rears its' head · 10 August 2007, 18:25
Compiling PHP 5.2.3 on Solaris 10, ran into a PHP configure script bug that perplexed me for a few days. PHP would compile fine, but ‘make test’ would result in a segfault. Stack trace shows a date / timezone function
timelib_parse_tzfile
being called, followed by memcpy() from libc, followed by a segmentation fault and core dump.
The bug is filed here
http://bugs.php.net/bug.php?id=38975
for the Wind River OS, but the problem and solution are the same for Solaris 10.
Upgrading to 5.24RC5 works as well as that build does not have the same configure / WORDS_BIGENDIAN problem.
— Max Schubert