代码项目地址：WorkDayProject
因为好奇，（其实是因为闲），顺带看了 Benchmark 天梯，于是就写了一些代码来测试一下，以工作的项目中最简单的一个工作日计算功能为例实践了一些框架。
先解释一下什么是工作日？在这里的工作日不是指一般职员周一-周五上班的工作日，而是指证券交易所的交易日。以中国股市收盘时间15:00为界，15:01之前为当前工作日，15:01（含）为下一工作日，周六周日（非工作日）的所属交易工作日为第二周第一个工作日。举个栗子，2019/05/05周日是职工工作日，但它的所属工作日是2019/05/06。
公司线上使用了一套 WC[……]
在DeepIn ♂ WCF 中曾提到WCF中net.tcp协议的特有消息序列化格式。这个格式是微软的私有格式，对非微软.net客户端调用非常不友好，导致接口测试比较复杂，特别是性能测试。
因最近工作对某服务进行了大量的优化，需要通过性能测试展示优化的成果。传统上对net.tcp接口的性能测试会再搭建一个webapi站点代理测试流量，对于普通写库业务来说，单次接口请求可能时长长达100ms，webapi还是可以有效传导压力的。但是对于我这个查询类的服务来说，单次接口请求时长仅2ms，webapi这层代理不堪重负，不仅序列化反序列化占用大量CPU，还有到net.tcp短链的端口[……]
前文： windbg调试一个CPU100%的.net进程
windbg调试一个CPU100%的.net进程（二）—— What is mscorlib.ni.dll
某日因一大波僵尸（韭菜）的大量访问，某服务发生服务不可用故障，同时CPU使用率触发报警。
调查结论是：导致CPU使用率高的原因是锁冲突，性能计数器显示每秒发生锁冲突超过800次。产生锁冲突的是Log4net的UdpAppender。该服务写ELK使用了UdpAppender和log4net.Ext.Json插件，log4net.Ext.Json插件内部使用了System.Web.Script.Serializatio[……]
起因是运维强烈认为偶发 CPU 使用率100%是一个不好的现象，我查了告诉他们原因是多线程并发垃圾回收导致 CPU 使用率高。他们硬要我解决这个问题，我只能想办法解决垃圾回收使用的 CPU 核数。
大致能得到如下配置，能满足运维的降低CPU使用率的需求。
<configuration>
<runtime>
<Thread_UseAllCpuGroups enabled="true"/>
<gcConcurrent enabled="tr[......]
本来以为一篇已经能终结这个问题了，但是没想到还有续写这个topic的一天，当然我也发现了新世界的大门。
这次的犯人是157C（5500）号线程。
看着这个堆栈，我只能黑人问号？？？
what is mscorlib_ni+0x57cff2 ？？？
what is 0x000007fe`8a3856ba ？？？
what is mscorlib_ni ？？？
首先先解决 what is mscorlib_ni 。google 很久发现有一篇讲到了这个。
The mscorlib_ni.dll m[......]
最近应需求写了一个oracle到mysql的数据导入工具，本来想随便写写，直接把数据一次读到内存然后再写。后来发现性能略差，就试图做点性能优化，使用IDataReader，一边读一边写，然而mysql写速度根本跟不上oracle读速度，而且测试机只有双核4线程，开4个写线程CPU75%，6个写线程就95%了。
不过没有用到sql优化，mysql插入优化主要是拼接sql，比如说在values后面拼1000个（）。oracle就比较方便，参数绑定可以支持数组，这样就可以批量执行。类似于这样。
public int OracleExecuteBatch(string sql, List<[......]
出问题的程序还是那个CPU100%的程序（就你事情多）。反正就是在查CPU占用率100%时顺带发现的，在进程垃圾回收期间，服务停止响应，没有接口调用，没有调用日志，没有错误日志，在事件管理器的安全子类下出现大量 Event 5152 的审核失败日志，如图。
其中这个 Event 5152 是 Windows 筛选平台（WFP）的一个事件ID。
这个问题我还提问了Stack Overflow：
Windows Event-5152 happens during WCF program is GC and the WCF stops serving
so 上面的人认为是[……]
微软家的东西大多是基于消息（Message）和上下文（Context）实现的。所以总会有一个Manager的调度器存在负责传递消息和上下文。本文主要目的是通过编程实现获取接口调用时的参数，在前文中是通过 RequestContext 实现的，在这里则对WCF功能进行扩展。
参考文档：
最重要的架构图
这个架构图非常清晰的描述了这个 rpc 消息在 WCF 内部是怎么被调度的。（然而实际上我在写扩展的时候还是靠看 .net 源代码的
项目代码Demo：https://github.com/HDRorz/WcfServiceDemo
翻阅了[……]
所以为什么不用ASP.NET WebApi呢（这样就不需要IIS了（
流程上是先建一个WCF服务项目，然后用WCF配置工具打开App.config。在高级-终结点行为中新建一个配置，比如说起名为restfulBehavior，然后点下面的添加，选中webHttp，添加（当然也可以修改这个子节点的属性配置，比如说修改DefaultOutgoingResponseFormat为Json）。在服务-终结点里把Binging设置从原来默认的basicHttpBing改为webHttpBing，修改BehaviorConfiguration为刚才的restfulBehavior。
这样就完成[……]
