Performance

Overview

This project targets module developers and provides a "bare bone" callback handler which is intended to be addressed by modules wanting to improve response times for specialized tasks.

The idea of such a callback handler was first introduced by http://drupal.org/project/js (which we hence sometimes refer to as the "original module"). The D6 branch of js_callback was a clone of it and originally intended as a workaround to fix some issues which had been addressed there for a while. In the long run, we still intend re-merging both projects to avoid confusion.

This module will allow Drupal to replace textarea fields with the UEditor - a visual HTML editor, sometimes called WYSIWYG editor.

Provides an APC status and cache reporting page, accessible by a link on the status report page.

Installation

APC Status requires:

Generic helper module to allow external resources such as CSS, JavaScript and images to be fetched and cached locally.

This module was designed to solve the specific problem of rebuilding the node access table quickly.
This task would sometimes take the standard Drupal system tens of hours on sites with hundreds of thousands of nodes. Add to this, the fact that the standard drupal node access rebuild removes all access entries before rebuilding, and this can cause a site to be unavailable for many hours if the permissions have to be rebuilt.

The principle of this module is that this process can be sped up by making multiple simultaneous javascript calls to a rebuild script, which processes mutliples nodes at a time.
By adjusting the javascript request interval and the number of nodes to process per request, the module can be tuned for a specific site to make enough concurrent requests to provide a significant speed boost over serial processing, while not overloading the server.
Like the built-in drupal rebuild, the browser page must be left open during the rebuild, as the progress to completion is handled by client-side javascript.

The module works by returning a count of nodes (possibly matching a set of optional filters), calculating the highest and lowest node id within that set, then calculating the range between these. It then divides this range into blocks of node ids, according to the number per block setting on the administration page.

CCDN is a peer-to-peer Content Distribution Network for the Community.

How it works:

We Install it (you and me)
yourserver.com and myserver.com
We add a trust network (a list of servers you trust )
on your server:

myserver.com | png, jpg | upto 1g | 6 hours
example.com | tar.gz, zip | upto 10g | as long as needed
example2.com | jpg, png, gif, flv | upto 200g | always

on my server

yourserver.com | png, jpg, zip, gz | upto 500m | a week 

If a server is over loaded and the other server is idling the server overloaded (yourserver.com eg) says help to all the others in the trust list.

For each of the servers that say yes I'll help
by sending e.g. :

I'll host
png, jpg, zip, gz 
upto 500m 
for a week
add http://myserver.com/files/ccdn/yourserver.com to your uri's

The yourserver.com then starts adding http://myserver.com/files/ccdn/yourserver.com into the url's of it's images e.g.:
from
<img src=/files/image.png />
to
<img src=http://myserver.com/files/ccdn/yourserver.com/files/image.png />