如果說數(shù)組是 PHP 的精髓,數(shù)組玩得不6的,根本不能算是會用PHP。那協(xié)程對于 Swoole 也是同理,不理解協(xié)程去用 Swoole,那就是在瞎用。
首先,Swoole 只能運(yùn)行在命令行(Cli)模式下,所以我們開發(fā)調(diào)試都是使用命令行,而不是 php-fpm/apache 等。
在 Swoole 中,我們可以使用`/Swoole/Coroutine::create()`創(chuàng)建協(xié)程,或者你也可以使用簡寫`go()`。
初識 Swoole 協(xié)程
- go(function(){
- go(function(){
- echo 0, PHP_EOL;
- });
- echo 1, PHP_EOL;
- });
- go(function(){
- echo 2, PHP_EOL;
- });
- go(function(){
- echo 3, PHP_EOL;
- });
執(zhí)行結(jié)果:
- 0
- 1
- 2
- 3
Swoole 協(xié)程與同步模式比較
我們一直在說 Swoole 協(xié)程適合用于 I/O 密集場景,在同樣的硬件配置環(huán)境下,它會比傳統(tǒng)的同步模式承載更多的訪問量。
我們熟悉的文件讀寫、網(wǎng)絡(luò)通訊請求(MySQL、Redis、Http等)都是屬于 I/O 密集型場景。
假設(shè)一次 SQL 查詢?yōu)?100ms,在傳統(tǒng)同步模式下,當(dāng)前進(jìn)程在這 100ms 的時間里,是不能做其它操作的。如果要執(zhí)行十次這個 SQL,可能需要耗費(fèi) 1s 以上。
而如果用協(xié)程,雖然不同協(xié)程之間也是按順序執(zhí)行,但是在前一個等待 100ms 期間,底層會調(diào)度 CPU,去執(zhí)行其它協(xié)程的操作。也就是說,可能第一個查詢還沒返回結(jié)果,其它幾個查詢就已經(jīng)發(fā)送給了 MySQL 并正在執(zhí)行中了。如果開啟十個協(xié)程,分別執(zhí)行這個 SQL,可能只需要耗費(fèi) 100+ms 即可完成。
測試代碼如下:
- Swoole/Runtime::enableCoroutine(); // 開啟一鍵協(xié)程化
- function work()
- {
- $pdo = new /PDO('mysql:host=127.0.0.1;dbname=db_test', 'root', 'root');
- $pdo->exec('select SLEEP(0.1)'); // 模擬sql需要執(zhí)行 100ms 的情況
- }
- $time = microtime(true);
- for($i = 0; $i < 10; ++$i)
- {
- work();
- }
- echo 'time: ', (microtime(true) - $time), 's', PHP_EOL;
- $time = microtime(true);
- for($i = 0; $i < 10; ++$i)
- {
- go('work');
- }
- swoole_event_wait(); // 等待所有協(xié)程執(zhí)行完
- echo 'time: ', (microtime(true) - $time), 's', PHP_EOL;
執(zhí)行結(jié)果:
- time: 1.0326268672943s
- time: 0.10734605789185s
上面的代碼可以假想為,單進(jìn)程處理 10 個請求所需的時間。每個請求需要執(zhí)行一次耗費(fèi) 100ms 的 SQL 語句。
同步模式,耗費(fèi) 1s 左右的是 fpm。可以看出,在等待 100ms 期間是不能做任何事情的。
協(xié)程模型,耗費(fèi) 0.1s 左右的是 Swoole。在等待 100ms 期間會掛起當(dāng)前協(xié)程,底層調(diào)度會讓 CPU 去執(zhí)行其它協(xié)程的操作。
新聞熱點(diǎn)
疑難解答