百度360必应搜狗淘宝本站头条
python判断字典是否为空crontab每周一执行aes和des区别安装指定版本npmadb pull
当前位置：网站首页 > IT知识 > 正文

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

liuian 2025-06-30 18:00 38 浏览

今天本能是想测试一个PDO持久化，会不会带来会话混乱的问题 先贴一下PHP代码, 代码丑了点，但是坚持能run就行，反正就是做个测试。

<?php
$dsn = 'mysql:host=localhost;dbname=test;charset=utf8';
$user = 'root';
$password = 'root';

// 设置 PDO 选项，启用持久化连接
$options = [
    PDO::ATTR_PERSISTENT => 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)

相关推荐

总结下SpringData JPA 的常用语法

SpringDataJPA常用有两种写法，一个是用Jpa自带方法进行CRUD，适合简单查询场景、例如查询全部数据、根据某个字段查询，根据某字段排序等等。另一种是使用注解方式，@Query、@Modi...

解决JPA在多线程中事务无法生效的问题

在使用SpringBoot2.x和JPA的过程中，如果在多线程环境下发现查询方法（如@Query或findAll）以及事务（如@Transactional）无法生效，通常是由于S...

PostgreSQL系列(一):数据类型和基本类型转换

自从厂子里出来后，数据库的主力就从Oracle变成MySQL了。有一说一哈，贵确实是有贵的道理，不是开源能比的。后面的工作里面基本上就是主MySQL，辅MongoDB、ES等NoSQL。最近想写一点跟...

基于MCP实现text2sql

目的：基于MCP实现text2sql能力参考：https://blog.csdn.net/hacker_Lees/article/details/146426392服务端#选用开源的MySQLMCP...

ORACLE 错误代码及解决办法

ORA-00001:违反唯一约束条件(.)错误说明：当在唯一索引所对应的列上键入重复值时，会触发此异常。ORA-00017:请求会话以设置跟踪事件ORA-00018:超出最大会话数ORA-00...

从 SQLite 到 DuckDB:查询快 5 倍，存储减少 80%

作者丨Trace译者丨明知山策划丨李冬梅Trace从一开始就使用SQLite将所有数据存储在用户设备上。这是一个非常不错的选择——SQLite高度可靠，并且多种编程语言都提供了广泛支持...

010:通过 MCP PostgreSQL 安全访问数据

项目简介提供对PostgreSQL数据库的只读访问功能。该服务器允许大型语言模型（LLMs）检查数据库的模式结构，并执行只读查询操作。核心功能提供对PostgreSQL数据库的只读访问允许L...

发现了一个好用且免费的SQL数据库工具(DBeaver)

缘起最近Ai不是大火么，想着自己也弄一些开源的框架来捣腾一下。手上用着Mac，但Mac都没有显卡的，对于学习Ai训练模型不方便，所以最近新购入了一台4090的拯救者，打算用来好好学习一下Ai（呸，以上...

微软发布.NET 10首个预览版:JIT编译器再进化、跨平台开发更流畅

IT之家2月26日消息，微软.NET团队昨日（2月25日）发布博文，宣布推出.NET10首个预览版更新，重点改进.NETRuntime、SDK、libraries、C#、AS...

数据库管理工具Navicat Premium最新版发布啦

管理多个数据库要么需要使用多个客户端应用程序，要么找到一个可以容纳你使用的所有数据库的应用程序。其中一个工具是NavicatPremium。它不仅支持大多数主要的数据库管理系统（DBMS），而且它...

50+AI新品齐发，微软Build放大招:拥抱Agent胜算几何?

北京时间5月20日凌晨，如果你打开微软Build2025开发者大会的直播，最先吸引你的可能不是一场原本属于AI和开发者的技术盛会，而是开场不久后的尴尬一幕：一边是几位微软员工在台下大...

揭秘:一条SQL语句的执行过程是怎么样的?

数据库系统能够接受SQL语句，并返回数据查询的结果，或者对数据库中的数据进行修改，可以说几乎每个程序员都使用过它。而MySQL又是目前使用最广泛的数据库。所以，解析一下MySQL编译并执行...

各家sql工具，都闹过哪些乐子?

相信这些sql工具，大家都不陌生吧，它们在业内绝对算得上第一梯队的产品了，但是你知道，他们都闹过什么乐子吗？首先登场的是Navicat，这款强大的数据库管理工具，曾经让一位程序员朋友“火”了一把。Na...

详解PG数据库管理工具--pgadmin工具、安装部署及相关功能

概述今天主要介绍一下PG数据库管理工具--pgadmin，一起来看看吧~一、介绍pgAdmin4是一款为PostgreSQL设计的可靠和全面的数据库设计和管理软件，它允许连接到特定的数据库，创建表和...

Enpass for Mac(跨平台密码管理软件)

还在寻找密码管理软件吗？密码管理软件有很多，但是综合素质相当优秀且完全免费的密码管理软件却并不常见，EnpassMac版是一款免费跨平台密码管理软件，可以通过这款软件高效安全的保护密码文件，而且可以...

一周热门
最近发表
标签列表