活着，就一直在忙碌，從未有停歇。

活着，就一直在忙碌，從未有停歇。

最近，忙裏偷閒，整理本身的技術知識體系，隨便寫寫，權當Mark。

問題界定

發現問題，解決問題。

案例一：高併發和MongoDB交互

問題描述：Job跑起價時，CPU Load很高。

Dump分析：查看線程調用棧信息，有42個線程在以下狀態

說明稍微高一點併發時，記錄日誌會有問題，反編譯能夠看到DoAppend時會lock住當前對象。

而代碼中採用一個實例，且設置的緩衝區大小爲2，重寫的SendBuffer方法中和MongoDB交互。

因此，這裏是因爲頻繁的和MongoDB交互引發的高CPU Load。

 

優化方案：

1.改變緩衝區大小，設置一個較大的值。但若是日誌不夠多，可能好久寫不出來。

2.自定義一個日誌池，根據時間和個數的雙重維度控制，異步批量的和MongoDB交互。

案例二：接口耗時較多

問題描述：CPU Load很高。

Dump分析：

先查看線程數，再打印出每一個託管線程的調用棧信息，沒有發現明顯問題。

繼續，查看線程的耗時，發現有兩個線程耗時爲30秒，從調用棧信息查看，是同一個接口。

對該接口作壓力測試，5個併發時CPU在90%以上，因此是因爲接口耗時較多，致使併發時高CPU Load。

 

性能分析：

用VS Analyze Tool對接口作性能分析，發現重複調用了從redis中取某個特定緩存數據的方法

跟蹤代碼，發現對於相同的緩存數據，用兩種方式重複取： 
1.循環，取單個緩存。 
2.一次取全部緩存。

因此這裏取重複了，多了一倍的耗時，經過調試能夠驗證這個結論。因此，首先要剔除重複。

以後，查看爲什麼從Redis取緩存如此慢，緣由是以json字符串格式存取Redis的，因此取時須要反序列化，能夠針對這點再考慮優化存取方案。

基礎架構

Quartz.NET、ActiveMQ、Unity、Autofac、Git等。

   

其中，進程間通訊，除了WebAPI，還包括：

        

分佈式系列

Hadoop沒實踐過，只是以前看看書而已，都快忘了。。。

 

分層

 

H5和ASP.NET MVC都不是特別熟，用戶表現層就不說哈~~

數據持久層

SQL Server、MySQL、Mongodb等。

 數據倉儲層

經過ADO.NET或EF等ORM工具，實現和數據庫的交互操做。

數據緩存層

使用Memcached、Redis或自建緩存系統。

業務領域層

C#

數據結構與算法設計

代碼倉庫

 

細節，有時間再慢慢道來吧。。