十万的License只取决于一个连接

十万的License只取决于一个连接_第1张图片
License

前段时间看到一份代码,小规模、低难度的一个应用,MVC用到极致,业务逻辑却混成一团麻,应该是中了培训班的毒。现在的程序员,大多是没仔细读过《现代操作系统》,没看过编译原理,不知道堆与栈,没怎么用过C、C++,上手就Java、C#,程序一开就内存狂飙,数据库连接随手就建,但这种人算是相当多了,见多了也就习惯了。

前两天看到一篇文章,作者使用的是InterSystems的数据库,这是一个美国公司,为医疗卫生行业提供重要的网络平台,不少国外的IVD厂商都有用到。作者描述的问题很简单:

服务器相当的不稳定,每天都会宕机。
挂了的时候所有的程序都连接不上数据库,大概过10分钟左右又好了!
找来找去说是数据库的License不够了,所以不让新的连接上来,那就纳闷了。虽然Intersystem公司卖的License贼贵,一个就要十万块,但是通过加上ECP,基本上就多出来1000个License Units,咋还会不够用呢?

首先,License 授权是个相当复杂的计算方式,拿 SQL Server 来说,SQL Server不同的版本有不同的功能,不仅价格颇有差异,获得许可的方式也不尽相同,高的有1万9千多刀,总的来说,有两种基本的授权(License)模式。

一、“每处理器”或“每核”模式
“每处理器”(Per Processor)授权模式只计算物理处理器的数量,与物理处理器的内核数量无关。按“每核”(Per Core)计数,同时还需要计算物理处理器(插槽)的数量,单个插槽最低需要购买4核。

这一授权模式可以很好的简化授权的复杂程度,不用统计有多少用户(或者设备)会访问SQL Server,以及是防火墙内部还是来自Internet的外部连接。

二、“Server+CAL”模式
CAL即客户端访问许可(Client Access License),分为设备访问许可(Device CAL)和用户访问许可(User CAL)两类。SQL Server及其组件(例如报表服务)提供服务,客户端则是访问这些服务的设备或用户。

购买CAL时需要考虑有多少客户端需要访问SQL Server并从中获取数据,客户端的计算方式与中间层无关,只与最终有多少客户端能够获取(包括浏览、修改、删除数据等)SQL Server服务器中的数据有关。

标准功能每客户端大概940刀。

回到主题,作者在License Usage 里面看到License Usage by User,同一个IP对应多个连接数但是UserID还是一样的,也就是说你开N个连接或者程序,UserID都是相同的,而且都是同一IP地址,当然,用的License也就是一个,但是,你会发现原来它会计算Connections,也就是连接数。
问题来了:

If the number of processes exceeds this maximum, a transition occurs and Caché begins allocating one license unit per process for that user ID. The system presumes that if more than maxconn connections are associated with a user ID, multiple users are accessing Caché through an intermediary, (for example, a firewall system) so additional license units are required. Therefore, when the (maxconn + 1) process starts, the number of license units allocated to that user ID changes from one to (maxconn + 1). Processes started by the Job command are allocated against the process limit of the user ID invoking the Job command.

原来一个License的进程数或者连接数是有最大限制的,如果超过这个最大限制的话,那就变成了每个连接都使用给一个单独License,难怪服务器会爆掉了。

比如我这边看最大连接数是25。
那就很少了,设备启动时候的用Job函数增加的进程也算在内,如果我们在这台电脑启动多个接口那就占用了多个进程数量了,万一多开几个程序,那完了,就爆了。

为啥有这个规定呢?
可能是为了控制你不用路由器的,如果你用路由的话对公网的IP地址都是一样,Cache就没法判断你到底有多少个终端了。
对于这种问题能怎么办呢,只能想办法优化一下连接数了。

这里要吐槽一下,国内的LIS厂家开发人员的水平跟互联网公司差十万八千里,当然,也可以推到DBA身上,因为99.99%的LIS厂家和大部分的医院都没有DBA。无论是内部开发还是第三方调用,都是一个用户,完全不考虑安全性问题,或者也有考虑安全性的,就是不开放数据访问,也不提供接口,逼第三方去想歪招;不过我已经看到有些LIS厂家已经开始提供WebService接口了,虽然没有遵循ASTM协议或HL7协议,但也是一个进步。
回到最前面说到问题,小应用场景或开发环境下,该做的优化不做,如果遇到这样的问题呢,总不能让客户花十万买License,只有优化连接数了,优化、测试的时间成本呢,客户的时间成本呢,或者客户能等你改好吗?

你可能感兴趣的:(十万的License只取决于一个连接)