2

Redisプロトコルのサブセットを使用する単純なキー値ストアを作成しました。Linux では pthread を使用してハッシュ テーブルを共有します。pthreads rwlocks を使用して、このテーブルへのアクセスを管理しています。Redis ベンチマーク ツールを使用して KV ストアをテストしてきました。

1 つのクライアントで、1 秒間に約 2500 の SET 操作を実行できます。ただし、1 秒あたり約 25 GET しか実行できません。私は逆のことを期待していたので、これは私を驚かせます。ある程度スケーリングできるので、10 クライアントを投入すると、1 秒あたりほぼ 9000 の SET と、1 秒あたり約 250 の GET が得られます。

私の GET コードは非常に単純です。テーブルをロックし、適切なハッシュ テーブルの場所を見つけ、そこにあるリンク リストに一致するキーがあるかどうかを確認します。GET の場合、完了したらpthread_rwlock_rdlockandを使用しpthread_rwlock_unlockます。SET には、 と を使用pthread_rwlock_wrlockpthread_rwlock_unlockます。SET は GET よりもかなり複雑です。

また、共有メモリ プロセスと読み取り/書き込みロックの独自の実装を使用して、Plan 9 でコードを動作させました。そこでは、GET は 100 倍遅くなる代わりに、SET とほぼ同じ速度になります。これにより、私のハッシュ テーブル コードはおそらく問題ないと思います。両方の OS でまったく同じハッシュ テーブル コードを使用します。#defines を使用して、各 OS に適切なロックを選択するだけです (インターフェイスはどちらの場合も同じです。幸運です!)。

私は pthread の経験があまりありません。なぜ私のパフォーマンスがひどく悪いのかを理解するのを手伝ってくれる人はいますか?

(注: これは高パフォーマンスの KV ストアを意図したものではなく、単純に記述されたテスト アプリケーション/ベンチマークを意図したものです。クライアントごとに新しいスレッドをスピンオフすることにより、可能な限り最も単純な方法でリクエストを処理します)

4

1 に答える 1

1

I don't know rwlocks but the experience I made with conditional locks with pthreads was, that with a realtime kernel the conditions were woken up faster. You can even tune the programs priority with chrtcommand.

于 2012-06-03T11:56:09.230 に答える