好奇，想問問原理。
SCF 冷啟動，一直運行著 webman。
然後休眠的時候webman是停止了的。
然後有請求的時候又 運行一次。
請問是這樣的嗎？

SCF 可以理解為一個docker 服務(wù)節(jié)點， 用的你鏡像啟動 docker， 啟動workerman后，開始向9000端口發(fā)送 API網(wǎng)關(guān)傳來的http請求，然后結(jié)果通過API網(wǎng)關(guān)再給 用戶。 時間一長沒人調(diào)用了，就把你的容器給kill了，如果訪問量越來越大，騰訊云會 docker run 容器數(shù)量越來越多，來處理請求。 騰訊云SCF容器運行，全局只讀，僅/tmp可寫

我剛嘗試了，除了業(yè)務(wù)代碼不是send_mail，而是直接改為return response('hello webman');*默認index的，
壓測結(jié)果
成功率：99.83%
超時數(shù)：56
平均耗時：117.84ms
最大耗時：9328ms
請求數(shù)：41270
平均TPS：314.34/s
持續(xù)時間： 02分 31秒

默認scf下的php-fpm:
成功率：100%
請求數(shù)：43146
超時率：0
平均耗時：143.59ms
最大耗時：5555ms
平均TPS：341.18/s
持續(xù)時間： 02分 31秒

感覺把webman部署上scf對實際毫無用處....
測試我是用weTest進行壓測的，
我個人的理解：

scf拉取了image->部署完->執(zhí)行webman對9000端口進行監(jiān)控。
后續(xù)有請求或并發(fā)加大的時候，scf會同時部署多個webman進行緩解壓力。

問題就出在docker部署在其余節(jié)點的時候，首次訪問導(dǎo)致超時和降低了TPS。

實際場景下也沒法直接把webman項目轉(zhuǎn)至scf上，畢竟只有tmp可讀取，已有項目改動太大了。

如果有理解錯的地方希望指正

感覺說毫無用處略顯極端。
我覺得這個模式挺好，部署更簡單了，智能橫向擴容+webman的高性能 可應(yīng)對高并發(fā)請求。
至于壓測才300qps，感覺是哪里遇到瓶頸了，猜測有可能是帶寬不夠，最好能內(nèi)網(wǎng)壓測。
只有tmp可寫這個也好改，軟鏈就解決了。

的確可能說的比較極端，
但是tps的壓測結(jié)果只是api網(wǎng)關(guān)的問題，這里只需要對比即可。
上面的壓測結(jié)果是使用scf+webman的
下面的壓測結(jié)果是使用scf+phpfpm。

然后你提到的，
“部署更簡單了，智能橫向擴容+webman的高性能 可應(yīng)對高并發(fā)請求”
其實你就算是普通的phpfpm，在scf上也是 “智能橫向擴容”，
而提到的webman的高性能，
實測結(jié)果就是把webman部署在scf上并不能獲取任何高性能。（參考上述壓測結(jié)果。

“只有tmp可寫這個也好改，軟鏈就解決了。”
現(xiàn)有項目除非存儲掛載了去COS/CFS，如果我沒記錯scf下tmp目的下寫入的數(shù)據(jù)每次都會被清空。

webman的邏輯應(yīng)該就是首次加載，常駐，從而提升速度。
但是去到SCF上，由于SCF的邏輯是按需加載（php-fpm的思想），所以反而導(dǎo)致webman的性能有所下降。

另外我不是想抬杠，
把webman丟上去無服務(wù)函數(shù)里執(zhí)行我之前也有過想法。
但是深入考慮后，覺得自己當(dāng)時想法根本不夠成熟，
這次LZ發(fā)了教程，自己剛好還有壓測資源，就順著去做了個測試，
實測結(jié)果確實和當(dāng)初所想一樣。
所以我才希望能通過交流來確認是否我做法上或考慮上存在問題，
我上面的壓測對比僅僅是針對SCF環(huán)境下的因素。

還有我上面一直有說錯，SCF上并不是PHPFPM和webman的對比，剛查看了SCF的手冊，
上面執(zhí)行PHP代碼是直接通過CLI方式進行的，意味著是webman和PHP CLI的對比了。
如果按手冊上面的這個說法，把webman弄上SCF真的就是毫無意義了。
倒不如直接使用SCF的laravel框架

webman的邏輯應(yīng)該就是首次加載，常駐，從而提升速度。
但是去到SCF上，由于SCF的邏輯是按需加載（php-fpm的思想），所以反而導(dǎo)致webman的性能有所下降。

如果是這樣，那確實沒啥用處了

你好，我剛看到，請移步阿里云測試，騰訊云同學(xué)找我了，說他們的冷啟動還需要跟進，這種部署的優(yōu)勢，不需要買服務(wù)器，節(jié)省成本
而且無限橫向擴容，單點服務(wù)器太累了，
并且，現(xiàn)在騰訊云支持 預(yù)支并發(fā)了，需要內(nèi)測申請，我已經(jīng)測試了，他預(yù)留幾個已啟動的容器給你用，而且你要去看運行耗時，SCF走的api網(wǎng)關(guān) 網(wǎng)關(guān)經(jīng)過3次轉(zhuǎn)發(fā)，影響實際請求測試，

并且，阿里云支持寫，騰訊云不久也會支持寫。

晚上我會再次 詳細測壓，對比騰訊云和阿里云 云函數(shù)

您誤會我的意思了.
我只是單純的想對比webman上SCF 和 不使用webman的區(qū)別；
就如上面所提到，我認真看完了SCF的手冊，發(fā)現(xiàn)SCF運行PHP就是通過CLI形式進行的，而不是通過PHP-FPM進行。
在這個場景下的比較已經(jīng)沒有任何意義了。
這就好比
webman：phpcli(常駐)->webman(常駐)->業(yè)務(wù)流程處理；
php：phpcli(常駐)->業(yè)務(wù)流程處理
這也印證了我上面提到的，scf上phpcli效率和webman效率相差不大的問題。

是的，SCF下就是php-cli運行的，所以 他不能用$_POST等直接來獲取 ，必須要按照他的規(guī)定來修改入口處理文件，這是代碼部署的模式下，

我說的是鏡像部署，正常開發(fā)就行，不需要兼容入口文件。如果是鏡像部署，cli啟動是php -S 0.0.0.0 這玩意效率不行，而且 鏡像部署中使用webman可以做到，自定義處理協(xié)議，在SCF上。

其實 話題偏離了，我想表達是 替換掉服務(wù)器