If you have missed the boat of the first generation of elePHPants, now is the right time to catchup up and participate to the 2008 generation! As for the first generation, this project is open to every PHP User group and aficionados, that want to adopt elePHPants, small or big.

Pricing is 4 Euros per elephant (in a 50 count box only) or 50 Euro for one of the larger elephants. They're even open to having company logos ("your own brood") added to the other side of his back. You can find more details on getting your hands on one at this page on the Nexen.net website or just head right to the order form to get a little blue PHPer to call your own.

I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn't seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation [...] However, it turns out there are some other php.ini config variables that you may need to look at.

The "usual suspects" list includes changing the max_upload_size value and adjusting the script timeout. The other settings he mentions, though, are things like memory_limit, post_max_size and max_input_time to help increase the default times that PHP uses on most page executions.

So, at dealnews, we have a category tree. To make life easy, we dump it to an array in a file that we can include on any page. It has 420 entries. So, I was curious how efficient this was. I noticed that some code that was using this array was jumping in memory usage as soon as I ran the script.

His tests showed that the memory jump from before and after the array was significant (5 MB for his test). He tested different methods of storage for the array including a var_export and serializing the data (the lowest memory option).

In "The J2EE guy still doesn't get PHP", Harry Fuecks suggests that PHP really needs [someone] to get together and write a detailed paper on how it works and why PHP scales so we can all live happily ever after.

I could not agree more.

Sebastian even notes that just recently, such a document would have come in very handy in a discussion. Unfortunately, he hasn't had the experience needed to make such a paper himself, so he's asking the community to help on the project and give suggestions/comments/offers of help in the comments of this blog posting.

Some days ago I stumbled upon an old entry of Jan in lighty's life, called "X-Sendfile". There he explains how to speed up the delivery of (large) files with lighttpd instead of PHP (YES, lighttpd is very fast - for one customer we created an ImageServer with pure lighty that replaced a 4-server-cluster with Apache and now has 1 server with lighttpd (which is boring around at low load). The box makes 180 Mio. requests per month).

He even gives an example of the functionality, showing how a combination of an entry in the web server's config coupled with a simple PHP script can easily send out a large file to anyone nice and zippy.

As one man was quoted "640K of memory should be enough for anybody" no one will need to access more than 2 GB data. What happens if you - just for scientific reasons of course - try to access larger files using your 32bit hardware and your favorite programming language PHP?

They give the example of opening a large 2 gig file with PHP and the resulting error that would pop up. They try a few differnt ways before getting down to more of a non-PHP PHP solution (yes, you read that right). They decided, instead, to create a script to work with the file chunked, using an exec() call to the unix split command to break it up.

He makes the case that not only is it a pretty simple matter to make the move (usually) plus the fact that several large companies using PHP have already made the leap as well. I also like this great little "soundbite" quote he shares:

Some of the reasons they give include:

• Many PHP-modules are not thread safe
• Non-standard date format characters
• No Unicode

Among those on the list, included are:

• PHP Edit
• ActiveState Komodo
• EditPlus
• PHPEclipse
• BBEdit

Each of the editors on the list is linked to the php-editors.com review for it, giving you more information than just the version, license, OS, and general rating in Justin's post.]]> Fri, 31 Mar 2006 07:03:45 -0600 http://www.phpdeveloper.org/news/4808 http://www.phpdeveloper.org/news/4808 Justin has posted an article from Aaron Crane that talks about using PHP in large websites - some of the issues, methods, and suggestions that he's noticed over time.

The PHP scripting language has an enjoyed an enormous growth in popularity over the past few years. It benefits from being particularly easy to pick up, and from having been designed as a language specifically for producing webpages. This means that choosing PHP as your implementation language allows you to build a dynamically-generated webpage quickly and easily.

However, it is not clear how well PHP scales for use in larger commercial websites. This paper examines the issues in trying to do so.

He invesigates topics like:

• Separation of presentation from business logic
• Areas where PHP's initial simplicity can actually make things more complicated
• Using a team of developers to build a site

For each item, he looks in detail about what the topic is and how a manage/develoeper can get a handle on it. There are good and bad sides to all, but finding the right balance is key.]]> Tue, 07 Feb 2006 07:16:53 -0600