安德魯的部落格

  1. .NET Core 跨平台 #3, 記憶體管理大考驗 - Windows Container (2016 TP)

     

    這次 .NET Core 的實驗做完，我看相關的 How To 可以寫一堆了 @@，整個過程中都在挑戰過去很少做的事情，包括 Linux, .NET Core, Docker, 現在連 Windows Container 都出動了.. 不過試完之後一整個充實啊，最後能把預期的結果弄出來，幾個晚上睡不飽是值得的…

    接續上篇文章，這篇就把 windows 的兩個平台測試給搞定吧! 先快速交代一下打算當作對照組的 Windows 2012 R2~

    2015/12/28 系列文章: .NET Core 跨平台 .NET .Net Core Docker 作業系統 專欄

  2. .NET Core 跨平台 #2, 記憶體管理大考驗 - setup environment

    記憶體管理，是跟底層平台高度相關的議題。對於 developer 來說，能掌控的部分很有限，developer 能做的動作，不外乎是 allocate / free memory, 頂多對於 GC (garbage collection) 的機制更明確的掌握而已。超出這個範圍以外的部分，就真的只剩下好好處理 exception 的份了…

    這次 .NET Core 開源 + 支援 Linux / MacOS, 正好開創了一個新的平台支援，實際測測看，是掌握差異最快的方式。我挖出了當年的老文章探討的記憶體管理問題，在新的平台上驗證。不同平台的差異，遠比我想像的精彩，就順手把它寫成文章整理起來，給需要的人參考。

    2015/12/27 系列文章: .NET Core 跨平台 .Net Core AZURE C# Docker 專欄 技術隨筆

  3. .NET Core 跨平台 #1, 我真的需要在 Linux 上跑 .NET 嗎?

    最近這幾篇 .NET Core / Docker 相關的文章貼出來之後，最常聽到有人問我的問題就是:

    “要跑 .NET 就在 windows 上面跑就好了，要在 Linux 上跑 .NET 有甚麼意義嗎?”

    其實還蠻有意義的 XD，這兩個月每天下班花一點時間研究之後的心得，.NET Core 的確還在起步的階段 (現在才第一版 RC)，跟已經進展到 4.6 的 .NET Framework 完整成熟的生態來說真的差太遠，現階段來看還完全沒有什麼誘因值得立刻轉移到 .NET Core + Linux 上面執行。不過眼光放長遠一點，這我認為到是個蠻值得的投資。怎麼說? 以下是我的觀點，跟大家分享:

    2015/12/26 系列文章: .NET Core 跨平台 .NET .Net Core AZURE C# Docker 專欄 技術隨筆

  4. [.NET Core] Running .NET Core RC1 on Docker - DOTNET CLI

    Microsoft Connect 2015在半個月前，Microsoft Connect 2015 大會上正式宣布 .NET Core / ASP.NET 5 正式推出 RC1. RC 代表開發已經到了準備 release 的階段 (RC: release candidate), 功能都已完備 (FF: feature freeze), 品質也到一定的階段，RC 推出後若沒碰到重大問題，那接下來應該就是 RTM 了。 若你擔心 Beta 跟最終的版本落差太大，而不願意太早投入了解 .NET Core 的話，那現在是個適合的時間點了! 這次除了版本進展到 RC1 之外，Microsoft 除了在 Docker Hub 釋出了新版的 image 之外，也推出了另一個新的命令列工具集: DOTNET CLI, 同樣也提供 Docker Container 的 Image 可以使用。 原本開始研究 Docker, 目的是為了有個簡易上手的 .NET Core / ASP.NET 5 在 Linux 上面執行的環境而已，我真正的目標是了解 .NET Core 跨平台的轉移過程，以及跨平台帶來的效益 (單純的在 Linux 上執行並不是重點，而是在 Linux 上面執行後可以帶來其他的資源跟優勢，以及對企業大型佈署可以獲得的效益) ...  不過這陣子越玩越大，研究 & 體驗的範圍也擴大到正式佈署上會用到的幾個重要服務 (apache, nginx, docker, mysql ... etc)，加上拿了我自己的部落格當白老鼠實際體驗，弄到現在才回到正題 =_=，正好趁那些偏離主題的研究告一段落，現在正好回頭來試試! 接著下去之前，先看看官方發布的消息:

    Announcing .NET Core and ASP.NET 5 RC1

    image_3

    Today, we are announcing .NET Core and ASP.NET 5 Release Candidate, supported on Windows, OS X and Linux. This release is "Go Live", meaning you can deploy apps into production and call Microsoft Support if you need help. Please check out theAnnouncing ASP.NET 5 RC blog post to learn more about the updates to ASP.NET 5.

        這篇我分幾個角度來探討 .NET Core. 如果你是想看 Step by step 的教學，或是想看看新版本有甚麼功能，或是哪裡下載等等，那請直接 Google 新聞或是官網就可以了。我的重點會擺在我的研究過程發現的心得，一些官方文件上沒寫的資訊，以及我研究過程得到的結論跟想法等等。接下來這系列我會談到這幾個主題，一篇寫不完的話就請各位等待續集了~ Progrmming / Coding 相關的探討，我本來就會定期分享，因此這系列文章我會著重在跨平台以及 .NET Core 本身的改進，還有原本就用 Microsoft Solution 的企業，導入 .NET Core + Linux 後帶來的效益。主題包括:
    1. DOTNET CLI, 跟 BETA 時期的 DNX / DNVM / DNU 的關係
    2. DOTNET CLI 搭配 Docker 的使用技巧
    3. CODING 實際上機: Hello World (Console)
    4. (下回分曉) Inside .NET Core Runtime, Windows / Linux 的差異 #1, Compute PI (performance)
    5. (下回分曉) Inside .NET Core Runtime, Windows / Linux 的差異 #2, Memory Fragment Test (memory management)
    6. (下回分曉) (還在想...)
    這次不碎碎念了，直接從第一個主題開始!  

    新玩意: DOTNET CLI, 整合 DNVM / DNX / DNU 的命令列工具

    隨著這次的 RC1 Announcing, 原本 Beta 時代的那些命令列工具, 也開始有新版本了。原本的工具分別負責 RUNTIME 的管理 (DNVM)，執行 (DNX)，維護 (DNU).. 現在被集中在同一個指令 dotnet 底下了，也就是這次新發布的 DOTNET CLI。 不過這個 CLI (Command Line Interface) 版本還很前期，看她的編號才 0.01 alpha , 離正式版本還很久，因此這次是分成兩個 container image 發行:
    • microsoft/aspnet: 這個 image 還是跟上次介紹文章寫的一樣，用的是 DNVM / DNX / DNU 這組指令，指示相關的版本已經升級到 RC1，使用方式跟前幾篇文章介紹的都一樣，這次就略過，後面應用測試時有需要再拿他出來..
    • microsoft/dotnet: 這個則是另一個新的 image, 裡面放的就是 .NET Core 新版的命令列工具 (v0.0.1-alpha preview). 功能差不多，不過比之前有組織的多。DNVM / DNX / DNU 這些指令第一次看到還真的會搞混，從名字完全看不出是幹嘛用的，新版工具的命名就清楚的多，同時也追加了一些新功能，像是編譯成 Nativa Code 等等，這些是之前 Beta 版時期還沒有的機制
     

    DOTNET CLI Container 的使用技巧

    開始介紹我的使用方式錢，先把幾個關鍵的參考資訊貼一下... 現在的參考資料還不是很多，除了官方少少的幾份資料之外，碰到問題根本還 Google 不到甚麼東西，只能自己憑經驗摸索 @@
    1. 來自 Microsoft GitHub 的 Readme: .NET CLI Preview Docker Image
    2. 來自 Microsoft GitHub 的 Quick-Start 說明: It is very easy to get started with .NET Core on your platform of choice.
    其他我參考過的相關資料還有這幾篇:
    1. ASP.NET 5 and .NET Core RC1 in context (Plus all the Connect 2015 News)
    2. .NET Blog / Announcing .NET Core and ASP.NET 5 RC
    3. .NET Web Dev and Tools Blog / Announcing ASP.NET 5 Release Candidate 1
    4. ScottGu's Blog / Introducing ASP.NET 5
    5. Scott Hanselman / Visual Studio 2015 Released plus ASP.NET 5 Roadmap
    OK, 參考資訊交代完，來看 Hands-On Lab 吧. 在過去幾篇文章哩，我都只把 Container 當成像 VM 一樣使用，把 SERVER 裝在裡面開起來用。然而 Container 實際上可以不用像 VM 隔離的這麼遠，他是能退化成單一應用程式來使用的.. DOTNET CLI 在 GitHub 的 README 也教你這樣用:

    Compile your app inside the Docker container

    There may be occasions where it is not appropriate to run your app inside a container. To compile, but not run your app inside the Docker instance, you can write something like:

    $ docker run --rm -v "$PWD":/myapp -w /myapp microsoft/dotnet:0.0.1-alpha dotnet compile
    This will add your current directory as a volume to the container, set the working directory to the volume, and run the command dotnet compile which will tell dotnet to compile the project in the working directory.
    其實關鍵就在中間 Docker 用的指令: "--rm" 會在這個 Container 執行完畢之後立即刪除它的狀態，等於你這個 Container 變成可拋棄式的 Container 了，以這個範例來說，用 Docker Run 啟動 Container, 透過 -v 掛載目錄，用 Container 內的編譯工具編譯你的 APP，結束之後就直接把這個 Container 狀態給刪掉，就跟 docker rm 一樣的作用.. 這招挺好用的，不過我在開發測試階段，要不斷的執行，老是進進出出 Container 也是不方便，因此我用的指令稍微修改一下，啟動的不是編譯器，而是啟動 shell, 結束這個 shell 之後才是刪除整個 Container. 以下來看看我的步驟，我打算從無到有，寫一段 Hello World 的 C#, 並且執行它，在畫面上印出 "Hello World!"，過程中要經過 create project (init), download dependency packages (restore), build (compile) 以及 launch (run) 幾個步驟.. 直接來看做法: 首先，先準備好 Docker 環境，取得 Microsoft 釋出的 .NET Core CLI image: 
    chicken@localhost:~$ sudo docker pull microsoft/dotnet

    完成後，用下列指令啟動 Container 內的 shell, 並且進入這個 shell: 
    chicken@localhost:~$ sudo docker run --name dotnet --rm -t -i microsoft/dotnet /bin/bash
root@6b021f6be610:/#
    第一行的 prompt 提示訊息還是 Linux Host OS, 執行成功之後，第二行的 prompt 就換成 Container 內的 shell ，代表執行成功! 如果你有現成的 code 想丟進去 Container 編輯使用，可以用 -v 加掛 volume 進去，不過我這邊的範例還不需要，我就略過了。接下來就進入這套新的 CLI: dotnet. 先來看看 dotnet cli 到底支援幾種命令? 
    root@6b021f6be610:/# dotnet -h

    就 compile | publish | run 三個，不過查了 Microsoft 的官方文件及範例，才發現原來還有好幾個指令列出來 @@, 第一個就是 dotnet init, 它可以幫你 init project, 有點類似 Visual Studio 在你 Create New Project 的時候做的事情一樣，指不過這個比較陽春。直接來試試: 
    root@6b021f6be610:/tmp/HelloWorld# dotnet init

    執行過 dotnet init 後，就會在目前目錄下建立 Program.cs 及 project.json 兩個檔案。預設的內容我就直接列給大家看了。若你另外有搭配開發工具，例如 visual studio 2015 等等，其實這個步驟就可以省掉了，整個資料夾直接搬過來就好。 這次我 create project 後，先不改任何 code, 直接進行下一步。下一步是把這個 project 所有需要的相關套件，從 NuGet 下載下來，作用就跟之前的 DNU restore 一樣，只是現在改了個名字重新包裝，變成 dotnet restore。第一次執行可能會下載一堆 depency packages, 放著讓他跑完就 OK 了: 
    root@6b021f6be610:/tmp/HelloWorld# dotnet restore

    中間還一堆... 我就不貼了，直接跳到最後面:

    沒想到一個 Hello World 就這麼多相依的套件要處理... 完成後就可以進行下一步，編譯你的程式! 我特地把 --help 顯示出來，其實看的到這個版本開始支援 compiles source to native machine code 了。看看後面的文章有沒有機會寫到這部分 :D 
    root@6b021f6be610:/tmp/HelloWorld# dotnet compile -h

    直接開始編譯，碰上兩個警告訊息，應該是相依的 assemblies 版本衝突，這問題暫時略過，下次再回頭探討: 
    root@6b021f6be610:/tmp/HelloWorld# dotnet compile

    編譯完成之後不執行它的話，不然要幹嘛? 接下來可以用 dotnet run 來啟動: 
    root@6b021f6be610:/tmp/HelloWorld# dotnet run

    走到這邊，總算大功告成! 各位的 .net code 若想 porting 到 linux 上面，就這麼簡單.. 當然這邊指的是操作程序的部分而已，我想 porting 最大的門檻應該是在那些只有 windows 版的 .net framework 才支援的 BCL (basic class library) 以及尚未支援 .net core 而無法在 linux 上執行的 3rd party 套件吧，那部分的 code 改寫才是最痛苦的.. 這種問題好像隔幾年就會來一次，當年轉移到 win32 api, 轉移到 x64, COM 轉移到 .NET, ... etc.. 其實我在嘗試的過程中，也碰到不少其他困難，懊惱的是 google 也還查不到太多前輩的經驗可供參考... 我覺得主要問題應該是 beta / rc 之間的差異造成的.. 我原本在 windows 10 上面用 visual studio 2015 (asp.net 5 beta 8) 開出來的 .net core project, 直接搬過來 microsoft/dotnet 這個 container 執行時卻困難重重，包含 runtime 不支援 (預設跑到 .net frmework 4.6.1)，相關的 assemblies 找不到，或是 nuget 無法找到正確版本等等，甚至也有編譯等等都成功，執行也成功，但是 console output 卻沒有顯示出來等等怪異問題。 這些問題的排除，等我先把我的環境全面升級到 RC1 之後再來驗證一次，我相信現在開始接觸 .net core 的朋友們應該也會碰到類似問題吧，我的經驗給大家參考~  

    2015/12/06 .Net Core C# Docker

  5. CaseStudy: 網站重構, NGINX (REVERSE PROXY) + 文章連結轉址 (Map)

    網站架構調整後有感: 要學習另一個陣營的技術，還真是條不歸路，越挖越覺得要摸索的東西越多 @@ 照例前面先來點碎碎念，正題後面再來。這年頭，大型的佈署是少不了 Linux + OpenSource Solution 的，再加上我吃飯的傢伙 ASP.NET 的下一版 (vNext, .NET Core) 也要正式跨各種平台了，不熟悉一下 Linux 以後怎麼會有能力把寫出來的 code 搬到 Linux 上面執行? 不過，要跨到完全另一個生態體系的環境，還真要下點決心才跨得過去… 所幸，我挑對了切入點 (把自己的 BLOG 從 BlogEngine 轉移到 WordPress, 架設在 NAS + DOCKER 環境)，這幾個月下來，也算累積了不少的心得 :D 要在 Linux 的世界裡打滾，最痛苦的就是安裝各種軟體了，只能說那真是地獄… @@，尤其是對於不熟 Linux 的人來說更是如此。現在有各種套件安裝的工具，向是 APT-GET 之類的，其實已經簡化很多了，但是難的在後頭，各種的 configuration 都要自己編 conf 檔，而每套系統用的語法都不一樣… 我不論是在 Coding 或是 System Admin 時，都很講究系統架構。因此往往預設的安裝我都不滿意，我都會想盡辦法用最基礎的模組，搭建出我認為最理想最適合的架構。很多組態都必須自己研究摸索，都需要碰到進階的安裝設定，這也是要開始認真用 Linux 的我最大的障礙… 然而我的目的不是要熟悉這些 configuration 啊，我目的是架設出期望的系統，來解決後續的問題，這些繁瑣的安裝設定機制 (除非必要，像是這篇要講的 Rewrite ) 就能省則省… 所幸 Docker 的出現，正好給了我這種人一個機會，我只要搞定最基本的 Docker 執行環境，其他安裝就簡單了，找到正確的 container image 就一切搞定。加上我用的 NAS 內建 Docker 的支援，連 Linux + Docker 架設都免了… 至於為何要這麼大費周章的熟悉 Linux ? 轉貼一則最近看到的新聞… 連 Microsoft CEO Satya Nadella 都公開表示 “Linux is Best for Cloud” 了，多年的 Microsoft 信徒軟絲當然要花時間去研究一下.. XD

    Microsoft Agrees Linux is Best for Cloud

    Ever since the new CEO, Satya Nadella, has taken the place of the Linux-hater Steve Balmer, the change in Microsoft’s rhetoric regarding Linux has been clear. Now, Microsoft is officially recommending Linux on Twitter.

      好，看到分隔線，就代表正題開始! 前面幾篇有跟到的讀者們，應該都知道我之前在研究甚麼.. 為了在我能力範圍內用最快的方式搭建能夠執行 .NET Core 的 Linux 環境，我選用了 Synology NAS + Docker 來踏出第一步. 為了快速熟悉各種實作技巧，我把自己的 BLOG 從原本的 BlogEngine ( ASP.NET ) 轉移到 WordPress (現在還是 PHP, 以後要變成 Node.js 了)。前兩篇說明了用 Apache 做前端的 Reverse Proxy, 同時也為了 新舊系統的文章轉址，用 Apache 的 RewriteMap 解決 400 篇文章 x 6 種網址格式，多達 2400 種組合的新舊網址轉址。 就當越用越熟練之際，我擔心的問題來了! NAS 再好用，他終究不是正規的 SERVER … NAS 的硬體都不怎麼樣，我的 Synology 412+ (Atom 2701D + 2GB RAM) 很快地就碰到瓶頸了，多開兩個 container 就明顯 的感覺的到回應變慢了… 於是我決定開始把我的 BLOG 系統轉移到 Ubuntu Server 上，用專屬的硬體來架設 (NB)。架設的硬體其實也很巧，是我老姊請我幫她處理掉的舊 NB。拿舊的 NB 其實很適合，一來省電，二來 Linux 省資源， 跑 Windows 跑不動，換成裝 Linux 跑個人 BLOG 其實還綽綽有餘，三來 NB 內建的電池正好當成 UPS，也省了一筆開銷… 。接手的 NB 硬體只是貧弱的 Intel Pentium P6100 + 4GB RAM，不過不管在運算能力或是 RAM 都遠比 我現在的 NAS 強… 於是架好 Ubuntu Server + Docker 後就開始動手了

    先來看看這次我想調整的架構圖。第一張圖是現有的架構，就是兩個月前剛轉移 BLOG 用的架構: NETWORK 第二張是我想調整的新架構，也就是這次要做的:

    這次的調整，我決定沿用之前的架構，就是前端用 Reverse Proxy 來發布藏在後面的 WEB application, 因為後面有好幾個 Docker Container 需要同時用一個 IP + 80 port 發布，這層是跑不掉的。加上大量舊網址轉址的需求，我不想把這個複雜度加在 WordPress 上面，所以這需求就落在 Reverse Proxy 身上。原先的架構中，Reverse Proxy 是用 Apache Httpd 來負責 (因為 NAS 內建 apache httpd, 而且已經把 port 80 佔住了，沒辦法換掉)，現在自己架設 Ubuntu Server 就沒有這些限制，我當然就改用現在當紅的 NGINX 來代替。 既然都用 Docker 了，其實找到正確的套件，設定一下就搞定，單純系統安裝的部分我就跳過去了。架構上調整的兩個較大的工程我補充一下:

    1. 前端 Reverse Proxy 的部分，改用 Nginx 。這邊面臨的是上一篇文章說明的轉址技巧，還有對照表的部分必須重新來過，改用 nginx 的 conf 重新設定一次。
    2. 原本架構只用了兩個 container, 分別負責 WEB 及 DB，資料檔案是直接掛上 local server 的目錄。這次則按照 Docker 官方建議，建立了專門管理資料用的 VOLUME-CONTAINER。

    調整後的架構跟效能，應該都會遠比原本的好。直到現在用了 Docker, 才開始對當年學 UML 的 deployemnt diagram 有感覺… 後來 Visual Studio Team Suite 也出現過這個功能，可以繪製 deploy diagram (強的是還能跟你實際的 code 雙向同步)。但是當年的實作上，總覺得實際要處理的問題遠比 diagram 要複雜得多，系統架設跟UML表達的架構，中間距離還很遠，往往高階架構都只在架構師腦袋裡，真正執行的工程師則被一堆設定的細節給淹沒了，直到現在有了 container 技術，才開始覺得佈署系統就真的跟 deployment diagram 上講的是同一件事，真的就是把元件拉出來，按照設計圖一個一個擺到定位，線接一接就完成了。 Volume-Container 的應用，有機會再另外寫一篇吧，先來看看 NGINX Reverse Proxy 的部分: 在上一篇在解決新舊系統網址對應最主要的技巧，就是如何簡潔又有效率地做好 2400 條轉址的需求。主要就是用 Apache 的 RewriteMap 來兼顧 Rule 的撰寫及對照表的維護。而同樣的機制，在 nginx 上也有，不過語法不大一樣，我先貼一段 example:

    # map blogengine with slug (encodded title) format
if ($uri ~* "^(/columns)?/post(/\d+)?(/\d+)?(/\d+)?/(.*).aspx$") {
    set $slug $5;
    return 301 /?p=$slugwpid;
}

    Nginx 的 Map 簡潔到不能再簡潔了，加上他用的 C Like 設定擋語法，老是讓我有個錯覺，覺得我在寫得是 script 而不是在寫設定擋… 然而簡潔到極致的 Map 用法，我看了半天才看出他的端倪…   上面這幾行，背後有條看不見的線，把 $slug 跟 $slugwpid 這兩個變數串起來… 當我把某個數值 assign 給 $slug 時，Map 的機制就會偷偷的啟動，用 $slug 的值去查表，把查到的結果放到 $slugwpid, 然後接著 run 後面 的 script / config. 上面這幾行，意思就是每個 request, 會把他的 URI 部分 (不含 hostname) 抓出來，用後面的 regular express 比對， 抓出第五個 match ($5) 的內容，指定到 $slug 這個變數內。接著透過 MAP 的機制，下一段指令 return 301 /?p=$slugwpid; 就是 用 HTTP 301 的方式轉址，轉到 /?p=xxxx 這樣的網址。 這看不到的機制，靠的就是整個 nginx 設定擋的另一個部分定義 MAP 的效果:

        map $slug $slugwpid {
        include maps/slugmap.txt;
        * 0;
    }

    Map 這精巧的機制想通後就很簡單了，Map 的宣告後面直接接兩個變數，一個是原變數 ($slug), 另一個是查表後對照的結果變數 ($slugwpid)。你在任何地方把數值指定給 $slug 的話，同時間另一個變數 $slugwpid 的值就會被替換掉。 說穿了不值錢，這些可是我研究了好一陣子才搞懂的。研究的過程中我也去找了 NGINX for Win32, 這樣測是起來比較方便，有需要快速體驗或測試 nginx 的朋友可以參考。用這個來研究設定擋的寫法，可以省掉很多時間 (畢竟我還是 windows 操作比較熟悉…) 最後就是對照表的定義了。NGINX 的設定蠻有彈性的，如果你的對照表不多，可以直接寫再 CONF 裡面就好。不過我的狀況有四百多篇文章，我選擇放到外部檔案再引用。我貼片段的對照表內容出來:

    GoodProgrammer1 65; # 2008/09/27, 該如何學好 "寫程式" ??
IBM-ThinkPad-X111- 252; # 2005/06/28, IBM ThinkPad X111 ...
e6b0b4e99bbbe5b7a5e697a5e8aa8c-1-Cable-TV-e99da2e69dbf 146; # 2007/09/12, 水電工日誌 1\. Cable TV 面板
e5a682e4bd95e59ca8e59fb7e8a18ce6aa94-(NET)-e8a3a1e99984e58aa0e9a18de5a496e79a84e8b387e69699 180; # 2007/02/28, 如何在執行檔 (.NET) 裡附加額外的資料?
X31-2b-e99b99e89ea2e5b995e79a84e68c91e688b0-_ 273; # 2005/03/06, X31 + 雙螢幕的挑戰 @_@
e588a9e794a8-NUnitLite2c-e59ca8-App_Code-e4b88be5afabe596aee58583e6b8ace8a9a6 215; # 2006/10/29, 利用 NUnitLite, 在 App_Code 下寫單元測試

    格是很簡單，就是新舊對照的值，一筆一行。兩個字串用空格隔開，最後用 ; 結尾。如果有需要的話， # 之後的字串會被當成註解忽略掉，就像上面這樣。還好這格式跟之前 Apache 用的 RewriteMap TXT 格是很類似，我用文字編輯器簡單替換一下其實就搞定了 看了 NGINX 官網的說明，他的 MAP 彈性大很多，除了靜態的字串對應 ( key / value pair ) 之外，可以包含萬用字元，也可以包含 Regular Express, 也就是說他也包含某些運算能力在 Map 裡。我擔心的是這麼一來 MAP 也許就無法像 Apache 一樣，把 Map 編譯成二進位的 Hash table 格式，大量查表的效能也許會受影響… 這邊我就沒有像上次一樣查 benchmark 了，不過新環境運算能力本來就強很多了，同時 nginx 本身效能也比 apache 強的多，加上我的舊文章數量又是固定的 (400)，數量還不算太大，也不會再繼續成長下去，測試過沒有明顯的影響，我就暫時不理它了 XD 好! 寫到這邊，其實搬家動作大概就告一段落。雖然如此，也是花掉我幾個下班休息時間才搞定的… 我想應該很多人跟我一樣，想從熟 Microsoft 領域，跨越到 Linux / Open Source 的領域而不得其門而入的困境吧? 我這系列文章都會用實際的案例，說明我 “為什麼” 會這樣做，而不是只有單純的 step by step. 畢竟比我熟這些操作的人太多了，人外有人.. 這應該輪步道我來寫。而我真正想分享的，是這些架構規劃面的經驗。希望我這些實作的案例 & 紀錄，可以幫到跟我一樣從 Microsoft Solution 要跨越到 Linux 這邊的人  :)

    2015/12/04 BlogEngine.NET Docker Tips

Facebook Pages

Sponsor Ads