InnoDB memcached插件vs原生memcached对比性能测试
MySQL 5.6开始支持InnoDB memcached插件,也就是可以通过SQL高效读写memcached里的缓存内容,也支持用原生的memcache协议读写,并且可以实现缓存数据持久化,以及crash recovery、mysql replication、触发器、存储过程等众多特性,详细介绍可以查看:Benefit
MySQL 5.6开始支持InnoDB memcached插件,也就是可以通过SQL高效读写memcached里的缓存内容,也支持用原生的memcache协议读写,并且可以实现缓存数据持久化,以及crash recovery、mysql replication、触发器、存储过程等众多特性,详细介绍可以查看:Benefits of the InnoDB / memcached Combination。看起来非常诱人,那就测试下看看吧,是驴子是马拉出来溜溜便知。
- 环境准备
测试机 | DELL PE R710 |
CPU | E5620? @ 2.40GHz(4 core, 8 threads, L3 Cache 12 MB) * 2 |
内存 | 48G(8G * 6) |
RAID卡 | PERC H700 Integrated, 512MB, BBU, 12.10.1-0001 |
系统 | Red Hat Enterprise Linux Server release 6.4 (Santiago) |
内核 | 2.6.32-358.el6.x86_64 #1 SMP |
raid级别 | raid 5(10K RPM SAS 300G * 6) |
文件系统 | xfs |
硬盘 | 10K RPM SAS 300G * 6, 1 hotspare |
- 测试方案
方案一 | server端运行InnoDB MC,本地/远程调用memslap执行benchmark |
方案二 | server端运行Native MC,本地/远程调用memslap执行benchmark |
- 测试脚本
cat memslap_run.sh #!/bin/sh . ~/.bash_profile > /dev/null 2>&1 cd /home/mc-bench exec 3>&1 4>&2 1>> memcache_memslap_${RANDOM}.log 2>&1 #不断循环 while [ 1 ] do #并发线程数 4 ~ 256 for THREAD in 4 8 16 32 64 128 256 do #每种并发测试5次 count=1 max=5 while [ $count -le ${max} ] do #取样 echo "memstat" memstat # --flush 每次测试完毕钱,都先清空数据 # --binary 采用binary模式 # 初始化数据: 5000000, 每个并发线程存取数据量: 100000 # 并发256线程时, 总数据量可达 30,600,000 # 未指定 --test 选项,默认是进行 set 测试 memslap --server=mc_server:11211 --concurrency=${THREAD} --execute-number=100000 --initial-load=5000000 --flush --binary count=`expr ${count} + 1` #每次测试完毕后,都休息2分钟,等待服务器恢复空负载 if [ ${count} -lt ${max} ] ; then sleep 120 fi echo "" echo "" done done done
- 测试结果
1. 写MC
? ? ? ? ? ? ? ?线程数 耗时 |
256 | 128 | 64 | 32 | 16 | 8 | 4 |
NativeMC(单位:1秒) | 104.315 | 47.646 | 24.486 | 12.162 | 6.351 | 5.525 | 5.078 |
InnoDBMC(单位:100秒) | 339.1431 | 68.11128 | 27.67265 | 11.26917 | 4.968556 | 2.24988 | 1.104334 |
直接以曲线图方式对比:
nativemc-vs-innodbmc-benchmark-02-set-result-20130828
2. 读MC
??????? 线程数 耗时 |
4线程并发,2千万记录 |
本地Native MC | 198.5016 |
本地InnoDB MC | 327.239 |
远程Native MC | 846.286 |
远程InnoDB MC | 912.467 |
曲线图方式对比:
nativemc-vs-innodbmc-benchmark-03-get-result-20130828
- 结论
InnoDB MC看起来很美好,现实很骨感,其并发4线程写数据需呀的耗时,和原生memcached的256线程相当,差的不是一丁半点啊,还有很大优化空间。
而如果是缓存只读,InnoDB MC本地读取的效率大概是原生memcached的2/3,如果是远程读取,则相当于是本地读取效率的1/4 ~ 1/3。
- 建议应用场景
鉴于上面的测试结果,建议将InnoDB MC这么来用:
1. 数据写入通过触发器(trigger)或者调度器(event scheduler)将待缓存数据同步到InnoDB MC缓存表中;
2. 以memcache API方式,通过本地/远程读取InnoDB MC中的缓存记录;
3. 尽可能减少通过远程方式往InnoDB MC写缓存数据;
原文地址:InnoDB memcached插件vs原生memcached对比性能测试, 感谢原作者分享。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











現在、通貨サークルが好む潜在的なコインには、SOL コインと BCH コインが含まれます。SOL は、Solana ブロックチェーン プラットフォームのネイティブ トークンであり、ビットコインのフォーク通貨である BitcoinCash プロジェクトのトークンです。技術的特徴、応用シナリオ、開発の方向性が異なるため、投資家にとってSOL通貨とBCHのどちらがより可能性があるかを分析したいと思います。また投資しましょう。ただし、通貨の比較には、市場、開発見通し、プロジェクトの強みなどに基づいた包括的な分析が必要です。続いて編集者が詳しくお伝えします。 SOLコインとBCHではどちらの可能性が高いでしょうか?比較すると、SOL 通貨のほうがより大きな可能性を持っています。SOL 通貨と BCH のどちらがより大きな可能性を持っているかを判断するのは、多くの要因に依存するため、複雑な問題です。

Windows オペレーティング システムは、常にパーソナル コンピューターで最も広く使用されているオペレーティング システムの 1 つであり、最近 Microsoft が新しい Windows 11 システムを発売するまで、Windows 10 は長い間 Microsoft の主力オペレーティング システムでした。 Windows 11 システムのリリースに伴い、Windows 10 と Windows 11 システムのパフォーマンスの違いに関心が集まっていますが、どちらの方が優れているのでしょうか?まずはWを見てみましょう

Windows 10 と Windows 11 のパフォーマンス比較: どちらが優れていますか?テクノロジーの継続的な開発と進歩により、オペレーティング システムは常に更新され、アップグレードされます。世界最大のオペレーティング システム開発者の 1 つとして、Microsoft の Windows シリーズ オペレーティング システムは常にユーザーから大きな注目を集めてきました。 2021 年、Microsoft は Windows 11 オペレーティング システムをリリースし、広範な議論と注目を引き起こしました。では、Windows 10 と Windows 11 のパフォーマンスの違いは何でしょうか?

Ollama は、Llama2、Mistral、Gemma などのオープンソース モデルをローカルで簡単に実行できるようにする非常に実用的なツールです。この記事では、Ollamaを使ってテキストをベクトル化する方法を紹介します。 Ollama をローカルにインストールしていない場合は、この記事を読んでください。この記事では、nomic-embed-text[2] モデルを使用します。これは、短いコンテキストおよび長いコンテキストのタスクにおいて OpenAI text-embedding-ada-002 および text-embedding-3-small よりも優れたパフォーマンスを発揮するテキスト エンコーダーです。 o が正常にインストールされたら、nomic-embed-text サービスを開始します。

さまざまな Java フレームワークのパフォーマンス比較: REST API リクエスト処理: Vert.x が最高で、リクエスト レートは SpringBoot の 2 倍、Dropwizard の 3 倍です。データベース クエリ: SpringBoot の HibernateORM は Vert.x や Dropwizard の ORM よりも優れています。キャッシュ操作: Vert.x の Hazelcast クライアントは、SpringBoot や Dropwizard のキャッシュ メカニズムよりも優れています。適切なフレームワーク: アプリケーションの要件に応じて選択します。Vert.x は高パフォーマンスの Web サービスに適しており、SpringBoot はデータ集約型のアプリケーションに適しており、Dropwizard はマイクロサービス アーキテクチャに適しています。

PHP の配列キー値の反転メソッドのパフォーマンスを比較すると、array_flip() 関数は、大規模な配列 (100 万要素以上) では for ループよりもパフォーマンスが良く、所要時間が短いことがわかります。キー値を手動で反転する for ループ方式は、比較的長い時間がかかります。

C++ プログラムのパフォーマンスに対する関数の影響には、関数呼び出しのオーバーヘッド、ローカル変数、およびオブジェクト割り当てのオーバーヘッドが含まれます。 関数呼び出しのオーバーヘッド: スタック フレーム割り当て、パラメーター転送、および制御転送が含まれます。これは、小規模な関数に大きな影響を与えます。ローカル変数とオブジェクト割り当てのオーバーヘッド: ローカル変数やオブジェクトの作成と破棄が大量に行われると、スタック オーバーフローやパフォーマンスの低下が発生する可能性があります。

C++ マルチスレッドのパフォーマンスを最適化するための効果的な手法には、リソースの競合を避けるためにスレッドの数を制限することが含まれます。競合を軽減するには、軽量のミューテックス ロックを使用します。ロックの範囲を最適化し、待ち時間を最小限に抑えます。ロックフリーのデータ構造を使用して同時実行性を向上させます。ビジー待機を回避し、イベントを通じてリソースの可用性をスレッドに通知します。
