Yet Another Software Blog

Not having any inclanation to look into the PHP and APACHE source code I will have to qualify the statement in the title that it is coming from an observation and should not be treated as a consistent fact.

To make a long story short, I have moved from a shared hosting environment into an unmanaged VPS, which have a relativity small amount of RAM memory – 256M. One of the things that I am running on this VPS is a gregarious based RSS aggregator (pity that this project is virtually dead), the rest were my hebrew wordpress based blog, this wordpress mu based installation, and a mail server.

Once in several days the swap usage of the server will sky rocket and I will have to manually reboot the VPS. Though I have tried to find a common reason to this phenomenon, I could not fins one and I assumed That I am just over using my memory.

I have tried to do various change to the apache parameter controling the number of instances and the time it takes before they restart themselves, but altough there was an improvment, the server will still freeze from time to time.

One day the aggregator stopped giving any output at all. I have made some debugging and found out that what was killing it was an output compression done by calling ob_start(‘ob_gzhandler’) since when I have removed the call everything started working fine.

Then I have spent some time thinking about the “why” since while the prices of bandwidth have fallen through the years it is still nice to save if it is not too difficult. Finally it struck me that the only way the ob_gzhandler handler can work is by allocating memory which is in some way proportional to the amount of output generated, and for a memory starved machine and large output this can be a real killer since, as every software developer should know, there is not a single software on earth which can gracefully deal with shortage of memory resources.

Anyway, since most major web servers include now the capability of compressing the output, maybe it is better to leave it to them instead of implementing it in software, as they mught have a better dedicated code then PHP, and when they perform the compression they have probably cleaned the memory used by the PHP code, so they have more resources.

Wait a moment!, shouldn’t this line of reasoning be applicable to the usage of ob_start in any case? IMHO the answer is yes, and ob_start should be used for the shortest time, and the shortest output you can reasonably manage to get, unless you have idle memory and you don’t want it to feel neglected.

OK, that was a major annoyance!. I found a nice mysql backup script, changed all the constant which define the DB names, user, password and backup path, run it from the terminal and everything looked great. The following day I have checked the backup and there was no automatic backup done!

I have checked that all the paths in the script are absolute, and the script is executable and it has enough permissions to run, even changed the location of backup files, but still nothing happened.

For two months I have run the script manually when I happened to log into the server, but to day I woke up determined to stop this nonsense and try to find the root cause and solution to this problem.

After some googling and reading deep into some forum discussions I have discovered that the “run-parts” script which is the real engine behind executing the script in cron.daily don’t know how to handle files with extensions , and I used a .sh extensions for the backup file since I like the name of the file to express as much as possible its content.

This was a major PITA. You expect the extension part to be significant on windows but not on Unix, and this is not documented in any of the major documentation sites of Linux and Ubuntu …. Well, at least now there is a blog post about this…….

So you have a working WordPress based site and you are really happy with it until one day you add some new content and when checking the result you think to yourself “man this design is getting really old and out of fashion”.

What follows is a cycle of redesign which by itself is followed by coding the new design into a theme, and then you reach the point where you like to test your design with “live” data. For small sites it is possible to simply export all the posts, or the entire DB if you have fancy plugins, and import it into your testing environment, but for big enough sites it might be a difficult task running against space and time limitations imposed on the usual exporting tolls.

Hey, who am I kidding, I like any other decent programmer prefer to develop instead of setting up test environments, and the faster I can get my code to the server the better I feel. For me the best thing is to do most of the development on the live server.

The main obstacle for testing new themes on the server is the fact that only one theme can be active at any given time*, which means that you can not test without disrupting the look and usage for the normal users of the site.

To the rescue comes a feature which was introduced in version 2.7 – the theme preview. When you use the themes management it shows you the way the site will look when  you will activate a theme, and this can be used to test a theme without activating it. All you have to do is log in as an admin, or any user which has a ‘switch_themes’ capability, and browse the following url:

Yoursite?preview=1&template={name of template}&stylesheet={name of theme}

Where {name of template} should be replaced with the name of the directory in which the main theme is located and {name of theme} should be replaced if with the name of the child theme being used. If you don’t use a configuration of base and child themes, then you don’t have to specify the stylesheet parameter.

And what about testing the admin related changes if you have any? The only advice I have is to try and avoid the urge to reuse the names of the options which were used in the old theme. In the price of having to do some extra configuration, it will make testing on the server a lot safer and will keep your ability to revert to the old theme at any time.

* One day someone will write a plugin to fix this, but for version 2.8 this is the situation.