/usr/sbin/apache2ctl line 82 (core dumped) $HTTPD ${APACHE_ARGUMENTS} -k $ARGV

Googling didn’t provide any useful information about the issue. So i contacted support and asked them to take a look at it. So i could move in the direction of the DPC11. After some horrible traffic and a closed road due to an accident. I finally made it to the DPC 2 hours late. But when i plugged my laptop in i noticed apache was still not running. Contacted support again. They couldn’t find any serious issues. I already missed the first part of “Optimizing MySQL Essentials“. So decided to do the tutorial first.

While i was sitting there i got the idea of disabling the apache modules. Which turned out to be a good idea. So after the tutorial session finished i logged in to the server. Disabled all apache modules and got apache working again. After some testing the cause of the problem seemed to be the Google mod_pagespeed apache module. That’s the second time this happened after a upgrade. Will leave it disabled for now.

On a side note.. Where is all the direct traffic coming from all of the sudden?

For me the main problem was. As soon as i enabled the module. It was active for all sites running on this server. And that should not be a problem. But some of these sites are WordPress monsters. That are ready to take any server down with a bit of high load.

So after a bit of trail and error. I figured out i could just disable mod_pagespeed globally by altering the main config file. After Apache reloaded mod_pagespeed was not active for the running sites.

in /etc/apache2/mods-available/pagespeed.conf make sure ModPagespeed is set to ‘off’

ModPagespeed off

So now i can simply enable settings i need on a per vhost basis. For this site end some other sites i used the following config section in my vhost.

# MOD-pagespeed

SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER
ModPagespeed on

ModPagespeedUrlPrefix “http://lenss.nl”

ModPagespeedFileCachePath “/var/mod_pagespeed/cache/”
ModPagespeedGeneratedFilePrefix “/var/mod_pagespeed/files/”

#ModPagespeedRewriteLevel CoreFilters
ModPagespeedRewriteLevel PassThrough

ModPagespeedEnableFilters add_head
ModPagespeedEnableFilters collapse_whitespace
ModPagespeedEnableFilters elide_attributes
ModPagespeedEnableFilters remove_comments
ModPagespeedEnableFilters rewrite_css
ModPagespeedEnableFilters rewrite_javascript
ModPagespeedEnableFilters move_css_to_head

First of we enable mod_pagespeed of course. And then we set the current domain for this instance. After that we set the file paths for the altered and cached files. And we use ‘PassThrough’ instead of ‘CoreFilters’. So we can decide our self’s what filters we will be using.

This had a much better result then my previous attempts. The server was still happily serving pages. And the load was OK. So let’s check the sites if mod_pagespeed is actually running.

$ wget -O /dev/null –server-response http://lenss.nl 2>&1| grep -i ‘X-Mod-Pagespeed’
X-Mod-Pagespeed: 0.9.0.0-172

Well that looks good. So now it’s time to do some testing. And this leaves me with a bit of a pickle. As i don’t have the required wget v 1.12 (i have a small patch for wget v1.11). Besides that i have some other problems running the tests

TEST: 404s are served and properly recorded.
wget -O /dev/null http://lenss.nl/mod_pagespeed/ic.a.bad.css 2>&1| grep -q ’404 Not Found’
wget -q -O – –save-headers http://localhost:80/mod_pagespeed_statistics | grep -q ‘resource_404_count: 1′
FAIL.

This fails because the statistics page requested is not available because this site uses rewrites. And i haven’t found a way to go around this yet besides disabling them in .htaccess with mod_rewrite. So shortly disabling this made it possible to run the biggest part of the test suite without problems.

resource_fetches: 2
total_page_load_ms: 0
page_load_count: 0
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 13
css_filter_minified_bytes_saved: 5082
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
javascript_blocks_minified: 15
javascript_bytes_saved: 380
javascript_minification_failures: 0
javascript_total_blocks: 15
resource_url_domain_rejections: 0
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 2
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0

It fails on the image compression part and that’s fine. Because i will leave that for later. So let’s run the site through the pagespeed browser extension with mod_pagespeed disabled:

load time without : 2.193
firebug/pagespeed score : 68

Now the same thing but with mod_pagespeed enabled:

Load time with : 1.284
firebug/pagespeed score : 90

That looks pretty good. And the other sites i have tested preform way better with the mod_pagespeed module enabled.

I still have some Javascript issues. Some things need further inspection because i have seen error like these coming along:

Permission denied for to call method Location.toString on .

Besides that. This morning my site was down due to Apache spitting segfaults. I disabled the ‘rewrite_javascript’ filter for now. And it seems to run a bit more stable.

[Thu Nov 11 07:38:24 2010] [notice] child pid 23608 exit signal Segmentation fault (11)

So besides it being a beta i am pretty impressed by the current state of this module. And after running it for a couple of weeks the statistics are pretty impressive.

Manuel Lemos also wrote a nice article about mod_pagespeed which is worth reading.

And this seems like a very promising project indeed. It mainly is a suite that provides web optimisation features to make your sites run faster. Right now 15 of such features are available.

including optimising caching, minimising client-server round trips and minimising payload size.

So no more manual image compressing and javascript, html and css minifying.

It uses the Apache SetOutputFilter to register the output filter. And from thereon you can use ModPagespeedEnableFilters to enable certain filters.

Filters like:

add_head
Add the head section if missing

move_css_to_head
Moves CSS into the head of the page (needs add_head)

combine_css
Combine multiple CSS tags into one.

rewrite_css,rewrite_javascript
Remove comments and white spaces

rewrite_images
Compress / re encode images

More info about the filters can be found here

So i went ahead and downloaded the Debian version to give it a try. And as always it’s straight forward from here.

dpkg -i mod-pagespeed-beta_current_i386.deb

It hooks nicely into Apache and creates the .load and .conf files in /etc/apache2/mods-available. After a Apache restart everything looked fine. And the pages did seem to load faster. Google also offers a test suite to see the result of this module in action.

Running the tests showed a small speed increase. But at the moment my daytime hours are spend behind a horrible firewall that really screws with web output. So i have to redo those for more accurate results. Never the less. This is a module to keep an eye on.

It’s still a very young project. And i did have some server issues today. So related or not. Be careful :)

Good move!

http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html

Warning: Unable to create prefs directory ‘/home/user/.googleearth’. File exists.
./googleearth-bin: relocation error: /usr/lib/i686/cmov/libssl.so.0.9.8: symbol BIO_test_flags, version OPENSSL_0.9.8 not defined in file libcrypto.so.0.9.8 with link time reference

Seems the libcrypto.so is linked against some wrong libraries. Thankfully this is pretty easy to fix. Just browse to the google-earth install directory and run the following commands:

$ rm libcrypto.so.0.9.8
$ ln -s /usr/lib/libcrypto.so libcrypto.so.0.9.8

The main reason i installed google-earth was to check out the new ocean view feature. So i selected a piece of coastline near the Netherlands.

Although i was looking for some ocean life. The first thing i found was an airplane :)