/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 :)

The first step was compressing all JavaScript files with the Yahoo YUI compressor. The next step was to activate mod_deflate and compress all text, XML, and media files (JavaScript, CSS).

When the mod_deflate module is loaded in apache this is a pretty easy thing to do. Just add the following lines to a .htaccess file in the root of the web site / application.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript text/css
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

The first line enables mod_deflate for the specified extensions. And the other three lines are there because of the way some older browsers handle gzipped data.

To test if the the content is transmitted over the line in gzipped format i used the Live HTTP Header Firefox extensions. This let’s you watch the Live HTTP headers as the fly by.

Check the HTTP/ 1.x 200 OK response from the webserver for the following line

Content-Encoding: gzip

And to test what happens if a browser doesn’t support gzipped data. You can set a configuration parameter in Firefox about:config.

gzip, deflate enabled:

network.http.accept-encoding = gzip,deflate

gzip, deflate disabled:

network.http.accept-encoding =

References :
http://www.howtoforge.com/apache2_mod_deflate

So i did some debugging and quickly came to the conclusion the POST data array was empty after a submit of the form. That’s weird i thought. And didn’t really have a clue where to start looking. The code wasn’t touched for a couple of weeks. Bu then i remembered adding the forcing of the trailing slash.

So i browsed to the contact form and did a view source. And there was the problem. The form submitted to

/contact/verstuurd

A URL without a trailing slash. This causes apache to rewrite the url to

/contact/verstuurd/

And this also seems to turn the POST into a GET request.

So to fix it just changed to URL in the form to reflect the correct end point. But i have to say i didn’t expect this to happen. I understand why it happens. And it’s pretty logical. But i wonder if there’s a way around this behavior?

/trip/80
/trip/80/

Both point to the same content. But a crawler would see this as two different URL’s. Which off course is correct. But this can lead to duplicate content being indexed in search engines. Which could result in penalties for the site in question. So to fix this problem we add three simple lines to the main .htaccess file

# If a requested file does not exists
RewriteCond %{REQUEST_FILENAME} !-f

# If a requested directory does not exist
RewriteCond %{REQUEST_FILENAME} !-d

# Force a trailing slash to the request
RewriteRule [^/]$ %{REQUEST_URI}/ [R=301,L]