十万的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，只有优化连接数了，优化、测试的时间成本呢，客户的时间成本呢，或者客户能等你改好吗？