Log4net内置了很多Appender但似乎找不到基于Http.在应用希望在本地保存日志的同时也可以把日志提交到一个Http服务中用于统一跟踪管理.如果每记录一次日志都提交给Http服务那对于应用端来说连接的创建是件很损耗性能的事情.由于日志不需要实时同步性,在设计上可以通过定时或当内存日志到达一定数量的时候才进行提交,这样就不会出现频繁提交日志带来的性能问题. 功能定义 Log4net实现一个Appender是一件比较简单的工作,只需要实IAppender接口即可以,当然Log4net也会提供一些基类方便我们实现.接下来实现一个httpAppender,在实 ...
由于前段时间在使用ServiceStack.Redis感觉不怎么方便和其代码实现也不理想所以就产生编写一个Redis .Net Client的想法(毕竟自己动手丰衣足食啊).实现的目的就是可以更简单了操作Redis并提供更多的数据处理方式如:String,json和Protobuf等。在操作Redis其实是通过TCP等方式来处理,所以它和其他网络服务一样有一个交互协议;Redis的交互协议比较怪异,第一次看感觉制定这协议很不合理……不过理解下来协议总体来说还是比较简单。 Redis的通讯协议可以说大集汇了……消息头标识,消息行还有就行里可能还有个数据块大小描述.首先R ...
IIS可以对ASP.NET站点进行一个资源控制,包括使用的CPU,处理进程数等.但如果想对某些动态页面进行一个资源限制,只允许固定线程数量来处理某些动态请求,而不至于在某些情况个别的动态请求把整个站的资源都占光了.对于这么小的粒度控制显然不适合由IIS来做,这个时候就可以通过asp.net提供IHttpAsyncHandler来解决这种事情. 处理结构 由于Asp.net提供了异步处理Handler,所以可以在Handler的Begin处理方法中把具体对象存放到队列中,然后根据实际业务的需要来配置1-N个线程来处理相关请求. IHt ...
在使用MSMQ的时候一般只会使用默认的XML序列化来对消息进行存储,但XML存储的缺点是序列化体积相对比较大和效率上有点低.其实.net提供非常简单的方式让我们实现不同序列化方式来存储MSMQ信息,如json,protobuf等.为了能够让开发人员实现自定义序列化的消息存储,.NET提供了IMessageFormatter这样一个接口,只需要简单地实现这个接口就可以对MSMQ的消息进行处理.以下讲解如何实现json和protobuf的messageformater. IMessageFormater接口 // 摘要: // 从“消息队列”消息体序列化或反序列化对象 ...
在网络通讯中相应的场景比较多,以下是针对Beetle在不同场景下的性能测试。 测描述 为了更接近实际应用情况,测试流程主要如下:数据接收->协议分析->数据反序列化成协议消息对象->消息对象分发->构建应答对象->序列化成协议数据->发送;而整个测试流程只缺少逻辑处理,不同应用逻辑处理存在差异,导致损耗也不一样所以并没有归纳到测试里去.测试用例分别有:1)高连接高并发,2)低连接密集并发,3)状态广播等三种情况. 测试硬件如下: 服务器采用E1230 V2版的至强CPU,8G内存和WIN2008R2的操作 ...
有些网络通讯场景存在大量信息广播,主要是把当前状态信息通知其他相关在线用户,从而体现更强的用户交互感。下面主要是测试一下Beetle在一些在线用户相互广播的交互能力。 测试描述 测试场景是以400个连接信息相互广播为测试用例就是当其中一个连接发送消息到服务端就会转发到其他连接上,测试情况分别是每个连接每秒广播2,5和10次,其服务器每秒的信息转发量分别320000,800000和1600000. 互动的消息结构如下: class Po : IMessage { public int ID; p ...
测试描述 测试是两台client分别每秒以600-1000的数量接入到beetle服务端,请求应答10次后自动断开连接。beetle对30秒内就没有进请求的连接进行强行关闭并释放资源. 测试结果 经过1千万次的连接接入和断开后beetle依然可以保证良好稳定地运行。 ...
测试描述 测试版:beetle 1.2 服务端: CORE E4300 1.8G  win2003 两台client建立4K个长连接,每个连接大概每0.1秒向服务器发送请求。 请求对象如下: class Register : IMessage { public string UserName; public string EMail; public int Tisk = Environment.TickCount; ...