亦有资源网

C++语言基础到进阶学习资源汇总

2025年03月28日

都说PHP性能差，但PHP性能真的差吗?

今天本能是想测试一个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 read
Requests/sec:   1901.92
Transfer/sec:    397.47KB

1900 ～ 2600 之间的QPS，其实这个数值还是相当满意的，测试会话会不会混乱的问题也算完结了。 但是好奇心突起，之前一直没做过go和php执行sql下的对比，正好做一次对比压测

package main

import (
    "database/sql"
    "fmt"
    "net/http"
    "sync/atomic"
    "time"

    _ "github.com/go-sql-driver/mysql"
    "log"
)

var id int64 = time.Now().Unix() * 1000000

func 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 read
Requests/sec:   1954.08
Transfer/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 read
Requests/sec:   1934.39
Transfer/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 read
Requests/sec:   2141.12
Transfer/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 read
Requests/sec:   2363.74
Transfer/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 read
Requests/sec:    631.86
Transfer/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 read
Requests/sec:   2296.19
Transfer/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 read
Requests/sec:    363.74
Transfer/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 read
Requests/sec:   2348.07
Transfer/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 read
Requests/sec:    200.73
Transfer/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 read
Requests/sec:   1957.70
Transfer/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 read
Requests/sec:    151.91
Transfer/sec:     11.13KB


go 的代码随着不断的测试，很明显处理速度在不断的下降，这说实话有点超出我的认知了。 PHP那边却是基本稳定的，go其实一开始我还用gin测试过，发现测试结果有点超出预料，还改了用http库来测试，这结果属实差强人意了。

突然明白之前经常看到别人在争论性能问题的时候，为什么总有人强调PHP性能并不差。 或许PHP因为fpm的关系导致每次加载大量文件导致的响应相对较慢，比如框架laravel 那个QPS只有一两百的家伙，但其实这个问题要解决也是可以解决的，也用常驻内存的方式就好了。再不行还有phalcon

我一直很好奇一直说PHP性能问题的到底是哪些人， 不会是从PHP转到其他语言的吧。

% php -v
PHP 8.3.12 (cli) (built: Sep 24 2024 18:08:04) (NTS)
Copyright (c) The PHP Group
Zend 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 version
go version go1.23.1 darwin/amd64

这结果，其实不太能接受，甚至都不知道原因出在哪了，有大佬可以指出问题一下吗

加一下时间打印再看看哪里的问题

package main

import (
    "database/sql"
    "fmt"
    "net/http"
    "sync/atomic"
    "time"

    _ "github.com/go-sql-driver/mysql"
    "log"
)

var id int64 = time.Now().Unix() * 1000000

func 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:8080
insert 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 read
Requests/sec:   2316.02
Transfer/sec:    169.63KB

2024-12-02 更新

今天本来是想验证一下有关，并发插入自增有序的唯一键高延迟的问题，发现整个有问题的只有一行代码。 就是在查询时，类型转换的问题，插入和查询都转换之后，空表的情况下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 int64
err = db.QueryRow(selectQuery, fmt.Sprintf("%d", uni)).Scan(&realId)
if err != nil {
    log.Fatalf("Error selecting data: %v", err)

标签：php基础 

作者:chayiyou , 分类:技术教程 , 浏览:15 , 评论:0

控制面板
您好，欢迎到访网站！
  查看权限
网站分类
最新留言