Surnia Ulula

UNIX Ideas for SysAdmins

PHP Class to Cache Remote Content by URL

Categories: PHP, WordPress

Tags: cache, google+, javascript, php, social buttons, tumblr, url, wordpress

Comments: No Comments

Published on: Thursday, February 14th, 2013

While developing the NextGEN Facebook OG plugin for WordPress, which adds social buttons from Facebook, Google+, LinkedIn, etc. to content and pages (along with several other features), I found the response time from these websites to be disappointing at times. When speed testing the pages of my websites, the JavaScript and images from these social elements would sometimes be a significant part of the total page load time. You can’t really save a copy of these files and serve them yourself, because they are frequently updated. You could create a cronjob to update them on a regular basis, but the maintenance of this can be cumbersome (as you add or remove files, etc.). It’s much easier to use a PHP method that caches and refreshes the remote files, and translate the URL at the same time. For example, something like:

$url = $cache->get( $url );

1	$url = $cache->get( $url );

Secure Vulnerable WordPress Files and Directories

by Jean-Sebastien Morisset

Categories: HTTP Server, WordPress

Tags: apache httpd, bulletproof security, cache, configuration, custom code, nextgen gallery, plugin, security, vulnerability, w3 total cache, wordpress

Comments: No Comments

Published on: Friday, December 28th, 2012

Recently Jason A. Donenfeld reported a simple vulnerability in W3 Total Cache on the Full Disclosure mailing list, which was picked up by the Security Ledger website, and then posted on Slashdot. The vulnerability is a simple Apache Httpd configuration oversight — plugins often create their own folders under ./wordpress/wp-content/ without considering that directory indexing might be turned on, or that files within that folder are located under a DocumentRoot, and thus available to anyone. Some configuration files are also vulnerable in this way — the wp-config.php file, for example. During the WordPress install, it is recommended that the wp-config.php be re-located one folder above ./wordpress/, to move it out of the DocumentRoot.

WordPress OS Disk Cache Report, Prime and Flush

by Jean-Sebastien Morisset

Categories: Bash, UNIX (Generic), WordPress

Tags: bash, cache, disk cache, flush, os, prime, report, sync, wordpress

Comments: No Comments

Published on: Thursday, December 6th, 2012

I wrote a bash script this morning to report the size of WordPress cache folders, the number of files they contain, read each file to prime the OS disk cache, and optionally flush the OS disk cache as well. This might be a script you could execute to email a daily/weekly report of cache folder sizes, or perhaps execute during/after booting a server to prime the OS disk cache, or even on a regular schedule to make sure the OS cache is always primed. The script also has a “flush” argument to sync and drop the OS disk cache, which isn’t very useful (to me) except to see the difference in speed between a clean and primed cache (about 11s vs 0.4s for all websites on my server).

WordPress Caching and Plugins for Performance

by Jean-Sebastien Morisset

Categories: HTTP Server, PHP, WordPress

Tags: apache, apache httpd, apc, bandwidth, cache, cache servers, caching, cdn, content delivery network, httpd, linux, memcached, opcode, performance, performance gain, php, php.ini, plugins, rewrite, static content, wordpress

Comments: 3 Comments

Published on: Saturday, December 1st, 2012

Over the past few weeks I’ve been looking at different solutions to improve the speed of my WordPress websites. The first step was to mirror and redirect the static content to another server (aka Content Delivery Network or CDN). I’m currently using a DreamHost VM, but I may look into using Amazon S3 as well. This is an easy way to save bandwidth, and off-load a web server that is configured for dynamic content (larger and slower). In the case of PHP and WordPress, there are several additional options available to improve local web server performance. I’ll describe the ones I’m currently using, including their expected impact to performance and short-comings. This article deals mainly with the local Apache Httpd and PHP configuration. There are additional infrastructure solutions that can improve performance, like using Nginx servers on the front, Varnish cache servers in the middle, and Apache Httpd on the back-end (for PHP and WordPress). This post is only about optimizing the Apache Httpd back-end. If you’re considering adding a Varnish server in front of Apache Httpd, you should probably avoid caching whole pages in Apache Httpd and leave that to the Varnish servers.

Save Memory with Alternative PHP Cache (APC)

by Jean-Sebastien Morisset

Categories: HTTP Server, PHP, WordPress

Tags: apache, apc, cache, httpd, memory, mpm, opcode, optimize, php, php.ini, prefork, speed, tune, wordpress

Comments: No Comments

Published on: Thursday, November 22nd, 2012

I’ve been looking for ways to improve the performance of my websites — several of them using PHP (WordPress), a few using mod_perl, and all running under the same Apache Httpd web server. The first thing I did was to sync all the static content to a Virtual Machine (VM) off-site, and redirect all requests for that content to the VM. Using redirects has several advantages, that (to me) outweigh the small disadvantage that all requests for static content still come to my web server, which then responds with a permanent redirect. The upside (to using a perl based rewrite map, for example) is that any change to the static content is immediately apparent to new visitors — excluding the usual browser cache issues. ;-)

I also wrote a script to check the Apache Httpd MPM config limits (prefork, worker, and event) and issue a warning or error message if those limits were set too high for the server’s memory. Writing this script made me realize just how much more memory each process was using since adding those PHP websites. Switching from the prefork MPM to the worker or event MPMs (where each process manages multiple threads / connections instead of just one) could have been one possible solution, but using PHP in a threaded environment is highly discouraged by the PHP team.

page 1 of 1