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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,968评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,601评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,220评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,416评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,425评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,144评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,432评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,088评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,586评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,028评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,137评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,783评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,343评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,333评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,559评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,595评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,901评论 2 345

推荐阅读更多精彩内容