特に、WordPressを活用した企業サイトを立ち上げている場合、ある程度以上のアクセスが集まると、レスポンスが遅くなるといった問題が生じることが多い。また、ブログ投稿ツールとしては非常に優れているWordPressの管理画面も企業サイトのワークフローにそぐわない場合もある。

ということで、技術者どもの集まりである我々が、ちょっくらそのあたりのWordPressのカスタマイズでもやってみるか、と思いGoogle App Engine (for Java)上でのPHPの稼動や、Windows AzureのPHP対応などに興味を持っていたところではある・・・。最近、Go言語にかまけて、このあたりごぶさたになっていたのだが、
WordPress on Windows AzureのInfoQ記事をみかけて再度、むむっとやる気が。

おりしも、年末締め切りで、Window Azureクラウドの開発コンテストなるものが開催され、PHPでも参加できるとのこと。まぁ、商品はたわいもないもののようだが、ちょっと本気だしてカスタマイズしてみる、には良い機会やもと思う今日この頃。

—

実はWindows Server2008の使用権などをもっていたりして、早く調査しておけばよかったのだが、windows のIISサーバではmemcachedのようなキャッシュの仕組みは何で運用されているんだろうか？・・・WordPressの裏方には、昨日当サイトで大々的に(?)とりあげたredis-db(実はwin32版もある)あたりをもってくるのもありかな、など、妄想は早くも広がりはじめている・・・実際にコンテストに応募となった際にはまた、ご報告いたします
m(_ _)m =>ただの 妄想で終わる可能性もあるため、下手に下手に。。

元のベンチマークのソースから書いていったので全体ごちゃごちゃしているのでソースの要部を以下に :

◇書き込み側

 ・・・
//redisクライアントの生成
  //(ドライバのソースに複数種類のクライアントがあるが使い分け不明)
	client, e := redis.NewSynchClient(); // (spec);
	if e != nil {
          return onError ("on NewSynchClient call: ", e);
       }
	if client == nil {
          return failedTest ("NewSynchClient returned nil!");
       }

	doSetAndGet(client);
	client.Quit();
・・・
func doSetAndGet (client redis.Client)  {
	keys := [...] string { "one","two","three","four"};
	for i, key := range keys {
        fmt.Printf("%d: writing key %s\n", i+1, key);
		client.Set(key, //ここで書き込み
                   strings.Bytes("value"+ strconv.Itoa(i+1)));
    }
	allkey,_ := client.AllKeys();
	fmt.Printf("keys => %d \n",allkey);
	client.Save();
}

}

◇読み込み側

func doGetOnly (client redis.Client) {
	keys,_ := client.AllKeys();
	fmt.Printf("keys => %f \n",keys);
	for i, key := range keys {
        fmt.Printf("%d:  key %s => ", i, key);
		val1,_ := client.Get(key);
		fmt.Printf("as a string => %s \n",val1);
	}
}

◇実行結果

kyon@andLinux:~/windows/redis/redis-go/bench$ 8g -I ./../src/pkg/redis kyonclient1.go
kyon@andLinux:~/windows/redis/redis-go/bench$ 8l -o k1.out kyonclient1.8
kyon@andLinux:~/windows/redis/redis-go/bench$ ./k1.out

=== My 1st golang-redis .(writing ver. 1 Client) — 100 opts — 127.0.0.1:6379

1: writing key one
2: writing key two
3: writing key three
4: writing key four
keys => %d([]string=[four three two one])
kyon@andLinux:~/windows/redis/redis-go/bench$ 8g -I ./../src/pkg/redis kyonclient2.go
kyon@andLinux:~/windows/redis/redis-go/bench$ 8l -o k2.out kyonclient2.8
kyon@andLinux:~/windows/redis/redis-go/bench$ ./k2.out

=== My 1st golang-redis .(reading ver. 1 Client) — 100 opts — 127.0.0.1:6379

keys => %f([]string=[four three two one])
0: key four => as a string => value4
1: key three => as a string => value3
2: key two => as a string => value2
3: key one => as a string => value1

◇redis-cliで確認

kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli get one
value1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli get two
value2

◇感想

ひっかかったところもほとんどなく、楽しかった。redis-dbがシンプルな作りであることもあり、golang-redisのソースは読みやすかった。golang-redis、KVSの学習兼golangのコードの書き方におすすめ。実用的に使えるかは・・・追検証にゆだねる。

kyon@andLinux:~/windows/redis/redis-go/src/pkg/redis$ make
8g -o redis.8 reflect.go sync.go specification.go error.go redis.go protocol.go connection.go synchclient.go asynchclient.go

ベンチマーク

kyon@andLinux:~/windows/redis/redis-go/src/pkg/redis$ cd ../../../bench/
kyon@andLinux:~/windows/redis/redis-go/bench$ chmod 755 runbench
kyon@andLinux:~/windows/redis/redis-go/bench$ ./runbench synchclient

=== Bench synchclient ================ 1 Client — 20000 opts — 127.0.0.1:6379

—
cmd: PING
20000 iterations of PING in 710 msecs
—
cmd: INCR
20000 iterations of INCR in 870 msecs
—
cmd: SET
20000 iterations of SET in 980 msecs
—
cmd: GET
20000 iterations of GET in 740 msecs
—
cmd: SADD
20000 iterations of SADD in 960 msecs
—
cmd: LPUSH
20000 iterations of LPUSH in 1000 msecs
—
cmd: RPUSH
20000 iterations of RPUSH in 1000 msecs
—
cmd: LPOP
20000 iterations of LPOP in 840 msecs
—
cmd: RPOP
20000 iterations of RPOP in 830 msecs
kyon@andLinux:~/windows/redis/redis-go/bench$ ./runbench gosynchclient

=== Bench synchclient ================ 10 Concurrent Clients — 2000 opts each —

—
cmd: concurrent PING
20000 iterations of concurrent PING in 960 msecs
—
cmd: concurrent SET
20000 iterations of concurrent SET in 1120 msecs
—
cmd: concurrent GET
20000 iterations of concurrent GET in 1040 msecs
—
cmd: concurrent INCR
20000 iterations of concurrent INCR in 1070 msecs
—
cmd: concurrent DECR
20000 iterations of concurrent DECR in 1040 msecs
—
cmd: concurrent LPUSH
20000 iterations of concurrent LPUSH in 1210 msecs
—
cmd: concurrent LPOP
20000 iterations of concurrent LPOP in 1100 msecs
—
cmd: concurrent RPUSH
20000 iterations of concurrent RPUSH in 1210 msecs
—
cmd: concurrent RPOP
20000 iterations of concurrent RPOP in 1040 msecs

どうやら、ノートPC上のバーチャルOS上でも、１秒間に２万回くらいのデータ操作ができている模様。

ほんとか？・・・については、ソース嫁なので、これから読みます、はい。

[追記]ソース読んだ。

実際に20000回ループはしていた。また、redis側のログも出ている。10000回だとこんな感じ。

kyon@andLinux:~/windows/redis/redis-go/bench$ ./runbench synchclient

=== Bench synchclient ================ 1 Client — 10000 opts — 127.0.0.1:6379

—
cmd: PING
10000 iterations of PING in 390 msecs
—
cmd: INCR
10000 iterations of INCR in 430 msecs
—
cmd: SET
10000 iterations of SET in 550 msecs
—
cmd: GET
10000 iterations of GET in 500 msecs
—
cmd: SADD
10000 iterations of SADD in 500 msecs
—
cmd: LPUSH
10000 iterations of LPUSH in 520 msecs
—
cmd: RPUSH
10000 iterations of RPUSH in 530 msecs
—
cmd: LPOP
10000 iterations of LPOP in 430 msecs
—
cmd: RPOP
10000 iterations of RPOP in 430 msecs

kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli smembers SOS
1. mikuru
2. koizumi
3. kyom
4. haruhi
5. kyon
6. nagato

よし、余計な一人を含めて、再度メンバーを呼び出せた。
キー(nagato)から値(clojure)も再度取得してみる。
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli get nagato
clojure

余計な３番を消そう。

kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli srem SOS kyom
1

kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli smembers sos
(nil)
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli smembers SOS
1. mikuru
2. koizumi
3. kyon
4. haruhi
5. nagato
キーは大文字・小文字が区別されるのか。

団長つながりで大サーカスの方も追加してみる。
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd yasuD yasuda
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd yasuD kurochan
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd yasuD hiro
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli smembers yasuD
1. kurochan
2. yasuda
3. hiro
３人そろった。

２つの団を結合(sunion)してみよう。
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sunion SOS yasuD
1. kurochan
2. mikuru
3. yasuda
4. koizumi
5. kyon
6. haruhi
7. hiro
8. nagato

セット(集合)なので、順序は気にしないらしい。
ということで、rdedisは書き込みが１秒１０万個のデータが書き込み可能、読み出しも８万個/秒とかいう高速KVS(Key-Value storage)。その他の機能として、リスト操作、ソートされたセット(v1.1から)があり、今後の発展も期待できるが、まぁ、いまのところはただの高速KVSと思っておこう。

おまけにリスト操作(LPUSH/RPUSH)の例も。というふうにhead/tailの両方から操作できるらしい。
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli k1 v1
Unknown command ‘k1′
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli rpush k1 v1
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli rpush k2 v2
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli rpush rpop k1
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli get k1
(error) ERR Operation against a key holding the wrong kind of value
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli rpush k1 vv1
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli LLEN k1
2
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli LLEN k2
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli rpush k1 vvv1
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli LLEN k1
3
コマンドは大文字・小文字どちらでも良い模様。

以下では、redis-cliクライアントの経由で試してみる。golangで試すはその後に。

例によって、メンバー数５又は６のSOS団でテスト開始。

はじめにただのkey-valueストレージとして。

kyon@andLinux:~/windows/redis$ cd redis-1.02/
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli set nagato clojure
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli set haruhi sleepingbeauty
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli set mikuru mikurubaem
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli get nagato
clojure
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli keys na*
nagato
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli set kyon whatitis
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli set koizumi java8
OK
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli keys k*
koizumi kyon

団長はただのKVSには興味がないようなので、もう少し。

kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS nagato
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS mikuru
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS koizumi
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli scard SOS
3
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS kyom
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS kyon
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli sadd SOS haruhi
1
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli scard SOS
6
kyon@andLinux:~/windows/redis/redis-1.02$ ./redis-cli smembers SOS
1. mikuru
2. koizumi
3. kyom
4. haruhi
5. kyon
6. nagato

あれ、typoしたぶん一人多い気が。あと、この順番では、団長がなっとくしない模様。setで団長をどう定義するのとかについては、続く(後編)。

で、クライアントのベンチマークコードまでつけてくれているよ。すばらしい。

それで、interfaceの使い方については、connection.goのコードに以下のくだりが、

// Handle to a future response
type PendingResponse struct {
	future interface{}
}

なるほど、こうやって、struct内でinterface宣言して、futureをいろいろ使いまわすのか。
他の言語うんぬん言う前に、やはりgolangなソース嫁だな。ソースが俺の嫁。