在工作上的需要接触道路运输车辆卫星定位系统相关应用,由于自己对网络服务的编写比较感兴趣,所以利用空闲时间实现了JT/T808的一些协议和相关服务(不得不说这种协议的设计在解释的确导致性能上的损耗,特别针地托管语言的C#来说就更加容易导致性能问题,不过对于现有硬件资源来说一台简配的PC支撑上几万个终端那还是没什么压力的).主要基于兴趣来写所以JT/T808只实现了几个常用的协议:0x0002,0x0200,0x0100等.         为了更好地 ...
        基于接口的调用远比基于基础消息交互来得更简单和便于维护,特别在业务展现上,接口作为业务表现更适合其便利性。为了让SmartRoute更适合业务应用集成,在新的一年开始SmartRoute集成了远程接口调用功能。基于SmartRoute的基础特性,在这基础上扩展的接口调用会变得更简单灵活,其特别点如下:并不需要知道服务地址,只需要明确接口和方法即可以实现远程服务调用;无需任何配置即可实现负载和故障迁移。而这一系列的更利功能都归攻于SmartRoute基础建设!    &nbsp ...
        SmartRoute是基于Dotnet Core设计的可运行在linux和windows下的服务通讯组件,其设计理念是去中心化和零配置即可实现服务通讯集群。SmartRoute是通过消息订阅的机制实现服务与服务之间的通讯,它可以让广播网段内所有服务器上的应用自动构建通讯集群; 而通讯集群完全是SmartRoute自动构建并不需要进行任何配置或安装中间服务。通过这种全新的通讯开发方式可以让开发者更轻松和简单地构建基于服务的集群通讯应用。 SmartRoute的发展目标 ...
        .Net Core出来的了一段时间,它是微软提供夸平台的一个基础.既然.Net Core是后起之秀那它和.NET在windows平台上的性能差异又怎样呢,相信也我们比较关心的。对一个Framework所提供的功能非常多,对不同功能进行测试对于我个人来说也不太现实;接下来我针对.NET Core和.NET的内存读写这一块进行一个性能测试对比,毕竟这是整个运行时所处理的基础,对性能的差异有一定的代表性。 测试描述         对基础类型包括字符 ...
        最近.Net Core在.NET圈子里还是挺火的,之前有接触过Mono并做过相关测试感觉效果并不理想。这段时间由于工作原因闲下来所以对针对.Net Core的基础通讯模块进行一个简单的压力测试,了解一下其性能情况;在测试后发现.NET Core这方面的性能还是做得比较出色,似乎比他的前辈.NET在windows的性能表现还要出色(看来微软这一次真是动了真格了)。 测试描述         现在的硬件发展速度非常快,所以测试出的效果应该都会比 ...
        在实际应用中为了满足程序或组件加载的需要,往往需要制定个性的信息配置要求。虽然.NET提供了相关类定义的支持,但通过代码写起来还是比较麻烦的事情;还好有开源爱好者针对这一功能做了相关插件,通过表单设计的方式来 实现配置信息订制功能。详情查看:http://csd.codeplex.com/  新建配置项         安装了CDS插件后,在项目添加项里就可以找到相关项目 新建后我们根据实际配置 ...
        有一段时间没有思考代码相关的工作了,最近项目经常碰到不同业务流水号的生成,下面的技术人员每次都针对流水号生成写一些复杂的代码;为了解放以后这方面的工作于是动了一下脑子想一个动态可配置的流水号生产组件,虽然没写代码一段时间但脑子在这方面还是挺灵活,大概想了一下基本就构建出一个通用业务流水号配置功能,以下分享一下这个设计。 流水号拆分 其实业务流水号都是由不同总分组成,每部分都表达不同的含意。所以在设计上需要对流水号进行分解。以"GZ201602020001RJ"的主要组成部分:{GZ}{20160202} ...
public class IDFactory { public IDFactory() { LoadIPGroup(); InitMillisecond = (ulong)(DateTime.Now - DateTime.Parse("2000-1-1")).TotalMilliseconds; mWatch.Restart(); } private ulong mCurrentMillisecond = 0; private ...
        一客户需要对websocket服务应用,其要求每秒同时给3W个在线的websocket连接进行广播消息.以下针对beetle.express扩展websocket简单的性能测试.从测试结果来看基本没什么压力 ...
        Redis是一个非常高效的基于内存的NOSQL数据库,它提供非常高效的数据读写效能.在实际应用中往往是带宽和CLIENT库读写损耗过高导致无法更好地发挥出Redis更出色的能力.下面结合一些redis本身的特性和一些client操作上的改变来提高整个redis操作的交通.         上图是反映平常操作redis的情况,每个线程都独立的发起相应连接对redis的网络读写.虽然我们可以通过批操作的方式来把当前多个操作合并成一个,但这种 ...