Home » Posts tagged "PHP" (Page 2)

How a programming language influences your mood

For over 3,5 years now I’ve been programming professionally in PHP. First in PHP4 and about half a year later we finally converted to PHP5. At first I was excited because I could use a lot of new features PHP5 offered such as proper OOP but also Zend Framework.

I started using Zend Framework from 1.5 (currently it’s at 1.10) and have very mixed feelings about it. Yes, it does have a lot of useful libraries such as MVC, basic ACL, Authorization, Input Validation & Filters, Views (with PHP as the templating language, which it essentially was designed for) and more. But ZF had a steep learning curve for me so far has been successfully used in about 5 big webapplications.

However, PHP’s inconsistent function naming, unpredictable order of expected arguments (needle and haystack anyone?), lack of closures/anonymous functions, namespacing, lexical scope and what not makes using PHP a true nightmare. Yes, PHP 5.3 finally supports closures and namespacing, but have you looked at the syntax for both? What a joke. On top of that, PEAR is even a bigger joke. Is someone using it at all?

Running into these issues day by day and knowing it can be easily solved in Perl is very, very depressing. It has totally taken away my desire to program, influencing my desire to program at all and has made my motivation disappear. I’ve truly been wondering if a programming job is really something I want.

The turnaround came when I had a talk with my boss about why we’d still use PHP for future projects. Yes, code reuse is one them but compared to Perl all the additional code I’ve written in PHP that is being reused already exists in Perl at CPAN. To my understanding the use of backslashes to define a namespace in PHP wasn’t really a design choice, but was forced upon because it was too hard to use the double colon or a dot, like many other languages do. On top of that, last time I checked, PHP6 development has been halted because they just can’t get Unicode to work.

Perl already supports Unicode, Perl doesn’t have a weird separation character for namespaces, Perl supports closures/anonymous subroutines, Perl supports lexical scoping, the core list of functions is small, easy to remember and the order of expected parameters is consistent. And it has CPAN.

I was able to convince my boss to start using Perl for future projects because of these given points for both Perl and PHP. What helped though was that he knew of Perl and we’ve also developed some applications in Perl already. One of them a Wx application, a newsletter mailer and some other small scripts. Difference now is that I can use it for webapplications as well.

Now that I’ve gotten the green light to go with Perl for future projects I’m much happier again at work. I’m more motivated to finish the current PHP projects so I can finally start doing some proper Perl work. Programming Perl makes me happy. Moving from PHP to Perl doesn’t mean we’ll be fully dropping PHP. That would be bad and ignorant. Existing stuff will still be supported, improved and extended with new features.

No matter how much you dislike one of the products you support, it’s part of the job. Having stuff you dislike is good actually, because it makes the fun stuff even more fun. For me, PHP makes Perl more fun :-).

Check your XCache settings!

So for a while now all PHP based applications at work were performing quite sloppy. Even though we’re using XCache as the opcode cache there was no difference in performance when XCache was enabled or disabled. Now, for small applications it didn’t really matter, but Zend Framework based applications were really slow. Even when all it did was route to an action and serve a page. Peak memory usage nearly topped 12 megabytes and average response time was between 600 to 950 ms. That’s a lot!

I’m sure it wasn’t the server, which has a quad-core CPU, enough free RAM and a high speed connection to the internet. Average load time is around 0.08 or so. And this is a server hosting several webshops, CRM software and CMS based websites.

Turned out that after I changed xcache.size from 16M to 64M and xcache.count from nothing to 4 (quad-core!) performance increased by almost 50%! A big Zend Framework based application went from 12 megabytes peak memory usage to only about 3.5 (depending on the type of page and actions of course). Response time went down to about 250 to 400 ms. Which is a very big increase. 400 ms Is still too much to my taste, but this is mostly for pages that fetch quite a lot of data, combine multiple views and so on. The smaller stuff (read non-ZF backed apps) how has a response time of about 80 to 180 ms, again depending on the type of page.

So remember, if you use XCache make sure you check your settings!

Update: After running for a day I found out performance degraded again. Once again it appeared that the opcode wasn’t used again. I’ve now set the xcache.ttl and xcache.gc_interval to one hour and 15 minutes respectively. Hoping this will solve the problems.

Update 2: Running multiple websites means caching a lot of files. I’ve now increased the cache size to 192, changed the gc_interval to 5 minutes and the ttl has been changed to 15 minutes. Do check though you’ve got the memory available for the increased cache size.

Change is coming

Which apparently is the slogan for launching Ubuntu 10.04. I think this is going to be a very nice LTS release. It’s too bad that they didn’t include Perl 5.12 in it, but that’s understandable as it just got released; although compiling your own is very easy. On the other hand, PHP 5.3 got in there thanks to the pressure of some fellow Dutchmen. Not that I’m a big fan of PHP, but PHP 5.3 has some nice additions such as closures.

Upgrading Ubuntu server delayed for next LTS version

Today at work we decided to wait for the next LTS version of Ubuntu, 10.04. Currently we run 7.04 which is no longer receiving updates. For a while now actually. This summer I worked on planning the upgrade process from 7.04 to 7.10, and finally to 8.04. Which is the current LTS version.

I was able to do a dry run upgrade on our backup server. So I was able to document every step of the upgrade process. Ubuntu upgrades nicely and from 7.04 to 8.04 there are only minor changes that need to be done in our configurations. Even the HP iLO software, for which support on Debian based systems is a bit vague, works out of the box with a native driver. No longer do I need to manually compile the HP iLO driver after every kernel update.

Originally we planned on doing the upgrade somewhere this month or December. But due to tight schedules (it’s quite busy for us) January or February seemed be more likely. Since 10.04, the next LTS version with support until April 2015, is out in April 2010 it likely doesn’t hurt to wait a little bit longer. As far as I know every LTS version so far was easily upgradeable to the next LTS version. So I expect upgrading is going to be a breeze. But of course, I’ll be running tests first when 10.04 gets released.

Why not upgrade to 8.04 first and run that first for a couple of months? Well, support for 8.04 ends in 2013, so 10.04 gives us more years of updates. Also, the upgrade process takes (down)time, time to get there, man-hours that need to be paid etc. etc. Further more, without a doubt, with every upgrade there are some issues going to arise. Small and trivial or stuff that brings down every website that’s running on it. Resolving these issues also takes time, which delays the progress of other projects and what not. By skipping yet another version I think we’ll actually save time.

I’m looking forward to it actually. On of the cool things I’m looking forward to is being able to upgrade Zend Framework from 1.8 to 1.9+. I’m also planning to use memcached and perhaps some PHP optimizer to greatly speed up some of the webapplications. And of course, Perl 5.10 (perhaps 5.12 by then?). Although we, unfortunately, don’t use Perl for our websites I like to keep Perl up to date as we use it for several system administration programs. CouchDB also caught my eye :-).

OK, enough for now. Bedtime :-).