無意間發現的這個神器webman，真是秋名山上的騰源拓海！
該框架是workerman下的一個web開發的生態，我們可以先看看這裏workerman的官方網站。
workerman早有耳聞，知道它蠻厲害的，跟swoole也不相上下，這次主要是說webman,可以看這裏
話不多說，趕緊上手。
1. 安裝
這個安裝真的很簡單，就一句話 composer create-project workerman/webman 就是它要求你的PHP版本和composer版本
- PHP >= 7.2
- Composer >= 2.0
很好，我們直接就跑起來
2. 修改服務端口配置
然後就進去 cd webman ，vscode打開這個文件夾， code .
找到 config/server.php 改一下默認的IP:端口。這裏我就把原來的 0.0.0.0 改爲了 127.0.0.1 端口繼續用 8787
然後就在命令行上面執行 php start.php start 把服務運行起來
好了，服務已經起來了。現在實際上就是 php在監聽 127.0.0.1 的 8787 端口
3. 分析入口代碼
我們看一下代碼
顯然這裏的controller是app下面的這個默認的 IndexController.php 文件控制器，好，我們打開這個文件可以看到默認方法
就是說首頁實際上是讀取了 README.md 文件來的，這樣，我們去訪問一下首頁的 http://127.0.0.1:8787/ 看一下結果，我們得到了這個
好的，然後我們嘗試着直接改一下這個文件看看。
我們改爲這個樣子看看
然後再刷新首頁
我們可以看到，這裏結果直接就變化了，這說明我們的代碼是立即生效的。這個和swoole還是稍微有點不同的，那個要重新啓動一下服務(不過我記得應該也有插件還是什麼來着能夠讓代碼立即更新的，但是要另外設置一下)
這裏我們可以將這個更新稱爲熱更新，就是服務還在運行，但是服務提供的代碼變了。
4. 分析靜態變量作緩存
這裏我注意到有個 static 關鍵字，感覺這個東西不得了啊，我就大膽的按照我預想的去嘗試了一下。
我將if判斷裏面加一個小小的調試。
好了代碼改好了，我們Ctrl+C把服務停掉，再執行一下把服務開起來 。
就像上圖我的操作一樣，我第一次點擊刷新進行訪問，命令行輸出了這句話 Will you only see me once time?
但是我後面的刷新訪問，再也沒有這樣的話輸出了，這說明了什麼？
這說明這個變量是在命令行裏面的靜態變量，就意味着，他只會在if裏面賦值一次，那也就是說，如果某些數據是從庫裏面拿到的而且不經常變化，我們完全可以拿這個靜態變量進行存儲，當作內存緩存在用，它比 file_get_contents 這樣的文件緩存還快。
因爲在以往php以 fastcgi或者FPM模式運行的場景下，請求與請求之間是獨立的，總是有服務器進行轉發或者解析的，那麼這個時候兩個請求之間是不能共用變量的，除非是那種 $_SERVER $_SESSION 等變量，但是這種東西顯然不合適用來存儲緩存數據的。所以我們一般會用 file 文件緩存serialize或者json_encode好數據，然後讀取的時候讀文件再反序列化來給後面的請求用，又或者我們覺得文件讀寫太慢更高級的 memcache redis緩存，但是即便是用這種內存服務器緩存，它也有開銷需要連接內存服務器，更激進一些我們用本地的Apc Yac緩存，可是這種東西我之前測試發現它有一個容量上面的限制，不是很方便給這種很大變量的緩存用。而這個時候我們能看到這個webman直接將靜態變量就能複用給不同的請求，實在是太快太方便了，等於後面的請求在index方法裏面就走了兩行代碼就直接return了，真的牛！
先別高興太早，仔細思考了一下，我覺得這樣也是有點風險的，如果開發人員塞進來一個大數組或大的變量，或者說開始寫代碼的時候數據量少，從數據庫讀出來就這樣賦值了，後來隨着數據量的猛增，這個內容越來越大，這樣命令行這裏佔用的內存也將越來越大，我猜測這裏的變量是不釋放的，直接是給下一個請求在用，我不知道這個框架它有沒有那種自動回收變量內存的機制，如果沒有，那這裏還真可能是個安全隱患。
所以，這對於我們開發而言，就必須要更謹慎小心的使用這個功能，雖然它真的很快很好用。
好了關於這裏的靜態變量緩存我們先探討到這裏，然後我們看看另外兩個方法。
5. 首頁另外兩個方法
這裏看看另外兩個方法，一個是 view ， 一個是 json
view的就很簡單，代碼如下
就是渲染了模板，然後賦值name變量，簡單猜測一下 肯定是在什麼 view 文件夾裏面的 index 文件夾 裏面的 view.html 之類的
然後去看了看果然
好了，這裏很簡單，就是把 name 變量輸出來，看看訪問效果
咦？怎麼會這樣，這裏不通？又想了想，哦，原來是 1234678，年輕人不講5的(武德) 啊！
重新按照這個訪問 http://127.0.0.1:8787/index/view
好了，有了。
然後再看看另外一個 json 的，代碼如下：
吸取教訓，這樣訪問 http://127.0.0.1:8787/index/json
得到了序列化json，可能你會奇怪爲什麼你的瀏覽器訪問的效果不是這樣的，你可能得到的是這樣的
哈哈，那是因爲我給我的chrome瀏覽器安裝了一個插件，叫 JSON-handle
你可以在 chrome 的插件市場裏面搜索JSON找到它
當然了，很有可能你都打不開這個網站。(你看看這站點域名就知道了)
6. 請求壓力測試
好了，現在該給它上點強度了。我下載了一個軟件叫 ddosify 。你可以這樣安裝它 sudo apt install ddosify
然後在命令行裏面 對剛剛的這個站點來測試一下。
先執行這個，給它來個 5000 個請求
ddosify -t http://127.0.0.1:8787/index/json -d 1 -n 5000
用 ddosify 給這個URL http://127.0.0.1:8787/index/json 進行請求(-t參數設置)，持續1秒(-d參數設置)，發起請求 5000次(-n參數設置)
看樣子感覺良好嘛，平均時間是 0.00187s 也就是 1.87 毫秒，不過畢竟這代碼啥也沒幹就返回了json。
再加大強度！上2萬個請求！
好傢伙，真是人才啊！這都頂住了，成功率百分百，而且花費時間反而短了，只用了 0.36 毫秒，都不知道說啥好了。
再加大力度！ 上5萬個請求！
總算出現失敗了吧。看樣子還是慢厲害的，都頂住了這麼多請求，這在原來nginx或者apache的那種場景下，不知道會怎麼樣。
沒有數據是沒法說話的，我們試試看。現將代碼修改成一樣。
先看看apache2 啓動！ sudo systemctl start apache2 再次測試
果然5000就頂不住了
後續我又測試了一下，2000也沒頂住啊，不過也有可能是我的apache2沒有調優導致的。
好，再看看 nginx。
好樣的 nginx! 頂住了第一波 5000 個請求
再上點強度！2萬個請求試試看。
再加大強度！5萬個請求試試看。
看來大家都是在5萬個請求這裏頂不住了。好的，你們已經盡力了，辛苦同志們了！
從單純的返回json數據的請求測試結果來看，這個框架還是厲害的，也能和nginx有一定程度上的媲美，我也感覺到了webman真是秋名山上的AE86啊！
感覺有了這個框架，就像給拓海的AE86換上了4A-GEU發動機，讓他不再受制於馬力的大小限制，真正狂飆起來！