場景描述
-
從全文檢索或者緩存中獲取ID,根據ID查詢數據庫獲取基礎信息,進行頁面展示
-
SQL:select * from table where id in(id1,id2,id3...id40)
- 此種場景的常規方案是將id對應的基礎信息在redis中緩存一份,mysql只是做爲後端存儲。我們做如下測試就是嘗試mysql是否可應對這種查詢場景。然而根本原因是DBA告訴我,現在MySQL性能已經極其厲害。
數據量說明
- 1.8億條數據
- 使用Oneproxy分爲200個數據表(200個表在同一臺機器)
- 因爲id是隨機的,查詢時oneproxy會將查詢分散到所有後端MySql
性能指標
- 併發數
- 每次查詢的響應時間
MySql服務器
- 騰訊雲提供的MySQL服務
mysql的具體配置不在這裏列舉,即下面的性能報告只是特定場景下的性能分析,不代表mysql的“真實”性能。本文核心是提供一種測試方法,而不是單純的提供一份數據報告 。
測試程序簡介
- 基礎:php、swoole協程
- 使用協程控制程序的併發數,每個協程中執行一次查詢。當一次查詢完成,管道通知開始新的查詢。
程序代碼
mysql_test.php
<?php
ini_set('memory_limit', '1280M'); //協程會耗費較多的內存
define('MAX_MYSQLPOOL_NUM', $argv['1']); //mysql最大連接數,即併發數
define('TESTCOUNT', $argv['2']); //一共的測試次數
$mysqlconf = [
'host' => '127.0.0.1',
'port' => 3307,
'user' => 'root',
'password' => '123456',
'database' => '',
'timeout' => 10
];
Swoole\Coroutine::create(function () use ($mysqlconf) {
$stime = microtime(true); //程序開始時間
$pool = new MysqlPool($mysqlconf);
$chan = new chan(MAX_MYSQLPOOL_NUM); //併發數,協程間使用channel通信
for($i = 1; $i< TESTCOUNT + MAX_MYSQLPOOL_NUM; $i++) {
$chan->push('x');
Swoole\Coroutine::create(function() use($pool, $chan, $i) {
//測試的業務邏輯開始
$conn = $pool->get();
if($conn) {
$sql = "select /* parallel */ * from table where id in (".implode(',', getRandpid()).')';
$time1 = microtime(true);
$conn->query($sql);
$time2 = microtime(true);
if($i % intval(TESTCOUNT / 10) == 0) { //輸出執行的進度
echo "\n finish $i / ".TESTCOUNT;
}
$pool->put($conn, (($time2 - $time1) * 1000)); //每次查詢耗時就不單獨做實例,直接修改連接池類做簡單統計
} else {
echo "\n connect mysql fail,跳過SQL";
}
//業務邏輯結束
$chan->pop();
});
}
$etime = microtime(true);
echo "\n ============執行結果=============";
echo "\n 併發數量: ".MAX_MYSQLPOOL_NUM;
echo "\n 查詢次數: ".TESTCOUNT;
echo "\n 執行總耗時: ".intval($etime - $stime)."秒\n";
echo "\n QPS (查詢次數/總耗時) :". intval((TESTCOUNT / ($etime - $stime)));
echo "\n 每次查詢耗時平均值:".intval($pool->alltime / TESTCOUNT) ."ms";
echo "\n ============end=============\n";
die;
});
//數據庫連接池,https://wiki.swoole.com/wiki/page/852.html
class MysqlPool
{
protected $pool;
private $mysqlconf;
public $alltime;
public function __construct($mysqlconf)
{
$this->pool = new SplQueue();
$this->mysqlconf = $mysqlconf;
$this->alltime = 0;
}
public function put($mysql, $time = 0)
{
$this->pool->push($mysql);
$this->alltime += $time;
}
public function get()
{
//有空閒連接
if (count($this->pool) > 0) {
return $this->pool->pop();
}
$mysql = new Swoole\Coroutine\Mysql();
$res = $mysql->connect($this->mysqlconf);
if ($res == false) {
echo "\n connect error info: ".$mysql->error."\n";
return false;
} else {
return $mysql;
}
}
}
//隨機生成的數字
function getRandpid()
{
for ($i = 0; $i < 40; ++$i) {
$ret[] = rand(1, 185724600);
}
return $ret;
}
測試1:直接連接mysql,查詢單表的性能
-
測試代碼:修改以上代碼
- 1:修改mysql配置爲直接連接mysql,而不是oneproxy。即端口從3307改爲3306
-
2:“業務邏輯”部分中的SQL改爲:
$sql = "select * from table_10 where id in (".implode(',', getRandpid()).')';
-
測試指令:
php mysql_test.php 1 1000 //併發爲1,查詢1000次
php mysql_test.php 10 1000 //併發爲10,查詢1000次
php mysql_test.php 50 10000 //併發爲50,查詢10000次
...
php mysql_test.php 500 100000 //併發爲500,查詢100000次 -
測試結果:
- 結果分析:
根據主鍵查詢單表,mysql的性能基本可以滿足正常業務的需求
測試2
-
說明
查詢oneproxy。因爲查詢id是隨機的,每查一次oneproxy,對應查詢的是40個mysql的表。
即,當oneproxy的併發數爲1,mysql的對應併發數是40 -
測試代碼:
以上提供的代碼即爲此種情況的代碼,無須修改。 -
測試指令:
php mysql_test.php 1 1000 //併發爲1,查詢1000次
php mysql_test.php 10 1000 //併發爲10,查詢1000次
php mysql_test.php 50 10000 //併發爲50,查詢10000次
...
php mysql_test.php 100 10000 //併發爲100,查詢10000次 -
測試結果:
- 結果分析:
- 1:OneProxy做爲mysql的代理,對查詢性能基本0消耗。
當oneproxy的查詢併發爲5時,對應mysql的查詢併發爲200。測試2的結果,併發爲5,每次查詢耗時30ms。測試1,mysql併發200,每次查詢耗時29ms。可得到結論,oneproxy對性能0消耗。 - 2:每次查詢耗時太高,很小流量的業務才能使用此方案。
- 1:OneProxy做爲mysql的代理,對查詢性能基本0消耗。
測試3:後端mysql表分散到多臺機器
-
分到兩臺,測試結果:
- 分析:
mysql分到兩臺機器。同樣併發數時,每次查詢耗時能縮短一倍。 - 推測:
mysql表分到更多的機器,每次查詢耗時能達到測試1的結果,可滿足正常的業務需求。
最後,關注性能的同時,也要關注系統的穩定性、開發者的易用性、易維護性。