Posts Tagged ‘wordpress’

Concrete5 vs WordPress: Benchmarking Load Time

December 14th, 2010

I just discovered Concrete5 CMS recently when another developer in my area launched a site with it.  Always up for learning something new, I went to the website, read the sales pitch, and decided to give it a whirl.  Before I spend time learning yet another CMS, for kicks I thought I would benchmark it for speed against WordPress, my current go-to solution.  Here we go.

Preliminaries
Hardware: All tests will be conducted on my Desktop Computer; a custom built PC with a 3.5Ghz Core2 Duo, 4GB of Ram, and a 10,000 RPM hard drive.  Not identical, but similar to many server setups on the market.

Software: I’m running Ubuntu 10.04 with Apache 2.2, PHP 5.3, and MySQL 5.1.  Once again, apart from using a Desktop OS, this is almost identical to your usual LAMP server software. For benchmarking, I will be using Siege 2.68.

Step 1: Fresh Installs
I downloaded and installed the latest version of Concrete5 (5.4.1.1) and WordPress (3.03)  Here are the screenshots of the home pages out of the box:

WordPress Fresh Install

Concrete5 Fresh Install

a

Step 2: Balancing
Okay, First thing, to be fair we need to balance the page weights.  Siege will not load all the linked resources (like CSS and Javscript), I actually only care about the html page weights.  Out of the box Concrete is 1771 bytes and WordPress is 2015 bytes.  Pretty close.  After removing several widgets from the WordPress sidebar (Those extra queries weren’t fair anyway) and adding the right amount of Lorem Ipsum, the WordPress page is now exactly 1771 bytes as well.  Perfect.

Step 3: Attack!
To stress test my desktop server I am using the following siege command:

 siege -c 50 -r 40 http://localhost/[siteurl]

This will attempt to make 50 concurrent requests to the website, and will repeat each request 40 times.  This is a total of 2000 requests to each site.

Step 4: Results
Here is the raw data from the tests:

WordPress Concrete5
Total Requests: 2000 2000
Average Response Time (seconds): 2.52 1.62
Transactions per second: 16.23 22.46
Longest Transaction (seconds): 4.8 3.13
Shortest Transaction (seconds): .10 .07
Elapsed Time 123.21 89.04

And the corresponding screenshots:

Results for WordPress

Results for Concrete5

a

Step 5: Conclusions
As we can see from the data Concrete5 outperformed WordPress by 20-30% in every measure. This is a significant amount.  What does this tell us?  For small sites with little content, Concrete5 will scale to additional concurrent users better than WordPress. What does this not tell us?  For one thing, the sites may not scale to additional content equally well.  This test also ignored all the static content which will download from either CMS with equal speed.  Finally, WordPress also has some excellent caching plugins that may have closed the gap.

Other Considerations
Am I suggesting you ditch WordPress and port your sites to Concrete?  Not at all. WordPress has many good things going for it; it is the #1 blogging tool and is a finely tuned engine that powers millions of websites.  What I CAN say for sure, is that if you can outperform that, then you’re doing something right.  Hats off to the team at Concrete.

——————————————————-

Update (1 Day Later)
Okay, After posting this, I had a lot of people point out to me that this is not a fair fight.  Concrete has caching enabled by default, and WordPress does not.   After installing wp-super-cache, the elapsed time for 2000 requests from WordPress fell from 123 seconds to 27 seconds.  Wow, crazy plugin.  Either way, my original results stand when you consider out of the box performance.  Wp-super-cache is neither bundled with WordPress nor do it’s version numbers suggest it is stable.  It’s technical options are overwhelming to all but advanced users.  Kudos still go to Concrete5 for integrating a simple, stable caching system into the framework.

Buddypress Group Document Store

December 24th, 2009

I just uploaded my largest wordpress plugin yet: Buddypress Group Documents!

Group Documents creates a page within each BuddyPress group to upload and store documents.  Documents can be edited and deleted either by the owner or by the group administrator.  Document activity is logged in the main activity stream, and is also tied to the user and group activity streams.  The site administrator can set filters on file extensions, and soon (in the next update) users can set email notification preferences.  There is also a “Recent Uploads” widget than can be used to show any number of uploaded documents.

Get it while it’s hot!
WordPress.org Plugin Download Page

Installation
Make sure WPMU and BuddyPress are installed and active.
Copy the plugin folder buddypress-group-documents/ into /wp-content/plugins/

Browse to the plugin administration screen and activate the plugin.

There will now be a “Group Documents” menu item under the “BuddyPress” menu.  Here you will find a list of all file extensions allowed for uploaded files.  Please check and make sure the list suits you.

Please don’t hesitate to contact me, especially if you run into trouble.  I will respond promptly.  email hidden; JavaScript is required

Buddypress jQuery is not defined error

December 16th, 2009

While developing a Buddypress plugin, I was running into a problem where none of my Javascript was working. Instead, Firebug was telling me: “jQuery is not defined”.  This was quite frustrating, as I could verify that the jQuery file was indeed, being loaded.  While a few other people received the same error for different reasons (corrupt files, etc.) I did not quickly find the solution for my problem.  Here it is:

Problem: Buddypress calls your plugin’s JS files BEFORE jQuery files.
This applies when you use the function wp_enqueue_script() – as you should.

Solution: Tell wp_enqueue_script your file depends on jQuery.
It turns out, wp_enqueue_script() takes a few optional parameters – the third being an array of other js files yours is dependent on.

Here’s how the call looks after the change:
wp_enqueue_script(‘my-js-file’,’my-file-path.js’,array(‘jquery’));

Viola!  Your js file is now loaded after jQuery and you’re good to go.

Using Custom Profile Field Data in Buddypress Templates

November 18th, 2009

I ran into what I thought would be fairly common need for Buddypress theme development, the ability to pull data from a custom user profile field and display it. After searching a bit, I could only find way to pull either random fields, or all of the fields together. So after digging around in the core files, I found the pieces to put together my own function for the task.

1. Create the file “bp-custom.php” and place it directly in the plugins folder. Note, do not place it in the “buddypress” folder, otherwise it will be overwritten when upgrading. If the file exists, simply append to it rather than creating a new one.

2. Paste the following function in:

function bp_the_site_member_profile_data($field_name = '', $echo = 1) {
  if( !$field_name ) {
    return false;
  }
  global $site_members_template;
  if( function_exists( 'xprofile_get_field_data' ) ) {
    $data = xprofile_get_field_data( $field_name,
                                     $site_members_template->member->id);
    if( $echo ) {
      echo "$data";
      return true;
    } else {
      return $data;
    }
  }
}

3. You can now use the function ‘bp_the_site_member_profile_data(‘MyField’) in your templates (of course, substituting ‘MyField’ with the one you’d like to use). Note, this must be place inside a ‘Members Loop’ so that the $site_members_template variable is populated.  Odds are, you’re inserting this near other profile data already in the loop, so there should be no problems.

UPDATE:
As of BuddyPress 1.2, this functionality has been included. While in the members loop, you can use the included function: ‘bp_member_profile_data( ‘field=the field name’ )’ to much the same effect.