Saiweb

If you’ve seen the new twitter feed to the right you may of seem some ramblings about ‘cura’.

Cura is a PHP class I have authored in Co-operation with Psycle Interactive (The company I now work for, so be sure to thank them for allowing me to publish this write up!)

So what does it do?
Cura sets several call back objects in your PHP application that re-directs all session data to a mySQL database.

But why do I need that?
The average 1 server end user can stop reading here, as I can tell you now that Cura is not for you.

If however you are a business fielding multiple web servers then read on.

By passing all your PHP sessions to a database you remove the work around requirements for a load balanced solution.

i.e. web1 web2

1) Shopper arrives at web1 and logs in.
2) Shopper adds item to cart, which is logged against their session.
3) web1 is subjected to a search engine index.
4) web2 is now serving the shopper, shoppers basket is now logged out as their session id has changed …

There are numerous work around methods for this, such as having a single shared mount point for the PHP session files, the use of cookies etc …

The problem is in a high availability solution that a single mount point is just that, it’s singular and therefor a single point of failure.

Then there is the use of cookies, which is fine until you start to store a lot of data during your users session, at which point on each server change you are reliant on the cookie data being transmitted back to the server each time, raising the question what is the point of adding a load balanced solution if the user experience becomes degraded due to it’s deployment?

So secret option number 3 is to use a database, you can remove the single point of failure by having a mySQL cluster, and you haven’t got to worry too much about how much data you are storing.

Because everything is in a database whenever your web application is run (web1, web2) it will read the data from one source, allowing persistent sessions across your whole platform without the need for single mount points or session replication.

The source files are available from: http://svn.saiweb.co.uk/branches/cura-php/trunk/

To deploy this solution simply add the following lines to any file that calls session_start();

Ensure that you have created a ‘sessions’ table as per the provided sessions.sql file in your database.

I will be adding simplified support for wordpress and joomla shortly these will become available from: http://svn.saiweb.co.uk/branches/cura-php/trunk/Tweet

I have been working on a script as of late to aid in the ever ongoing process of optimizing a web applications “back end”, inevitably the database, and underlying code.

Thus dbstat was born, the current version is not for release _just yet_ , as some tweaks are still needed, at the moment it only supports reporting for a single database at any one time.

v 0.5 Features list.

1. Dynamic / Fixed row size checking. (Dynamic size rows can cause table fragmentation).
2. MyISAM / InnoDB  checking (Reports total number of tables using these engines).
3. Index threshold testing.
4. Table fragmentation threshold testing.
5. Table size threshold testing.
6. Database size reporting.

At the moment this is currently written in PHP, and is quite heavily scripted I will be looking to move to C++ for a v1.0 for the release, for calculations sake and to remove the need to install PHP.

I will post more information as the project develops, I will be looking to release the program and source under GPL by version 1.

By version 1, I intend to have included the following:

1. User interactive reporting. (On even of threshold being exceeded, prompt user to fix or skip, with cursory notes*)
2. Table de-fragmentation.
3. Reporting to include suggested fixes.

*Cursory notes  to describe the fix, and possible implications of actioning it.

So watch this space, and please leave requests via comments Tweet