摘要:今天本能是想测试一个PDO持久化,会不会带来会话混乱的问题先贴一下PHP代码,代码丑了点,但是坚持能r
今天本能是想测试一个PDO持久化,会不会带来会话混乱的问题 先贴一下PHP代码, 代码丑了点,但是坚持能run就行,反正就是做个测试。
true, PDO::ATTR_ERRMODE => PDO::ERRMODE_Exception];try { // 创建持久化连接 $pdo = new PDO($dsn, $user, $password, $options); $stmt = $pdo->prepare("INSERT INTO test_last_insert_id (uni) VALUES (:uni);"); $uni = uniqid('', true); $stmt->bindValue(':uni', $uni); $aff = $stmt->execute; // if ($aff === false) { throw new Exception("insert fail:"); } $id = $pdo->lastInsertId; function getExecutedsql($stmt, $params) { $sql = $stmt->queryString; $keys = array; $values = array; // 替换命名占位符 :key with ? $sql = preg_replace('/\:(\w+)/', '?', $sql); // 绑定的参数可能包括命名占位符,我们需要将它们转换为匿名占位符 foreach ($params as $key => $value) { $keys = '/\?/'; $values = is_string($value) ? "'$value'" : $value; } // 替换占位符为实际参数 $sql = preg_replace($keys, $values, $sql, 1, $count); return $sql; } $stmt = $pdo->query("SELECT id FROM test_last_insert_id WHERE uni = '{$uni}'", PDO::FETCH_NUM); $row = $stmt->fetch; $value = $row[0]; if ($value != $id) { throw new Exception("id is diff"); } echo "success" . PHP_EOL;} catch (PDOException $e) { header('HTTP/1.1 500 Internal Server error'); file_put_contents('pdo_perisistent.log', $e->getMessage . PHP_EOL); die('Database connection failed: ' . $e->getMessage);} catch (Exception $e) { header('HTTP/1.1 500 Internal Server Error'); file_put_contents('pdo_perisistent.log', $e->getMessage . PHP_EOL); die('Exception: ' . $e->getMessage);}用wrk压测,一开始uniqid因为少了混淆参数还报了500,加了一下参数,用来保证uni值
% ./wrk -c100 -t2 -d3s --latency "http://localhost/pdo_perisistent.php"Running 3s test @ http://localhost/pdo_perisistent.php 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 52.17ms 7.48ms 103.38ms 80.57% Req/Sec 0.96k 133.22 1.25k 75.81% Latency Distribution 50% 51.06ms 75% 54.17ms 90% 59.45ms 99% 80.54ms 5904 requests in 3.10s, 1.20MB readRequests/sec: 1901.92Transfer/sec: 397.47KB1900 ~ 2600 之间的QPS,其实这个数值还是相当满意的,测试会话会不会混乱的问题也算完结了。 但是好奇心突起,之前一直没做过go和php执行sql下的对比,正好做一次对比压测
package mainimport ( "database/sql" "fmt" "net/http" "sync/atomic" "time" _ "github.com/go-sql-driver/mysql" "log")var id int64 = time.Now.Unix * 1000000func generateUniqueID int64 { return atomic.AddInt64(&id, 1)}func main { dsn := "root:root@tcp(localhost:3306)/test?charset=utf8" db, err := sql.Open("mysql", dsn) if err != nil { log.Fatalf("Error opening database: %v", err) } defer func { _ = db.Close } //// 设置连接池参数 //db.SetMaxOpenConns(100) // 最大打开连接数 //db.SetMaxIdleConns(10) // 最大空闲连接数 //db.SetConnMaxLifetime(time.Hour) // 连接最大存活时间 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { var err error uni := generateUniqueID // Insert unique ID into the database insertQuery := `INSERT INTO test_last_insert_id (uni) VALUES (?)` result, err := db.Exec(insertQuery, uni) if err != nil { log.Fatalf("Error inserting data: %v", err) } lastInsertID, err := result.LastInsertId if err != nil { log.Fatalf("Error getting last insert ID: %v", err) } // Verify the last insert ID selectQuery := `SELECT id FROM test_last_insert_id WHERE uni = ?` var id int64 err = db.QueryRow(selectQuery, uni).Scan(&id) if err != nil { log.Fatalf("Error selecting data: %v", err) } if id != lastInsertID { log.Fatalf("ID mismatch: %d != %d", id, lastInsertID) } fmt.Println("success") }) _ = http.ListenAndServe(":8080", nil)}truncate表压测结果,这低于预期了吧
% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080"Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 54.05ms 36.86ms 308.57ms 80.77% Req/Sec 0.98k 243.01 1.38k 63.33% Latency Distribution 50% 43.70ms 75% 65.42ms 90% 99.63ms 99% 190.18ms 5873 requests in 3.01s, 430.15KB readRequests/sec: 1954.08Transfer/sec: 143.12KB开个连接池,清表再测,结果半斤八两
% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080"Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 54.07ms 35.87ms 281.38ms 79.84% Req/Sec 0.97k 223.41 1.40k 60.00% Latency Distribution 50% 44.91ms 75% 66.19ms 90% 99.65ms 99% 184.51ms 5818 requests in 3.01s, 426.12KB readRequests/sec: 1934.39Transfer/sec: 141.68KB然后开启不清表的情况下,php和go的交叉压测
% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080"Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 52.51ms 43.28ms 436.00ms 86.91% Req/Sec 1.08k 284.67 1.65k 65.00% Latency Distribution 50% 40.22ms 75% 62.10ms 90% 102.52ms 99% 233.98ms 6439 requests in 3.01s, 471.61KB readRequests/sec: 2141.12Transfer/sec: 156.82KB% ./wrk -c100 -t2 -d3s --latency "http://localhost/pdo_perisistent.php"Running 3s test @ http://localhost/pdo_perisistent.php 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 41.41ms 10.44ms 77.04ms 78.07% Req/Sec 1.21k 300.99 2.41k 73.77% Latency Distribution 50% 38.91ms 75% 47.62ms 90% 57.38ms 99% 69.84ms 7332 requests in 3.10s, 1.50MB readRequests/sec: 2363.74Transfer/sec: 493.98KB// 这里骤降是我很不理解的不明白是因为什么% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080" Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 156.72ms 75.48ms 443.98ms 66.10% Req/Sec 317.93 84.45 480.00 71.67% Latency Distribution 50% 155.21ms 75% 206.36ms 90% 254.32ms 99% 336.07ms 1902 requests in 3.01s, 139.31KB readRequests/sec: 631.86Transfer/sec: 46.28KB% ./wrk -c100 -t2 -d3s --latency "http://localhost/pdo_perisistent.php"Running 3s test @ http://localhost/pdo_perisistent.php 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 43.47ms 10.04ms 111.41ms 90.21% Req/Sec 1.15k 210.61 1.47k 72.58% Latency Distribution 50% 41.17ms 75% 46.89ms 90% 51.27ms 99% 95.07ms 7122 requests in 3.10s, 1.45MB readRequests/sec: 2296.19Transfer/sec: 479.87KB% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080" Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 269.08ms 112.17ms 685.29ms 73.69% Req/Sec 168.22 125.46 520.00 79.59% Latency Distribution 50% 286.58ms 75% 335.40ms 90% 372.61ms 99% 555.80ms 1099 requests in 3.02s, 80.49KB readRequests/sec: 363.74Transfer/sec: 26.64KB% ./wrk -c100 -t2 -d3s --latency "http://localhost/pdo_perisistent.php"Running 3s test @ http://localhost/pdo_perisistent.php 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 41.74ms 9.67ms 105.86ms 91.72% Req/Sec 1.20k 260.04 2.24k 80.33% Latency Distribution 50% 38.86ms 75% 46.77ms 90% 49.02ms 99% 83.01ms 7283 requests in 3.10s, 1.49MB readRequests/sec: 2348.07Transfer/sec: 490.71KB% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080" Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 464.85ms 164.66ms 1.06s 71.97% Req/Sec 104.18 60.01 237.00 63.16% Latency Distribution 50% 467.00ms 75% 560.54ms 90% 660.70ms 99% 889.86ms 605 requests in 3.01s, 44.31KB readRequests/sec: 200.73Transfer/sec: 14.70KB% ./wrk -c100 -t2 -d3s --latency "http://localhost/pdo_perisistent.php"Running 3s test @ http://localhost/pdo_perisistent.php 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 50.62ms 9.16ms 85.08ms 75.74% Req/Sec 0.98k 170.66 1.30k 69.35% Latency Distribution 50% 47.93ms 75% 57.20ms 90% 61.76ms 99% 79.90ms 6075 requests in 3.10s, 1.24MB readRequests/sec: 1957.70Transfer/sec: 409.13KB% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080" Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 568.84ms 160.91ms 1.04s 66.38% Req/Sec 81.89 57.59 262.00 67.27% Latency Distribution 50% 578.70ms 75% 685.85ms 90% 766.72ms 99% 889.39ms 458 requests in 3.01s, 33.54KB readRequests/sec: 151.91Transfer/sec: 11.13KBgo 的代码随着不断的测试,很明显处理速度在不断的下降,这说实话有点超出我的认知了。 PHP那边却是基本稳定的,go其实一开始我还用gin测试过,发现测试结果有点超出预料,还改了用http库来测试,这结果属实差强人意了。
突然明白之前经常看到别人在争论性能问题的时候,为什么总有人强调PHP性能并不差。 或许PHP因为fpm的关系导致每次加载大量文件导致的响应相对较慢,比如框架laravel 那个QPS只有一两百的家伙,但其实这个问题要解决也是可以解决的,也用常驻内存的方式就好了。再不行还有phalcon
我一直很好奇一直说PHP性能问题的到底是哪些人, 不会是从PHP转到其他语言的吧。
% php -vPHP 8.3.12 (cli) (built: Sep 24 2024 18:08:04) (NTS)Copyright (c) The PHP GroupZend Engine v4.3.12, Copyright (c) Zend Technologies with Xdebug v3.3.2, Copyright (c) 2002-2024, by Derick Rethans with Zend OPcache v8.3.12, Copyright (c), by Zend Technologies% go versiongo version go1.23.1 darwin/amd64这结果,其实不太能接受,甚至都不知道原因出在哪了,有大佬可以指出问题一下吗
加一下时间打印再看看哪里的问题
package mainimport ( "database/sql" "fmt" "net/http" "sync/atomic" "time" _ "github.com/go-sql-driver/mysql" "log")var id int64 = time.Now.Unix * 1000000func generateUniqueID int64 { return atomic.AddInt64(&id, 1)}func main { dsn := "root:root@tcp(localhost:3306)/test?charset=utf8" db, err := sql.Open("mysql", dsn) if err != nil { log.Fatalf("Error opening database: %v", err) } defer func { _ = db.Close } // 设置连接池参数 db.SetMaxOpenConns(100) // 最大打开连接数 db.SetMaxIdleConns(10) // 最大空闲连接数 db.SetConnMaxLifetime(time.Hour) // 连接最大存活时间 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { reqStart := time.Now var err error uni := generateUniqueID start := time.Now // Insert unique ID into the database insertQuery := `INSERT INTO test_last_insert_id (uni) VALUES (?)` result, err := db.Exec(insertQuery, uni) fmt.Printf("insert since: %v uni:%d \n", time.Since(start), uni) if err != nil { log.Fatalf("Error inserting data: %v", err) } lastInsertID, err := result.LastInsertId if err != nil { log.Fatalf("Error getting last insert ID: %v", err) } selectStart := time.Now // Verify the last insert ID selectQuery := `SELECT id FROM test_last_insert_id WHERE uni = ?` var id int64 err = db.QueryRow(selectQuery, uni).Scan(&id) fmt.Printf("select since:%v uni:%d \n", time.Since(selectStart), uni) if err != nil { log.Fatalf("Error selecting data: %v", err) } if id != lastInsertID { log.Fatalf("ID mismatch: %d != %d", id, lastInsertID) } fmt.Printf("success req since:%v uni:%d \n", time.Since(reqStart), uni) }) _ = http.ListenAndServe(":8080", nil)}截取了后面的一部分输出,这不会是SQL库的问题吧,
success req since:352.310146ms uni:1729393975000652 insert since: 163.316785ms uni:1729393975000688 insert since: 154.983173ms uni:1729393975000691 insert since: 158.094503ms uni:1729393975000689 insert since: 136.831695ms uni:1729393975000697 insert since: 141.857079ms uni:1729393975000696 insert since: 128.115216ms uni:1729393975000702 select since:412.94524ms uni:1729393975000634 success req since:431.383768ms uni:1729393975000634 select since:459.596445ms uni:1729393975000601 success req since:568.576336ms uni:1729393975000601 insert since: 134.39147ms uni:1729393975000700 select since:390.926517ms uni:1729393975000643 success req since:391.622183ms uni:1729393975000643 select since:366.098937ms uni:1729393975000648 success req since:373.490764ms uni:1729393975000648 insert since: 136.318919ms uni:1729393975000699 select since:420.626209ms uni:1729393975000640 success req since:425.243441ms uni:1729393975000640 insert since: 167.181068ms uni:1729393975000690 select since:272.22808ms uni:1729393975000671单次请求的时候输出结果是符合预期的, 但是并发SQL时会出现执行慢的问题,这就很奇怪了
% curl localhost:8080insert since: 1.559709ms uni:1729393975000703 select since:21.031284ms uni:1729393975000703 success req since:22.62274ms uni:1729393975000703经群友提示还和唯一键的区分度有关,两边算法一致有点太难了,Go换了雪法ID之后就正常了。 因为之前 Go这边生成的uni值是递增的导致区分度很低,最终导致并发写入查询效率变低。
% ./wrk -c100 -t2 -d3s --latency "http://localhost:8080"Running 3s test @ http://localhost:8080 2 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 44.51ms 24.87ms 187.91ms 77.98% Req/Sec 1.17k 416.31 1.99k 66.67% Latency Distribution 50% 37.46ms 75% 54.55ms 90% 80.44ms 99% 125.72ms 6960 requests in 3.01s, 509.77KB readRequests/sec: 2316.02Transfer/sec: 169.63KB今天本来是想验证一下有关,并发插入自增有序的唯一键高延迟的问题,发现整个有问题的只有一行代码。 就是在查询时,类型转换的问题,插入和查询都转换之后,空表的情况下QPS 可以到4000多。即使在已有大数据量(几十万)的情况也有两千多的QPS。 现在又多了一个问题,为什么用雪花ID时不会有这样的问题。雪花ID也是int64类型的,这是为什么呢。
// 旧代码err = db.QueryRow(selectQuery, uni).Scan(&id) if err != nil { log.Fatalf("Error selecting data: %v", err) } // 新代码 变化只有一个就是把uni 转成字符串之后就没有问题了var realId int64err = db.QueryRow(selectQuery, fmt.Sprintf("%d", uni)).Scan(&realId)if err != nil { log.Fatalf("Error selecting data: %v", err)来源:老男孩的成长之路一点号