Monthly Archives: April 2006

Canadian Music Creators Coalition

Courtesy of Boris (who always finds good stuff) I discovered the Candian Music Creators Coalition. This organization is dedicated to dispelling the myths that some major labels seem bent on propagating, and also serves as a vehicle where Canadian musicians can have their voices, view points and ideas heard.

From their site:

Until now, a group of multinational record labels has done most of the talking about what Canadian artists need out of copyright. Record companies and music publishers are not our enemies, but let’s be clear: lobbyists for major labels are looking out for their shareholders, and seldom speak for Canadian artists. Legislative proposals that would facilitate lawsuits against our fans or increase the labels’ control over the enjoyment of music are made not in our names, but on behalf of the labels’ foreign parent companies.

Their main points are:
1. Suing Our Fans is Destructive and Hypocritical
2. Digital Locks are Risky and Counterproductive
3. Cultural Policy Should Support Actual Canadian Artists

While I am in complete agreement with all of these, I think their last point is the most interesting. Canada is a bit unique (compared to the United States) in that our government actually supports our artists. In an environment where government organizations like FACTOR fund artists as much as Warner Bros., we have a great opportunity to define cultural policy and legislation that reflects this.

Looking forward to more…

–update–
Michael Geist has some great thoughts on this.

Posted on: 06.04.25 | 2 comments

Speeding up XML-RPC calls in Drupal

Through Bryght, I’ve been working on an interesting project that really exercises the “toolkit” and “web services platform” like nature of Drupal. The final architecture of our project ended up having many distributed processes, all sending data to Drupal through XML-RPC, and we were using Drupal mainly to aggregate and display the results.

Performance was very important, and we were having a huge bottle neck with Drupal’s XML-RPC library. XML-RPC calls were talking a long fricken time, and we were making tons of them.

Fortunately I had help from Walkah and Moshe, and I thought I would pass on what we did to drastically increase XML-RPC performance. This worked for us, so maybe it might help someone else out.

The problem is of course that Drupal does a full bootstrap for every XML-RPC call.

Our solution:
The first, simple (and huge) win was to utilize a PHP opcode cacher - this drastically reduces this bootstrapping time. We used eAccelerator, but there are many others.

Secondly, since we were working in a controlled environment (we knew what modules were going to be called via XML-RPC) we were able to hack the xmlrpc.php file to avoid a full bootstrap. The downside is we had to hardcode a few path things into the file, but again, this is for a particular app/site, and the performance gains were worth it.

Courtesy of Moshe, here is our revised xmlrpc.php file (you might want to rename it to xmlrpcs.php or something):


< ?php
// $Id$

/**
* @file
* Optimized php page for handling xml-rpc requests. Your module must use declare the hook_init() or hook_exit()
* so that it is loaded during the boostrap. Otherise, use hook_xmlrpc as usual. Note that only required modules are loaded at this point.
*
* @author
* Moshe Weitzman
*/

// CONFIGURE
$path = ‘./sites/mwpb-9.local/modules/’;
$module = ‘my-xmlrpc-module’; //the name of the module where your xml-rpc calls are
// END CONFIGURE

include_once ‘./includes/bootstrap.inc’;
drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE);
include_once ‘./includes/xmlrpc.inc’;
include_once ‘./includes/xmlrpcs.inc’;

require_once $path. $module. ‘.module’;
$function = $module. ‘_xmlrpc’;
$callbacks = $function();
// print_r($callbacks);
xmlrpc_server($callbacks);

// put any common.inc or other core functions here that your module relies upon.
function t($string) {
return $string;
}
?>

This was enough to get a huge increase in performance. (Yeah!)

Further thoughts:
One could use “mysql_query()” and avoid bootstrap all together, although I don’t think this is very much overhead, and the benefits of using Drupal’s “Database abstraction layer” probably out way any performance overhead here.

I wonder if there is any way to get Drupal to intelligently load necessary code instead of doing a full bootstrap. The “hardcoding” method above certainly works, but I am craving a more elegant and universal solution. Any thoughts?

Posted on: 06.04.19 | one comment