[.NET/Visual Studio] 如何使用Visual Studio Performance Profiler來找耗時操作?

 前言：

系統的優化最常見的是降低操作的執行時間，Visual Studio(以下簡稱VS)內建的profiler其一的CPU Usage是很適合的入門工具。

使用方式：

• 打開VS目錄 -> [Debug] ->[Performance Profiler](或快捷鍵Alt + F12)：

• 此例目標選擇「啟動專案」，選擇Release build / CPU Usage / Start with collection paused(執行profiler後自己啟動錄製) -> Start：

• 在要量測的執行前，按下Record，執行後，按下Stop Collection，即可產出分析結果

• 報表主要分為3個部分
• Top Insights：會列出主要問題，並可搭配copilot分析或優化
• Top Functions：依序列出耗時的函式
• Hot Path：可列出最耗時的執行路徑

To be continued...

參考資料：

https://learn.microsoft.com/en-us/visualstudio/profiling/cpu-usage?view=visualstudio

https://learn.microsoft.com/en-us/visualstudio/profiling/running-profiling-tools-with-or-without-the-debugger?view=visualstudio

https://learn.microsoft.com/en-us/visualstudio/profiling/cpu-insights?view=visualstudio

[.NET/Visual Studio] 如何使用Visual Studio Performance Profiler來找memory leak?

要抓.NET應用程式的memory leak，最基本就是使用Visual Studio Performance Profiler，

該如何用呢? 操作步驟如下：

• 打開Performance Profiler(Alt + F2)

• 選擇分析目標，此處使用啟動專案並勾選Memory Usage，點擊啟動(建議使用release build)

• 在baseline時機點，點擊快照

• 執行懷疑有memory leak的操作後，再快照1次來比較2次快照的差異(點擊紅框處)。

• 可針對size差異做排序，找出那些物件造成leak，點擊其中一個物件，下方面板會顯示此物件的參考鏈，就可以去判斷為何物件還沒被GC。

• 取得所需的快照後，即可停止收集，並可將結果儲存起來。

參考資料：

https://learn.microsoft.com/en-us/visualstudio/profiling/memory-usage?view=visualstudio

https://learn.microsoft.com/en-us/visualstudio/profiling/memory-usage-without-debugging2?view=visualstudio&pivots=programming-language-dotnet

https://learn.microsoft.com/en-us/visualstudio/profiling/hot-path-to-root?view=visualstudio

[UML] UML的關聯(association)、依賴(dependency)與差異

 關聯(association)與依賴(dependency)是UML類別圖常用來描述類別間的關係。

 關聯的表示如下，Customer關聯Order，用實線指到目標類別：

依賴的表示如下，MessageBroker依賴MessageFormat，虛線表示：

會覺得好像有點像? 

關聯是用在A類別擁有B類別的執行個體參考，如下程式碼：

而依賴則是代表A類別在其方法內建立或使用B類別的instance，

也就是A類別並沒有保存B類別的物件。

而箭頭上的數字就代表擁有參考的數量，如下圖就代表Customer擁有多張Order。

其實關聯還有其他2個特殊形式，聚合(aggregation)與組合(composition)，

不過直接用關聯表示也可以，除非真的需要特別呈現出來。

[Web] OAuth Authorization code flow筆記與取得google userinfo範例

 

Authorization Code是OAuth的其中一種授權方式，

可以讓client程式取得使用者(resource owner)外部的資源，需要使用者輸入帳密，

流程如下：

● 觸發驗證流程後，client程式將使用者的瀏覽器導向authorization server的驗證端點(authorize endpoint)。

● 此時網頁會顯示client程式想存取使用者在外部的哪些資源，等待使用者授權。

● authorization server依使用者回應與帳密決定是否授權。

• 若使用者允許，則authorization server會依client程式註冊OAuth服務時填寫的redirection URI，將authorization code導回給client程式。
• 若使用者不允許或無法成功授權，則將錯誤訊息導回client程式。

● client程式再帶authorization code、redirection URI等參數POST到authorization server的權杖端點(token endpoint)。

● authorization server確認參數無誤後，即回傳access token相關資訊，即可以此token跟resource server要資料。

以Flow chart描述流程如下：

來個實際操作吧，這邊使用Google OAuth來取得userinfo：

• 先到google developer console的Credentials頁面，新增OAuth client ID，至少要給redirect URIs，儲存後就會拿到ClientID與Secret。
• 組合取得Authorization code的url，紅色部份依實際狀況填入：

https://accounts.google.com/o/oauth2/v2/auth?

client_id=client id from google oauth setting&

redirect_uri=redirect_uri from google oauth setting&

response_type=code&

scope=profile&

access_type=offline&

state=up to you

• GET呼叫取得Authorization code的url，google server會callback Authorization code，code通常是4%2F開頭，要注意有url encode，所以要轉為4/。
• 接著POST呼叫要token，code就帶Authorization code，通常超過10分鐘會失效，如下圖，即可取得欲存取資源的token。
  
  
  
  
  
  
• 最後拿token即可存取授權的資源：

參考資料：

https://tools.ietf.org/html/rfc6749

https://developers.google.com/identity/protocols/oauth2/web-server

[Web] 初探Http Cache策略(cache-control)

前言：
瀏覽器會將從server下載回來的靜態檔案做快取，
好處是節省頻寬與資源，加快瀏覽速度。
壞處是需要針對存取資源做適當的快取配置，
讓client在瀏覽網頁的速度與資源的更新取得平衡。


作法：
除了更新資源檔案的檔名外，
一般都是從HTTP/1.1 header中的cache-control指令下手，
設定max-age(單位為秒數)，讓browser定期跟server擷取資源，
不過各browser作法略有不同。
FireFox從第2次開始，會自行帶max-age=0給server，

Chrome不會自行帶max-age的指令，還是需server設定，
且需再增加no-cache指令，讓browser發request來重新驗證資源是否更新，
否則Chrome仍然使用local cache。


max-age雖然可讓browser定期擷取資源，但若資源內容沒有變動，
也沒有下載的必要，因此會搭配ETag指令：
server會依快取的檔案內容產出一字串，回應給browser，
之後browser送出request會夾帶If-None-Match指令，如果字串比對一致，
則回傳status code 304(表Not Modified)，如下圖：

反之，若字串沒有match了，代表資源內容變更了，此時browser再重新擷取該資源即可。

建議font可善用CDN cache，分散又可降低server loading。


參考資料：
https://tools.ietf.org/html/rfc2616
https://tools.ietf.org/html/rfc7234
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
https://developer.mozilla.org/zh-TW/docs/Web/HTTP/Caching
https://medium.com/@codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c

[Network] TCP建立連線與關閉連線機制(connection establishment / termination)

TCP protocol屬於傳輸層(Transport Layer)，提供可靠傳輸與流量控制，
host與host溝通需先建立連線，過程共需3次封包傳遞：

用2個封包，可能會發生：
第1次送出的封包delay，client等不到回應，只好再送出SYN封包，
server先收到第2個SYN封包，且完成工作並關閉連線了。
後來第1個SYN封包送到server了，server就會建立多餘的連線...
因此，使用3次封包來回較可靠，俗稱3向交握(3-way handshaking)機制。

交握流程如下圖：

圖中的SYN與ACK，代表該封包的旗標(flag)，
在TCP封包的header中，用一6 bits的segment來表示：
[SYN]：000010。
[ACK]：010000。
[SYN,ACK]：010010。

其他segment：
seq：封包序號，由host自己維護，建立連線時+1。
len：封包的資料長度，不包含header。
ack：封包的確認號，建立連線時，為host接收到的序號+1。

對照使用Wireshark截取的封包。

Win：接收視窗，為該host陳述自己的可接受資料的快取byte。
MSS(Maximun Segment Size)：表封包一次最大裝載資料byte。
同樣Win下，MSS愈大，傳遞的封包愈少。


下圖是關閉連線的機制。

參考資料：
http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml

[Programming/Modbus] little-endian與big-endian

endian在CS裡指的是記憶體位址的排列，不同的CPU有不同的endian，電腦常用的Intel x86是little-endian設計，而big-endian設計的有Modbus PLC，與HP、IBM、MOTOROLA 68K系列CPU，究竟差在哪?


65534以1個word表示為0xFFFE，而記憶體是由左而右存放，
放到little-endian的記憶體會是

FE

FF

最低byte存放記憶體最前面，反序排列。

而放到big-endian的記憶體會是

FF

FE

最高byte存放記憶體最前面，依序排列，較適合人讀。

參考資料：
https://en.wikipedia.org/wiki/Endianness