Installation walkthrough, including memcached and pecl memcache

lyricnz ,

Thanks for putting together the documentation. I'm preping for starting a memcache test cycle within the next couple of weeks. Are there issues that I need to know about before I attempt this test installation?

James
FatAtlas.com

@gogman: none of this code is production ready yet. You're really encouraged to start trying things out... such as following lyricnz's instructions for installation, but until there is an official release, don't use this code on any live site.

@lyricnz please assign this issue to yourself and commit your document to the project as INSTALLATION.txt or something of the like.

Just running it under a test drupal 5.1 environment using devel generate to create 10k nodes (5k comments plus taxos) and then hammering it with siege.

Here's how:
Stage One: Generate the Performance test URL list

php -r '$domain_name = "example.com";
 $subdir = "/node/";
 $min_node = 1;
 $max_node = 10000;
 $number_urls = 10;
 for ( $counter = 1; $counter <= $number_urls; $counter += 1) {$urls .= $domain_name . $subdir . rand($min_node,$max_node)  . "/" . "\n";} echo $urls;  $fh=fopen("/usr/etc/urls.txt","w"); fwrite($fh,$urls);
 fclose($fh);'

Stage two: Hammer it with siege

siege -c 16 -i -t 1m -d 5 -f /usr/etc/urls.txt

I ran two scenarios. The first was a random set of URLs which would not repeat during the test. This should represent a non-cached set of nodes ( $number_urls = 1000;). The second scenario was a constrained list where the URLs would repeat, thus representing a cached set of nodes ($number_urls = 10;).

Scenario One (non-repeating URLs)
Transactions: 115 hits
Availability: 100.00 %
Elapsed time: 60.24 secs
Data transferred: 0.68 MB
Response time: 5.40 secs
Transaction rate: 1.91 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 10.32
Successful transactions: 115
Failed transactions: 0
Longest transaction: 7.20
Shortest transaction: 5.04

Senario Two (limited set of URLs)
Results:
Availability: 100.00 %
Elapsed time: 59.73 secs
Data transferred: 0.34 MB
Response time: 5.10 secs
Transaction rate: 1.98 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 10.07
Successful transactions: 118
Failed transactions: 0
Longest transaction: 6.26
Shortest transaction: 5.04

Analysis:
- This may just prove that I don't know how to setup a test for this cache strategy.
- The strange thing was that their was little difference between test one and two. The transaction rate per second was nearly the same (1.91 versus 1.98).

I have also been running the memcahcetests.php file.

Results to Date:
- confirmed installation
- memcachetest.php - it seems as though Test 1 - Test 7 work. Failure on further tests as they envolve muliple cache servers.

Multiple Errors - all seem to be 'connection refused' and 'cannot find connection identifier in /var/www/html/drupal_test51/memcachetests.php'. Other tests indicate that connections existed.

Conclusion:
- right now I still think that my installation may not be working properly. I should be seeing significant gains in transactions per second for the cached set of URLs.
- memcachetests.php is very helpful. Of course, it still could use a little more documentation.

I would welcome any feedback on how I could refine this test design using a mixture of ab (apache benchmark), siege and devel_generate. My objective would be for us to develop some simple repeatable test that allows us to benchmark alternate caching methods.

James
FatAtlas.com

James, it is more likely that there are still bugs in all of this new code. Your documentation, however, is really great, and I hope that lyricnz will find a way to add it to this project's documentation.

Configuration Fedora Core 6 (FC6)
memcached 1.2.1-4.rf.x86_64
php-pecl-memcached 2.0.4-1.rf.x86_64

Drupal Memcache
version = "5.x-1.x-dev"
memcache.info,v 1.1 2007/01/12 20:31:17
'; $Id:' seems to be missing from some components (memcache.module)

I had applied all the patches following the first cut of the installation documentation. This included node and taxo. I don't believe this included the stats patch you mentioned. I'll review and reset. I'm a bit confused on the ordering of patches at this time, but then again, thats' the price of progress.

benchmark.txt
I would be happly to help put together a simple benchmark.txt using the three tools ab, siege and devel_generate. This way each developer can benchmark their own system as well as share results with others in a consistent fashion. As the caching stack gets more complex we need some way of looking at these different strategies.

I will have some real stats with some of the stuff that is being rewritten within a day or two. We should have new patches available soon too.

Please create a feature request, and include this (cool) new documentation about performance testing.

Feature Request - done
Documentation 'benchmark.txt' - in progress