最近的發(fā)現(xiàn)在我嘗試過的所有其他事情中，我用自定義 JavaScript 替換了我的 JMeter 配置文件，該 JavaScript 在無限循環(huán)中依次訪問我的每個 API 端點，然后在不同的瀏覽器（一個 Firefox、一個 Chrome、一個 Safari）中并行運行這個腳本 -嘗試排除與來自同一來源的所有連接相關的問題（相同的用戶代理、相同的 cookie、相同的會話 ID 等）當我這樣做時，我注意到我所有的問題都消失了。查詢并行運行，應用程序的響應速度比 JMeter 讓您相信的要快得多在我看來，JMeter 將序列化請求似乎是不可能的，因為它是負載測試的事實上的標準。所以我開始嘗試重現(xiàn)這種行為為了重新創(chuàng)建 JMeter，我創(chuàng)建了以下兩個 PHP 腳本，它們（希望）模擬了我的 Yii 應用程序：慢.php<?phpsession_start();$_SESSION['some'] = 'value';// Yii is calling session_write_close() almost immediately after// the session is initialized, but to try and exacerbate issues,// I've commented it out:// session_write_close();$dsn = "mysql:host=localhost;dbname=platypus;unix_socket=/tmp/mysql.sock";$pdo = new PDO($dsn, "user", "password");// Yii was using whatever the default persistence behavior was,// but to try and exacerbate issues I set this flag:$pdo->setAttribute(PDO::ATTR_PERSISTENT, true);// Simulate a query running for 1 second by issuing a 1-second sleep$pdo->query("DO SLEEP(1)");echo "Done";快速.php<?phpsession_start();$_SESSION['some'] = 'value';$dsn = "mysql:host=localhost;dbname=platypus;unix_socket=/tmp/mysql.sock";$pdo = new PDO($dsn, "user", "password");$pdo->setAttribute(PDO::ATTR_PERSISTENT, true);// Simulate a query running for 0.1 seconds$pdo->query("DO SLEEP(0.1)");echo "Done";針對這兩個新端點運行 JMeter，沒有請求序列化。一切都是并行的。即使我擴展到 3、4 和 5 個線程，fast.php 總是在 100-150 毫秒內(nèi)返回，而 slow.php 總是在 1000-1050 毫秒內(nèi)返回。我能夠看到事情在 11 個線程崩潰，但那是因為我超過了 PHP 中的工作線程數(shù)所以總結(jié)一下：該問題僅在使用 JMeter 分析我的 API 時出現(xiàn)，并且不是應用程序本身固有的這個問題不僅僅是一個 JMeter 錯誤，而是與我的應用程序或 Yii 1.1 相關聯(lián)我試過但無法提出最低限度的復制案例盡管在使用其他工具進行分析時不存在該問題，但很多人做出了回應并提供了很多有用的信息：避免 PHP 中的持久連接（可能導致多個請求共享一個連接，可能不會）session_write_close()通過盡早調(diào)用來避免會話鎖定確保您有足夠的 PHP 工作線程來處理同時連接的數(shù)量MySQL 完全支持并行請求（如果硬件可以處理的話）警惕表鎖定（任何帶有UPDATE語句的事務都可能鎖定表）MyISAM 執(zhí)行表級鎖定而不是行級鎖定