精华内容
下载资源
问答
  • 二是对于技术含量高的企业,普通员工也是“依赖资源”,通过实施员工持股计划稳定这部分资源,对于企业发展的作用同样不可估量。 3、创原天地公司实行经营层与员工持股可以达到以下目的: (1)对企业核心资源...
  • 稳定员工队伍,吸收和引进外部优秀人才; 第二条 方案基础 本方案的制定主要有如下基础: XX省国资委印发的《省属国有独资和国有绝对控股企业国有产权经营管理人员经营业绩考核暂行办法》中“股权激励”的相关...
  • 管理者如何保持团队稳定性

    千次阅读 2013-12-14 20:37:56
    先不说最终比分如何,微博上一条神回复让我觉得挺搞笑但又挺有感触: ‘足球比赛,百度VS 360 是百度老员工和百度新员工的比赛’ 事实其实也是这样,和我一起08年入职还在公司的员工真心不多。每次我刚入职所在的...

    前段时间,各大互联网公司间举行了一次‘互联网公司足球大赛’,其中一场比赛是百度对战360, 百度有最帅气年轻的VP李明远参与的球队, 最终于。。。。先不说最终比分如何,微博上一条神回复让我觉得挺搞笑但又挺有感触: ‘足球比赛,百度VS 360  是百度老员工和百度新员工的比赛

    事实其实也是这样,和我一起08年入职还在公司的员工真心不多。每次我刚入职所在的小组的10多个同事聚会,提到我还在公司,他们都会露出惊讶的表情: 怎么还在百度!

    的确, 我一直都惊讶百度的离职率是如此之高, 但后来了解到其他互联网公司也差不多, 甚至更高,频繁地跳槽似乎已经成为一种常态。 但无论如何,对于一个公司来说,过高的离职率本身就是不正常的,作为管理者,就应该通过各种手段降低离职率,而不是因为行业如此,就任其为之。

    以下就通过我个人在百度的经历,经验以及教训, 以及公司中的培训,说下我碰到的员工离职的原因, 以及在管理者能够操作的范围内,如何挽留员工,保持团队的稳定性及士气。

    总结下来,主要有两个因素影响员工去留: 职业发展和薪水,即前途和钱途,员工的离职,基本上都是因为这两方面的原因

    职业发展有可以细分为团队的发展和个人的发展。不恰当但形象的例子,我们可以将团队的发展看成是股市的大盘而个人发展看成是具体的股票, 大盘疯涨的时候,个股一般都会水涨船高,大盘低迷的时候,很少有股票能够表现惊人。 例如在一个公司作为战略重点的部分会是组,得到的资源更多,更容易出成绩,而一些边缘部门或组,事实上就不太受重视,也没有太多资源投入,发展很慢,缺少核心技术,员工看不到未来。薪水则是马斯洛论述的底层需求,高薪水是高物质生活的象征,而且帝都生活压力也挺大的, 所以这个因素也会对员工的去留取决定性作用。

    让员工对团队的认可和信心

    员工都是在具体团队中工作, 团队做的事,方向就是这个员工的舞台,同样舞蹈功底的人,在人流涌动的中关村地铁站口与在满座的国家大剧院 跳同样的舞, 获得的关注及成就感肯定不一样;或者用另一句通俗的话讲: 台风来的时候,猪都能上天。 当然搞IT的都不是猪,大家都很聪明,团队的核心价值及接下来要做的事是否能得到员工认可就至关重要, 如果得到认可,员工就会认为自己是在国家大剧院跳舞,自豪感,满足感油然而生;而如果员工悲观地觉得自己只是个中关村街边的流浪艺人, 那么他会对未来悲观,迷茫,也许之后他会好好想想是不是要找另一个个像国家大剧院的舞台。

    另外很重要的一点,就是就是leader是否能给员工信心,一直都听说马云初创的时候,很多人都一直跟着马云,就是信任马云,这个leader就像是古代战场上的将军一样,如果有一个自己佩服的老大,那就算团队,业务有较大的调整变动,但下边的人仍然有信心跟着老大,充满信心;而如果团队中这样的人离开, 那么员工也可能会因为看不清未来而选择离职。所以有时留住团队留住领军人物,就显得至关重要了。

    非常现实的事实: 前些天老大说我们优化团队为支持无线的后续发展会进行调整以更高效地支持无线变现,正当团队热火朝天地组织各种讨论, 各种规划的时候,突然得到消息,后续计划有变, 团队会被整体划到另外一个部门,当时团队里知道这个消息的人真是惊呆了,与老大沟通了半天我也没感觉到团队划出去的好处,怎么看都是效率变低,当时真的立马就有一丝想离职的冲动。。。

    另外对一些级别比较高的员工,有时也会因为对公司,团队一些做事的方向,理念,思路及做事方式不认可,而去寻找新的环境。

    解决之道:明确团队方向规划,认可团队价值

    需要让员工了解团队的价值, 让员工觉得自己是在为一项事业而工作,而不是简单的搬砖头,螺丝钉。

    管理者需要明确团队的定位及核心价值,在此基础上制定明确的roadmap,并将这些信息充分向下传达并保证大家都能认同这些信息。 如果员工有内容不认同, 则需要详细了解是因为什么原因导致不认同,并及时使用有针对性的措施或是及时调整。同时要时时为员工打气,让其认识到团队的使命感, 自己的重要性。员工认可团队的核心价值及roadmap后,即使碰到风浪,他也会像乘坐在大船中一样,知道远航的目标。

    当然,有时候明确团队方向这个问题, 受到管理者所在大环境的限制,相当于管理者所在的大环境决定了员工所能上升到的天花板。例如有些部门喜欢不断提出(或是从其他部门抢夺)一些新的项目,并且将其规划得很大重点去推,在项目推进的过程中,员工会感觉到自己做的事前途无量,上升空间很大。当然这种方式也有一个风险,就是更新更受关注的项目出现的时候, 资源很容易就被投到新项目。做原有项目的人会觉得被冷落而有一种失落感。 还有些部门是守着自己的疆土,将某一领域做深, 在自己土地上还能深挖的时候,员工会觉得自己能学到很多东西,能有成长, 但当整个领域已经达到一定高度,技术带来的提升不明显,而管理者提前没有去开发新领域时, 就可能出现问题。

    相对于所处大环境决定的员工发展的天花板,员工管理者帮助员工制定的个人规划,则相当于在既定的天花板的事实上,如何让员工更接近这个天花板。管理者可以在这块有更多的发挥, 或者说也只能在这块上多做一些事。

    让员工对自己发展有信心

    以前一个同事的跟我说过‘自己只是公司微不足道的一小部分,对对于自己却是全部’,很多时候我们会谈公司的使命,价值观, 这个的确很重要,因为没有使命,没有明确价值观的公司很容易走偏,这些东西在将员工凝聚在一起时起了不可估量的作用,但很多时候员工更关注自己的发展,如果员工觉得自己的发展出现了瓶颈,看不清未来,且这种状态持续一段时间,那么他离职的可能性也非常高。

    我们可以将员工对个人发展的认知过程分为: 向前看和向两边看两种方式。

    向前看, 是指员工分析自己的个人发展,是否认可自己在团队,公司的发展及前景。 包括员工想在这个公司,这个团队做怎样的事,获得什么提升,有怎样的提升。

    例如员工对照自己在团队中所负责的工作,感觉到这个工作规划比较清晰, 且在接下来的较长时间, 这个方向可以长时间投入且有较大的提升, 那么这个员工肯定干劲十足全情投入;反过来,如果这个员工觉得以同样的状态方式, 在接下来一两年都不会有太大长进, 那除非他就是想在公司养老,否则他肯定会考虑动一动,找一个自己认可的方向,团队或是公司。

    另外员工如果感觉到自己的老大不重视自己,或是不重视自己所做的工作,员工也会比较沮丧,这也会滋生员工离职的想法。  这些是员工对自己发展的向前看的方式。

    相对地,向两边看,是指员工与公司其他员工,或是公司,部门内外同行,同事的比较,也许员工在公司里的晋升并不慢,但如果员工看到觉得和自己水平差不多的员工发展得更好更快, 那么他也会产生一种不公平的感觉。比如我之前的一次经历: 经理告诉我没有晋升,我很沮丧, 他花了很多时间和我沟通,总算让我心情平静了一些,但当晋升结果公布时,平常由我带着做项目的员工居然晋升,界别比我高时,我出离愤怒了, 当时立马产生离职的念头。 后来经理又各种安抚。 这也或多或少有点不患寡而患不均的味道。

    解决之道: 给空间,重认可,多指导

    给空间: 我们经常会说一个贬义词(至少很多时候我觉得是个贬义词): 画大饼。  但画大饼真的比较重要, 而且很多时候, 没有画的大饼, 就不会有真正的大饼。 画大饼, 其实就是为员工描绘了关于他自己的一个美好的远景。 当然, 只画大饼远远不够,也许画大饼的时候员工的确能够对未来有美好的憧憬,不过一旦员工发现大饼是不能做成的,那后果会比较严重,不仅之后的画大饼不起作用,同时员工也会对管理者失去信任。 所以管理者不仅要画大饼,还要给足员工做大饼的料,帮助员工做成大饼。例如一开始给员工一个明确的目标规划,那就需要在资源上支持员工完成这个目标,时候也要和员工一起回顾目标完成的情况,是员工没做好,还是料没给够。如果料没给足,那很多时候管理者就需要反省了

    重认可: 这里主要是指员工的工作是不是得到管理者,团队及公司的认可,这里包含两个层面: 第一是否得到精神上的认可。如果员工觉得自己的工作及成果连自己的管理者都没有认可,那员工很少能有后续动力继续推进,这种认可很多时候可以是语言上的和行动上的,管理者对员工的任何成长进行语言或物质上的奖励,都会带来正向的效果。例如一句及时的口头表扬,一封邮件,或是季度,年度的一个奖项,都能带来较好的效果。但同样的,管理者的行为细节会让员工感觉到管理者是否受到重视,所以管理者要非常注意在员工面前的表现, 相由心生,员工会根据管理者的这些行为细节(正确或错误)地感受到自己是否真的受重视。

    同时管理者要非常重视one-one的过程,员工表现好的地方要多给表扬,激励其再接再厉,表现不好的地方,要以一种帮助其进步的姿态指出,并给其建议。

    第二是实质上的认可, 最明显的就是员工有没有因为所做的工作而得到晋升,因为公司有自己的流程,所以有时的确会出现很多人做的很卖力,也得到了很多精神奖励,例如口头表扬,个人奖项, 但没有晋升的情况(况且不谈这样的流程是否是最合理的); 如果出现这种,员工也会认为的工作没有被认可,得到了不公的待遇,也会产生较为负面的影响。应该尽量减少这种精神和实质认可不一致的情况。

    多指导

    给了空间, 有了认可以后, 还需要持续指导员工。 这里的指导又包含多方面的,例如经理的指导和直接导师的指导, 而且很多时候导师的指导更加重要直接。 好的导师能够让员工学习到更多的东西, 无论是知识或是方法,同时能保证员工能够在自己的工作中不走偏(这个也需要经理的更多参与),导师在身边能在一定程度上增强员工的安全感。

    薪水的重要性

    事实上,现在人们生存的压力的确也比较大,所以一方面上级,团队,公司的认可,能够满足自己更高层次的追求,但作为马斯洛基本层次的需求, 薪水也是影响绝大部分员工去留的重要因素。也许他在团队中工作比较开心, 能学到较多东西,但换个场景:如果员工觉得他在另外一个环境中,也能够开心的工作且学到较多的东西,而且拿的钱更多,或者多很多, 那我会问:他为什么不跳槽?    另一种情况,他已经觉得这个环境拿的钱比较低了,而且未来也可以预期不会涨很多,那他肯定就会考虑换工作了。 特别现在互联网公司比较多,外部给出的待遇也还不错。

    这个问题其实很难解决, 因为薪水这东西太实在, 我碰到过很多员工,在公司其实工作得也挺开心的,但还是选择了外部的机会,因为外部开出的薪酬条件更诱人; 也有很多员工本来就觉得公司给得低,主动选择的。

    解决之道: 这个一方面依赖于公司能否给出较高的package;另一方面,也需要在员工的个人发展上狠下功夫, 让员工了解认可自己的发展,以及寻求外部发展的规律。例如对于新人,需要让他们了解他们现阶段主要精力应该花在如何提升自己的内容; 对于老一些的员工,和他们一起做好个人的规划,让他们充分认可,同时和他们沟通寻求外部发展的规律(我的看法是这个平台是否还能支撑自己的后续发展,能否达到自己追求的目标,以及外部的机会,是否是真的好机会,是否真的适合自己)

    团队的氛围

    团队的氛围不是决定性的因素,如果员工因为其他原因有了离职的想法,那好的团队氛围也是留不住员工的,不过较好的团队氛围,的确能减少员工离职的想法,或是在一定程度上抵消外部更高薪金的诱惑。 有那么一种说法, 比较好的团队氛围, 能够抵消外部最高30%~50%薪酬提升的诱惑。

    总的来说,给员工发展空间,以及高薪金是公司能够提供的硬实力,他依赖于公司的发展阶段,盈利能力,以及公司对人才的投入,对每个人的投入;价值观,团队氛围等属于软实力,这是管理者更多需要发挥的地方。 很多时候,以为强调软实力会让员工更理性,而且一旦在发展,薪金上受了挫折或者不公,就可能产生比较负面的后果; 较强的软实力不能保证员工不离职, 但却能增强员工的凝聚力,增强员工的幸福感, 也能在一定程度上抵消外部的诱惑, 或者是因为这些软实力有些员工就不会有意识地和外部进行过多的接触,减少外部的诱惑。

    从一开始招聘就关注离职风险

    很多时候,从招聘的时候,就需要考虑这个人能长期留在公司的可能性, 说一个我碰到的例子: 我在公司负责流量推荐系统,之前来校招面试的一个小姑娘,技术面结果还可以,考虑到她有推荐系统的项目经验,就给了一个校招offer,不过后来HR联系我说这小姑娘比较浮躁,是HR见过的最浮躁的校招候选人,,她可能是想拿百度的offer去其他公司谈条件,建议不发offer。我给的建议是先发offer,看她是否签,结果不出HR所料她果然拒了offer。 但后来她没拿到其它公司更好的offer,又打电话联系我,希望给她offer。 最终我还是没有给她offer,因为觉得HR说得对,她不是那么踏实,而且也不是没给她机会。从这个事后,我面试候选人的时候,也会更加注意这个人是否浮躁,是否能长期待在公司。

    工作1.5~2年或者工作5年也是离职高峰, 一般工作1两年的人,觉得在公司做的事已经比较熟练,想寻找更多挑战,或是外部薪水的诱惑,会有较高的概率离职,工作5年的人,会对自己的个人发展有更清楚的认识,也可能会做出判断后选择离职。所以这两个阶段也需要特别关注。 这些都需要在平常的one-one中细致观察多沟通,提前了解,做好功课。

     

    百度关键词工具介绍参见:http://support.baidu.com/product/fc/4.html?castk=24b18bi7062c720d0d596

    也可关注我的微博:  weibo.com/dustinsea

    或是直接访问: http://semocean.com

    展开全文
  • 校园一卡通系统可行性方案

    千次阅读 2020-10-29 11:36:10
    第1章 一卡通应用情况及现状 3 1.1校园一卡通当前状况 3 第2章 市场需求分析 3 2.1 业务需求分析 3 2.2 应用需求分析 4 2.3 技术需求分析 5 2.4 功能需求分析 6 ...第4章 技术可行分析 12 4.1 设计原则

    第1章 一卡通应用情况及现状 3
    1.1校园一卡通当前状况 3
    第2章 市场需求分析 3
    2.1 业务需求分析 3
    2.2 应用需求分析 4
    2.3 技术需求分析 5
    2.4 功能需求分析 6
    2.5 市场前景和竞争能力分析 6
    2.5.1 校园一卡通的优势 6
    2.5.2 校园一卡通的机遇 7
    2.5.3 校园一卡通的挑战 8
    2.6 项目风险分析 9
    第3章 校园一卡通建设目标 10
    3.1 校园一卡通系统应达到如下建设目标 10
    3.2 分析利与弊 11
    第4章 技术可行性分析 12
    4.1 设计原则和依据 12
    第5章 经济可行性分析 16
    5.1 支出 16
    5.1.1 基本建设投资 17
    5.1.2 其他一次性支出 17
    5.1.3 非一次性支出 17
    5.2 售后保障 17
    第6章 运营可行性分析 18
    6.1系统分析 18
    6.1.1系统的安全性 18
    6.1.2网络运行的可靠性 18
    6.1.1 系统标准化 18
    6.1.2 人-机合理配合 18
    6.2 系统带来的影响 19
    6.2.1 提高高校的管理和服务水平 19
    6.2.2 提高高校信息化建设和应用的水平 19
    6.2.3 方便师生员工的工作、学习和生活 20
    6.2.4 降低商户交易成本 20
    6.3 社会因素方面的可能性 20
    6.3.1 社会法律政策可行性 20
    6.3.2 公共环境可行性 20
    6.3.3 用户使用可行性 21
    第7章 营销推广 21
    第8章 总结 23

    第1章 一卡通应用情况及现状
    随着校园的数字化、信息化建设的逐步深入,校园内的各种信息资源整合已经进入全面规划和实施阶段,校园一卡通以结合学校正在进行的统一身份认证、人事、学工等 MIS 和应用系统等建设。通过共同的身份认证机制,实现数据管理的集成与共享,使校园一卡通系统成为校园信息化建设有机的组成部分。通过这样的有机结合,可以避免重复投入,提高建设进度,为系统间的资源共享打下基础。
    1.1校园一卡通当前状况
    校园是众多学生集中学习和生活的场所,学生在校期间发生的就餐、购物、用水、用电、宽带上网、图书借阅、看病、楼宇出入等活动涉及了付费、身份认证和水电消耗管理等各个方面。一卡通系统通过一套系统、每人一张卡即可对上述活动实现统一管理,极大地节约了资源、提高了学校的管理效率、降低了管理费用,同时也为在校师生提供了很大便利。一卡通在校园领域应用最早、发展最快,功能也最齐全。
    目前,传统校园一卡通市场趋于成熟,但随着校园信息化建设的深入,以及“数字校园”、“智慧校园”概念的提出,在 M1 卡向CPU 卡升级、手机一卡通迅速兴起、建设一卡通系统的学校范围越来越广泛、一卡通系统功能日益增多、运营商的广泛进入、校园节能减排需求增加等众多有利因素的驱动下,未来校园一卡通将以智能卡为媒介,成为起面向校园师生的综合性服务平台。

    第2章 市场需求分析
    2.1 业务需求分析
    (1)、校园一卡通系统使用智能非接触式IC卡做为信息载体,在校园网的支持下,实现校内一卡通行,具有支付交易、身份识别、个人信息查询等功能。
    (2)、学校财务管理部门实现校内财务的统一管理、资金结算和相应理财业务。实现财务收支两条线。校园卡的使用取代了校内的各种票证。支付交易信息传送格式按金融交易报文格式,实现与银行系统自助圈存、转账对账、账务结算、营业分配等数据对接,极大方便广大持卡人。
    (3)、各种费用的收缴及各类款项的发放、校园一卡通系统直接和银行衔接,具有将持卡人的补助(或奖金)、工资等直接发放到银行账户的功能。也可以由银行提供代收持卡人各类各种费用。
    (4)、在学校内实现电子钱包的支付交易功能。校园卡可作为电子钱包使用,持卡人将银行的存款通过圈存等方式充入校园卡的电子钱包中后,可在学校各校区内现金交易点进行支付交易,逐渐免去现金流通。在功能上,校园卡还可以采取一人一户、一户多卡、一卡多个钱包的格式设计,以满足一户对多个家庭成员卡、一卡对多个项目应用支付扩展需要。
    (5)、为校内使用证件的各种应用提供身份认证的功能,实现校园管理功能。校园卡可记录个人的各类基本档案,校园卡系统可共享身份信息、黑(白)名单库等信息资源。因此,校园卡可验证持卡人的身份,实现图书借阅,门禁考勤、停车场等身份认证,从而代替以前的各种证件,使学校管理更加规范。
    (6)、为持卡人提供自助业务服务功能,包括电话查询、网上查询、触摸屏查询等方式,实现校园卡自助挂失、解挂、信息查询等。各类自助业务功能可按需随时扩展,为持卡人提供更方便更高效的服务。
    (7)、校园一卡通系统和学校的管理、科研、学籍、奖贷、教务、人事等各部门原有的MIS管理;信息系统部分数据对接,将建设学校统一人员、管理、科研等基本管理信息系统数据库,校园卡作为个人身份ID,通过一卡通实现校内信息充分共享。如学费的缴纳与教务、管理、学籍管理联系等。
    2.2 应用需求分析
    (1)、校园一卡通系统作为数字化校园基础组成部分,与学校内其它管理信息系统协调一致。
    (2)、 校园一卡通系统主要由一卡通系统平台和应用子系统两大部分组成。应用子系统分为四个系列:支付交易类子系列、身份认证类子系列、综合业务类子系列,自助服务类子系列。
    (3)、 校园一卡通各应用子系统与一卡通平台系统的链接,可以按照数据中心数据、持卡人卡片数据、终端产品数据是否完全共享分为三种链接形式:无缝链接、有缝链接、不链接。
    (4)、 在一卡通平台上,可以在任何位置挂接子系统,增加子系统不需要再对一卡通平台系统进行扩充和改动。不仅如此,在应用软件界面上用户可以进行自定义菜单,实现操作使用一体化。
    (5)、在一卡通平台上,可以实现身份信息、电子钱包信息的全局共享,同时实现对各个子系统的状态的监控,实现全局的财务信息的统一管理。
    2.3 技术需求分析
    (1)、由于校园一卡通涉及多个应用系统及全校各类人员,因此,对校园卡的设计规划有较高要求,校园卡需满足各类身份类别需求并且要求有足够冗余,卡片结构设计需具备公用信息区,自定义信息区、银行信息区及多个电子钱包以真正实现一卡通,而不是一卡多用。
    (2)、联机支付交易数据量大,实时性要求高。
    (3)、在网络故障时可以脱机支付交易,终端设备要求高。
    (4)、由于校园一卡通终端设备数量较多,传统的单机型结构已不能满足大型系统的业务要求,需要采用网络通信协议做辅助,通过标准化结构化布线技术以保证数据传输的稳定性和实时性。
    (5)、由于校园一卡通系统是学校数字化校园建设的基础工程,校园一卡通应用系统需为数字化校园搭建包括全校人员统一身份库的基础平台。并且搭建校园一卡通系统的基础平台,保证一卡通在扩充各类应用子系统和与第三方产品对接时无需再对一卡通平台进行修改。
    (6)、由于校园一卡通系统中处理的大量是金融支付交易,所以对于系统的安全性、实时性、可靠性要求达到金融级别的标准。
    2.4 功能需求分析
    校园一卡通主要具有消费、身份认证、信息查询等功能,其应用覆盖综合消费系统,包括收、缴费及各类款项支取,校内各类小额消费;以及信息查询系统,包括身份认证,门禁、图书借阅、管理信息查询及统计分析等。整个系统应与银行系统和校内信息管理系统有良好的衔接。
    2.5 市场前景和竞争能力分析
    据统计表明,目前全国校园卡发卡量已经超过1亿张。成为继银行卡、电信卡(包括各种IC卡、IP卡、手机)之后的第三大卡。校园一卡通不仅可以用作食堂消费结账的工具,而且可以代替学生证、借书证、钱包等,“一卡通”已经渗透到学生学习和生活的各个方面,刷卡也成为高校的一个主旋律。
    在对北京、上海、广州、武汉等城市的高校的调查中,发现90%以上的师生欢迎一卡通,且对其发展前景持乐观态度。目前,东部地区的绝大多数普通高等学校已经建成相对完善的校园一卡通、系统,在今后的一段时期,东部地区的主要需求集中在对原系统的升级改造与更新上。与此同时,中西部的普通高等学校的一卡通系统普及率相对较低,存在较大提升空间。随着教育经费投入的加大以及国家政策向中西部发展的倾斜,中西部的普通高等学校和其他类型学校的校园一卡通市场需求将得以释放。
    我公司产品结合了智能系统支撑平台,具有较强的学生安全管理功能,能够支撑海量用户同时使用系统,系统在业务统一性、数据安全性、功能的全面性方面,具有较强的竞争力。
    目前,正逢校园一卡通更新换代的时机,很多学校都有建设一卡通系统的需求,同时,学校之前的一卡通系统需要升级。我公司以可根据用户需求,本地化的需求,及时定制产品和提供周到的稍后服务,这从市场方面保证了产品的竞争力,随着产品技术的不断完善和知名度的提高,市场份额将持续扩大。
    2.5.1 校园一卡通的优势
    (1)、用户、用户组数据集中
    传统的校园一卡通系统有自己的数据库保存用户、用户组的信息,由于设计、安全性要求高等多方面的原因,导致了一卡通用户信息很难被别的系统共享,而且一卡通系统的就构信息、用户信息、用户信息也不能满足其它应用系统的需求,因此一卡通不可能成为学校的统一身份认证中心,只能是集成到统一身份认证系统上的一个子系统。数字化校园建设要求所有与身份认证有关的用户基本必须要到统一身份认证系统集中存储,集中管理,所有的应用系统必须的身份认证和身份基本信息获取必须要到统一身份认证中心进行。用户的分组信息和大的权限也可以在统一身份认证中心中集中管理。小的权限各应用系统单独维护。
    一卡通系统的用户首先需要到统一身份认证中心中注册,用户的分组也需要在统一身份认证系统中有定义。统一身份认证系统用户信息变更后及时通知并复制到一卡通系统,一卡通的卡状态变更(挂失、解挂)后及时通知身份认证中心。
    (2 )WEB信息集中发布
    在数字化校园中将给用户提供门户网站作为用户的入口,用户通过门户网站一次登陆即可进入所有应用系统。通过这个信息门户,师生可以进入教务系统、人事系统、邮件系统等等。一卡通作为数字化校园的一个应用,也同样需要在此门户上进行信息发布,内容可以是:消费记录、用户充值记录、门禁进出记录等等。
    (3) 调整定位和分工
    一卡通系统专注于与卡、终端设备相关的应用系统的建设,例如消费系统、门禁系统。原有需要一卡通系统集成其它系统的时候,仅需要通过统一身份认证系统作为桥梁,按照统一身份认证系统的标准进行对接,而无需一卡通厂商和业务系统厂商单独协商接口,可以节省了大量的沟通和协调的工作量。

    2.5.2 校园一卡通的机遇
    教育部统计数据显示,当前全国高等院校2956所,最新公布的广东省所有大学名单,共计154所,其中本科学校67所,专科学校87所。
    以每家高校在一卡通项目上平均投入300万元左右计算,按照目前全国高等院校数量,理论上市场份额已超过70亿元。目前尚有50%以上的校园未实施一卡通,即尚有30多亿元左右市场空间,另外高校一卡通每年维护费用的空间约有7-8亿元。据了解,高校一卡通系统通常5年左右就需要重新建设或者升级,因此,高校一卡通市场具有持续的增长空间。
    显而易见,校园一卡通是典型的ToB业务,虽然在整个"教育产业"中份额并不大,但具有营销目标明确、中标金额巨大、更换频率固定等市场属性,对于所有的教育集成厂商来说无疑都是巨大的诱惑。
    各个高校的智慧校园建设逐步深入,一个安全、稳定、环保、节能的校园正向我们走来。“校园一卡通”是智慧校园的基础工程,为智慧校园提供平台,是管理科学化、信息化、便捷化的必要前提和基本途径。
    现阶段,支付宝和微信凭借庞大的用户群,支付方式灵活,存取方便,已经成为一只普遍的支付形式。但是移动支付在用户数量扩大以后,其安全问题就逐渐凸显出来,因为这种支付方式安全维护频繁,用户数据被盗的情况时有发生,而且,法律和法规在这一方面存在一定的空白,用户利益难免受损,考虑到校园一卡通系统相对独立的网络环境和系统,支付宝与校园一卡通各种成功实现网上支付充值业务。借助微信平台,可实现银行卡到校园卡的转账,再加上已有的圈钱机的转账功能,校园卡的充值方式不断增加,充值更加便捷,避免排队等候的现象,使得校园卡进行消费也越来越方便。

    2.5.3 校园一卡通的挑战
    校园一卡一卡系统经过多年的发展,逐渐实现“一卡在手,走遍校园”,极大地方便了师生的学习、生活和工作,但是随着我国第三方支付方式,WiFi技术和NFC技术的发展,校园一卡通支付方式和考勤管理方面面临极大的挑战,
    (1)校园支付方式的变化
    随着移动互联网的发展和智能终端的普及,特别是智能手机的普及,移动支付以其快速、方便等特点被广大师生所喜好。手机支付基本可以完成在校内的就餐、消费等日常事务的办理,就算是校外人员也可以在学校内进行消费。因此,无卡支付将会越来越受到广大师生和商家的青睐,这种消费支付方式对于校园一卡通提供的消费和金融管理功能是一个极大的挑战。
    (2)信息管理方式的变化
    现有的高校学生指纹考勤系统依附校园一卡通系统,新生入学时采集指纹信息保存到校园卡,晚上宿舍考勤时,学生在指纹认证终端验证指纹,提前学生指纹并与校园卡内保存的指纹信息对比,如果一致,则指纹对比成功,完成考勤,考勤结果上传到考勤数据库,并自动记录考勤时间。这是一种将指纹验证和校园卡验证结合,进行刷卡加指纹的双重验证考勤方式。随着,移动电话的成本降低,品牌竞争的加剧,智能手机的价格越来越亲民,APP的面世及功能逐渐完善、性能不断提高,人们在工作、学习和生活方面已经离不开智能手机。近年来,WiFi技术、NFC技术的飞速发展,移动电话和室内WiFi定位系统相结合,位置误差范围可以控制在3米以内,基本内满足室内移动定位的需求,使得无卡考勤成为可能。另外,随着GPS定位精准度的逐步提高,通过智能手机的内置GPS芯片的定位功能,成功实现移动电话客户端,不受时间和空间的限制,可以轻松完成高校学生的定位、教职工会议签到考勤工作。
    2.6 项目风险分析
    在对产品研发的风险分析中,我们要意识到项目潜在的风险包括:需求变动—用户新业务或先阶段需求变化的风险;员工技能差–人员流动;技术风险:由于所采用技术的不成熟,延误开发进程甚至造成正规产品架构失误的风险;市场风险—市场比必然存在的许多不可预知因素的风险等。
    对项目风险的管理,首先需要对项目本身有着深刻的认识和理解,通过理解项目去识别潜在的各种风险。在项目实施的过程中,针对个部分风险采取专门措施进行管理和控制,从而最大程度低降低风险、控制风险。对于需求的变动及技术的风行,前期需要做深入全面的调研,周密细致而又前瞻性的需求和技术分析认证,采用成熟技术和工具平台。对于人员技能及流动,一方面加强文档管理,项目进展均要形成规范化文档,另一方面注重人员素质提高,形成合理的人员梯队,可以承受任何由于人的因素带来的风险。而对于市场,虽然它存在很大不可以预知的因素,但在项目过程中密切跟踪市场发展,并快速对市场变化做出反应同样可以在最大程度上降低风险。

    第3章 校园一卡通建设目标
    校园一卡通系统的总体设计,是在坚持先进性、实用性、稳定性、安全性、经济性、扩展性的基础上,直接借助校园网传输数据,实现学校各校区、各类商务收费、各种身份识别的一卡通行。系统的设计突出采用了目前国内、外最先进的技术和产品,具有明显的时代特色和预见性,留有十分灵活方便的扩展接口,为数字化校园建设的持续发展打下坚实的基础。
    3.1 校园一卡通系统应达到如下建设目标
    (1)、以建立校园一卡通系统为契机,建立学校各类学生、教职员工、各种组织机构基本的、统一的信息化标准,并且作为公用数据在整个校园网实时共享,强化集中式的信息规范管理,促进数字化校园的建设。
    (2)、通过校园一卡通系统建成一个统一管理的校园基础数据总平台。校园卡应用的商务管理、银行转账、身份识别管理等各种应用子系统的建立都以该平台为基础,将来学校应用规模的扩大和卡片应用功能的增加只需增加相应子系统,不需再对一卡通平台进行扩充。
    (3)、在校园一卡通管理平台的基础上,通过系统预留的扩展接口和智能控制可以实现与学校现在已运行的各类MIS系统、OA系统的信息互通,形成全校范围的数字化管理空间和共享环境,动态实时地反映职能部门运作情况和统计分析数据,增强领导科学决策的依据,提高学校管理水平。
    (4)、在校园一卡通管理平台的基础上,可以随时向持卡人提供准确的校园卡使用情况,包括本人帐户数据、电子钱包数据以及在其他场合使用的流水帐,方便持卡人个人理财。
    (5)、校园一卡通内的“一卡通”电子钱包可以通用于各校区内的任何一个通用消费网点。校园卡内“专用”电子钱包按需求只能用于各校区内的专用消费网点。
    (6)、在校园一卡通系统中,校内的所有商户单位不论其性质与规模都可以授权代理收款、结算;商户资金可以及时到账,也可以按照银行规定进行结算。
    (7)、在各个校区内,实现银行借记卡与校内电子钱包部分之间自动式和自助式两种形式的实时圈存转账。
    (8)、建设财务结算中心,该结算中心与学校财务管理部分一体化设计,为财务管理提供更加科学、有效、安全、便捷的理财服务,实现各校区的财务统管。
    (9)、实现校内各类身份识别校内所有的证件都由校园卡代替;所有用证、用卡的信息管理系统,可扩展身份识别部分连通校园一卡通系统,实现身份识别的数据共享。一卡通系统与学校现有的图书管理系统数据的实时同步和自动交换。取代各校区原有的各类借书证、卡,实现与公用机房的机房管理系统,电子阅览室等系统的对接连通,取代各校区原有上机证等。与教务管理系统的对接,实现学生按学期的学籍注册管理;校医院挂号收费管理;实现图书馆,教学楼、宿舍楼等重场所出入门禁等对学校教学资源、生活设施的使用控制。
    (10)、通过借助校园一卡通各类终端设备,持卡人可实现全方位全天候的自助业务,包括银行借记卡的各类自助业务;校园卡的自助业务,包括电话语音服务系统,网上查询服务系统,触摸屏查询,领导查询系统,自助终端为持卡人提供365724小时不间断服务。
    建设目标定位为:自助将银行存款圈存到校园卡,以完成学校内各类消费,并实现个人身份认证,进而与学校管理信息系统链接。实现持卡人各类自助业务,以及领导宏观管理的综合查询等,以校园一卡通系统建设为纽带促进数字化校园的建设。

    3.2 分析利与弊
    所谓“一卡在手 方便行走”,在使用一卡通以前,校内使用着大量的不同类别的卡、证、票,除了每人必备的身份证、学生证、图书证、医疗证外,还有各种卡,如光电卡、学生食堂饭卡、条码卡、磁卡、IC卡等,光上机卡在校内就有五六种,同时还存在着一些有价票据,如澡票、游泳票等等。各种证、卡、票的同时并存,使得管理分散,使用不便。即使是采用各种自动识别技术的卡,也因机器种类繁多,各种类别的卡之间不可通用,造成办理与使用手续复杂,学校内也没有统一管理,这与高校的现代化管理水平极不相称而且方便学校与学生之间消费中经常产生的问题。
    实施校园“一卡通”,不仅可以减少卡、证、票据数目繁多,手续复杂不便的问题,更可以在“一卡通”中加入个人身份认证信息,使“一卡通”的卡不仅可以作为现金卡供支付用,也可以作为证件进行身份识别,这样就可以将各部门进行统一管理,节省时间,提高效率,使校园具有现代化的管理水平。另外一卡通可以大量减少现金的流通和管理成本,每张卡的消费数据,系统都会存储在系统数据库中,并上传至服务器,系统还会在设定的时间内,自动将发生的消费数据进行资金结算,还会根据相应设置进行数据处理,消费数据,系统都会存储在系统数据库中,并上传至服务器,系统还会在设定的时间内,自动将发生的消费数据进行资金结算,还会根据相应设置进行数据处理,对不符合消费条款的卡,系统会将该卡列入待处理或黑名单队列,使该卡暂时或永久失去消费功能或权限。

    第4章 技术可行性分析
    4.1 设计原则和依据
    一卡通网络拓扑示意图

    相对于目前主流的一卡通网络方案,我们的一卡通系统中将一卡通中心数据库进行了重新规划,并将数据统一保存到学校的IDC中,其中用户数据存储到目录服务器中。增加了两组服务器,一组是作为数字化校园建设的统一身份认证中心,另一组是个人信息门户。
    我们新型一卡通系统的网络层次分明,具有典型的三层结构,包括了客户端、应用服务器、数据中心,有利于系统的扩展和安全管理。

    (1)、先进性
    校园一卡通系统的技术层面上,含网络构架、硬件设备、卡片设计、协议选择、软件设计、安全控制等各个方面 应充分体现和采用先进和成熟的技术。在管理层面上,含管理组织结构设计、管理流程、业务流程、使用流程等也应充分体现和采用先进和成熟的理念和方法。系统组成和拆分的灵活、运作的高效、用 户个性化服务,体现出该系统的先进性。
    (2)、安全性
    校园一卡通系统从卡片、终端、网络、软件、硬件、数据库等各个组成部分,到支付交易、数据存储、数据传输、数据处理、数据使用等各个环节,均遵从中国人民银行、有关专业银行以及国家计算机信息系统安全保护等级标准(GB 17859-1999),确保系统的安全性。
    (3)、实用性
    数字化校园一卡通系统充分体现了以人为本的人文化,无论是系统管理者、使用者,还是卡户(持卡人)、商户,易于使用、管理和维护。所以,在系统设计时,充分考虑界面友好、操作简便、容错能力强、性能稳定、功能强大、维护方便、文档齐全的实用标准,确保系统的实用性。
    (4)、扩展性
    校园一卡通系统充分考虑了用户的现状和今后不断发展以及多样化的需求,所有软件均采用标准模块化结构设计,集成、拆分、维护非常方便;所有终端产品均采用标准板块化结构设计,当功能改变需要进行个性化服务时,只需在计算机上修改原代码,通过网络下传给相应的终端机即可,不需要开盖更换应用程序芯片;所有终端产品可以提供各类应用接口,非常方便系统扩充和升级。卡片结构设计采用了最先进的目录式技术、自定义技术、扇区功能转移技术,不仅可以满足用户单位现行需要,而且可以满足发展的需要。所有网络产品均采用国际标准化产品,保证通用和扩展。显而易见,本系统的扩展性设计可以确保用户投资的长期效益,避免资源重复浪费。
    (5)、开放性
    校园一卡通管理系统网络具有良好的开放性。这种开放性靠标准化实现,使得符合这些标准的计算机系统很容易进行网络互联。为此,制定了全网统一的网络体系结构,宾遵循统一的通信协议标准。网络体系结构和通信协议选择了广泛使用的国际标准宾符合中国教育和科研计算机信息网络的总体设计要求,并采用了开放技术、开放结构、开放系统和开放用户接口,以保证系统可以平稳地适应学校发展的变化而变化。
    (6)经济型
    校园一卡通管理系统充分考虑到学校的经济承受能力,着眼于近期目标和长期的发展,选用先进的设备进行最佳的性能组合,利用有限的投资构造一个性能最佳的系统。
    (7)可靠性
    校园一卡通管理系统保证系统的稳定、可靠和安全运行,具有很高MTBF(平均无故障工作时间)和极低的MTBR(平均无故障率),具有容错的功能,支持故障检测和恢复,可管理性强,能满足学校所在地的环境、气候调整,抗干扰能力强。
    (8)完善的应急机制
    校园一卡通用管理系统可脱机单独工作,在出现网络故障时或停电时不影响各处使用。拥有安全可靠的数据备份系统,完善的系统安全机制。
    公司结合自己长期从事高校校园一卡通系统设计,实施的丰富经验,根据校方校园一卡通项目的需求,遵循“先进、实用、安全稳定、升级简便、扩充性好、开放性好”六项基本原则,设计了代表全国高校一流水平的、集商务、校务管理和金融服务为一体真正意义上的校园一卡通系统全面解决方案。

    (9)人脸识别建设
    一脸通行,智慧校园
    红外人脸生物活体识别,人脸识别速度遥遥领先与同行,行业领先特征比对人脸算法,识别率高达99.99%。实现刷脸进门、人脸考勤、刷脸支付、人脸借阅。支持存储功能,可动态/静态人脸检测, 质量模型保证输出清晰照片
    人脸识别功能:广义的人脸识别实际包括构建人脸识别系统的一系列相关技术,包括人脸图像采集、人脸定位、人脸识别预处理、身份确认以及身份查找等;而狭义的人脸识别特指通过人脸进行身份确认或者身份查找的技术或系统。

    智能防范-人脸抓拍

    第5章 经济可行性分析
    5.1 支出
    本校园一卡通管理系统的支出包括软件和硬件部分,从软件方面分析的支出主要包括开发费用投入以及后期的运行维护投入,再从硬件方面分析,这方面的投入主要包括射频卡终端、存储设备、服务器设备、网络设备等等。
    5.1.1 基本建设投资
    数据通信设备(计算机,扫描机、服务器、pos机、读写器等,依托现有的校园网)
    环境保护设备(终端控制器)
    安全与保密设备(监控系统)
    数据库管理软件(一卡通软件)
    卡片成本

    5.1.2 其他一次性支出
    数据库的建立(一卡通数据中心)
    检查费用和技术管理性费用
    5.1.3 非一次性支出
    设备的租金和维护费用
    软件的租金和维护费用
    数据通信方面的租金和维护费用

    5.2 售后保障
    1、由当地的渠道商负责,保修期内,非人为损坏,免费维修。超保修期,酌量收取材料费和维修费。
    2、校园一卡通系级统软件产品免费升级,终身维护。
    3、系统启动时,由当地渠道商派技术支持人员到现场指导工作。
    4、技术支持人员每年定期协助用户完成设备的检测工作,以保证系统的正常运行。

    第6章 运营可行性分析
    6.1系统分析
    6.1.1系统的安全性
    系统具有安全性,包括网络系统、主机系统、数据存取系统、数据传输系统的安全性,数据备份和灾难恢复的可靠性,为保证系统软件、应用软件及数据安全,系统严格选用操作系统平台,开发平台,设计防病毒功能,保护系统数据,并建立了备份系统,定期自动进行全量及增量备份。在系统中采用射频卡作为身份识别,并在关键信息的处理,传输中采用加密处理,防止信息被为授权访问,确保系统的不可攻击性。
    6.1.2网络运行的可靠性
    可靠性包括网络运行的可靠性、各硬件设备的可靠性、所运行软件的可靠性,并在系统中加入电保护,数据备份等手段来保证吸引的正常、长期的运行。
    本系统才有实时+非实时相结合的网络架构,系统管理中心有中心数据库,各子系统有具有本地库,各本地库与中心通过校园网实现数据互传,使各应用子系统依赖校园网,又可脱离校园网单独运行,这样增加了运行的安全可靠性。
    6.1.1 系统标准化
    所谓标准化,主要是指代码的标准化和程序设计的规范化。对代码来讲,原则上存在国家标准的就采用国家标准,无国标的采用行业标准,如即无国际有误行业标准的,就参照其他国家的标准或其他行业的相近标准指定本系统的标准,软件按照国际标准规范化设计,以便于交流和与其他系统的连接。
    6.1.2 人-机合理配合
    一卡通系统是人机有机结合的一个系统,因此必须重视人和计算机的关系,提供良好、亲切的用户界面。而且易于人操作。低层次、繁杂的数据除了任务交由计算机处理,而人将从事较高层次的工作,避免系统过于复杂、提高计算机的运行效率和计算效果。记住,简单是一种美,美是有生命力的,优秀的系统并不一定是需要复杂界面、繁多的功能来堆砌

    6.2 系统带来的影响
    6.2.1 提高高校的管理和服务水平
    校园一卡通的应用可以提高学校财务管理、学生管理和后勤服务的水平节省人力成本,减少水、电等资源的浪费。
    首先,校园一卡通系统与后勤系统、图书管理系统等的衔接可以改进后勤服务的质量,促进学校教育资源的管理,杜绝恶意损坏与浪费,节约不必要的开支,改善学校的财务状况。其次,校园一卡通的应用能够够消除校内绝大多数现金收费,有效地治理校内的乱收费和“小金库”,预防经济犯罪并降低现金保管的风险和成嫩。第三,校园一卡通的应用可以帮助财务部门及时、准确地掌握校内商户经营状况并实现商户应缴费用的按时、足额上缴。最后,将校园卡用于财务报销过程中的身份认证还能杜绝“虚假冒领”的现象,降低财务风险。校园一卡通系统收集的学生校服信息可以帮助学生工作部门准确掌握学生在校内的消费情况,提供贫困生资质的准确度。在后勤服务方面,校园一卡通的应用可以实现水、电等资源后勤服务的信息化管理,减少资源浪费。此外,以“校园一卡通”取代餐卡等各类单一功能卡可以避免重复建设,实现后勤服务的统一管理,降低运行成本。
    6.2.2 提高高校信息化建设和应用的水平
    作为数字校园的重要基础设施,校园一卡通系统在身份认证、消费缴费信息采集和数据共享等方面的应用能够提升高校信息化建设和应用的水平,校园一卡通系统收集和补充全校师生员工信息并通过数据交换共享平台将它们共享给一卡通应用欧诺个条个数字校园中的应用系统,实现人员信息的“一处输入、全校使用”,减少各种因身份认证困难或成本高而产生管理问题。同事。校园一卡通的应用还能够方便地实现师生员工在校内活动信息的自我采集。
    6.2.3 方便师生员工的工作、学习和生活
    校园一卡通的应用为师生员工的工作、学习和生活代理极大的方便。首先,校园一卡通以“一卡”取代“多卡”,真正实现了“一卡在手,走遍校园”。第二,校园一卡通普遍采用的非接触式IC卡使持卡人不必取出卡片即可使用,加快了身份验证和消费的速度。最后,一卡通服务平台还为持卡人提供全天候、多渠道、使用方面的自助服务平台。
    6.2.4 降低商户交易成本
    校园一卡通的应用实现了电子化结算,大量减少了现金收钱的和找零的发生,不仅加快了交易速度,而且降低了商户保管现金的风险和人力成本。同时,一卡通服务平台中对商户提供的应用信息查询和统计功能能够为商户的管理人员提供方便的信息服务,为商户规范化内部管理提供信息支持。
    6.3 社会因素方面的可能性
    6.3.1 社会法律政策可行性
    该系统的开发不会侵犯他人、集体和国家的利益,也不会违反国家政策和法律,因此在法律方面的可行的。合同制定确定违约责任。
    6.3.2 公共环境可行性
    建立先进的信息管理系统是实现高等教育现代化的必经之路。学院的一卡通管理系统存在不足,局限性很大,开发本系统能为学院带来高效的管理和运用,则是推荐高效信息化管理的重要举措之一。校园智能卡可供学生用于校园网内部处理杂物,购买食品、书本,借阅图书,查资料,洗衣等。学生只需在一卡通充值中心存入金额,即可启用其他电子钱包功能,可反复充值。
    6.3.3 用户使用可行性
    开发该系统充分考虑了用户操作方面、处理流程、人员素质等多方面的因素。因此能够满足用户的需求,所以用户使用方面也是可行的,使用本软件人员要求具有大学计算机基础。操作人员需要重新上架培训,可以避免大量的开发费用。

    第7章 营销推广
    (1)、搜索引擎推广
    通过确定网站关键词、登录各个大门户网站搜索引擎、注册网络实名、企业实名、行业实名等方法大范围的传播公司信息,参与百度等著名搜索引擎的搜索排名,利用其强大的搜索优势,最快速的传播品牌信息。
    (2)、软文推广 
    软文推广具有周期长、价格低的优点,可以用较少的投入,吸引潜在消费者的眼球,提高品牌认知度和社会形象。在软文的潜移默化下,达到品牌的策略性战术目的,引导消费群的关注及购买。
    (3)、与相关厂商、渠道商及网站合作
    寻找拥有教育方面资源的厂商,和学校有相关业务合作的渠道商进行合作,拥有学校资源的网站进行投放广告、展示。
    (4)、头条推广
    今日头条是近两年发展较快的移动互联网咨讯软件,它的官方定义是:基于数据挖掘技术的个性化推荐引擎产品。它与其他咨询类网站不同之处在于推荐方法,头条会根据每次用户的阅读习惯,推荐用户感兴趣的内容,由头条指数决定推荐的权重。个人或者企业都可以开设头条账号,目前它的激活用户数已经超过6亿,月活跃用户数超过1.4亿,日活跃用户更是数超过6600万。这么庞大的用户群不为自己企业所用,岂不可惜?

    缺点:文章审核要求严格,只推荐用户感兴趣的文章
    (5)、品牌基础推广
    百科类推广:在百度百科,360百科建立品牌词条。
    问答类推广:在百度知道,搜搜问答,新浪爱问,知乎等网站建立问答。
    (6)、关注教育资源方面的展会
    参加教育资源方面的展会,可以与相关、互补的展品的公司进行合作、从而展示公司的校园一卡通系统信息,针对性比较强。

    第8章 总结
    建立先进的信息管理系统是实现高等教育现代化的必经质量,而智能卡技术的推广运用,是推进高校信息化管理的重要举措之一。校园一卡通方面能有效缓解校务管理和后勤服务的繁重业务,提高学校的管理水平、提高后勤的服务质量。
    往未来的深处看,综合了智能卡、自动控制、生物识别、计算机软件及网络、数据库、信息安全领域的诸多新技术成果的智能一卡通系统,在信息技术革命时代,表现出蓬勃的活力,将带来更安全、更便捷、更舒适的生活。这也就意味着新一代校园卡系统至少应该具备人性化、多样化和智能化的特征,充分体现融合、服务和创新。面对时刻变化的校园客户需求和日趋激烈的市场竞争,导入新产品是企业持续成长并保持赢利能力的重要保证。
    随着人工智能,云计算、物联网等信息技术的发展,未来校园卡系统又会发生哪些改变?这是抛给高校用户和一卡通厂商的新课题,也为校园卡系统的应用拓展带来更大的想象和发展空间。但毋庸置疑的是,大数据时代发展至今,校园一卡通能够为企业带来的早已不是高校每年的建设费用和维修费用,更加重要的是每一张卡背后所蕴含的持卡人的一系列行为习惯集成的数据。不难想象,未来的竞争会更加激烈。

    展开全文
  • 金蝶K/3产品性能稳定性优化指导手册  2011-08-15 11:43:05| 分类: ERP应用|字号 订阅  金蝶K/3产品性能稳定性优化指导手册(常见问题)(V3.0) ?金蝶软件(中国)有限公司研发中心K/3产品...

    金蝶K/3产品性能稳定性优化指导手册  

    2011-08-15 11:43:05|  分类: ERP应用|字号 订阅

     金蝶K/3产品性能稳定性优化指导手册(常见问题)(V3.0)

    ?金蝶软件(中国)有限公司研发中心K/3产品事业部.设计部解释

     

     

    目的

     

    本手册在于指导技术支持人员、分支机构实施服务人员和客户处理K/3系统应用过程中产生的性能问题、中间层服务器问题等;同时也指导我们的实施服务人员和客户在实施中如何避免将来可能发生的性能问题和中间层问题。让研发人员、技术支持人员和分支机构实施人员一起共同提高工作能力,快速反应快速解决客户的问题。

     

    适合对象

     

        本手册的主要阅读对象是K/3系统研发人员、技术支持人员、实施人员、客户服务人员和公司授权的有一定技术能力的客户系统管理员。

     

    反馈

     

    本手册是对研发在处理客户性能和稳定性问题的收集和总结,所以涉及到的面有可能还不够。完善本手册,提供一个更加完整的客户问题解决指导方案,离不开大家的支持,所以大家在碰到相关的问题时,请反馈K/3设计部,我们将及时对手册更新。

     

    导读

     

        本手册包括数据库、中间层、客户端和辅助分析工具介绍四大篇,分别介绍K/3客户性能和稳定性问题的处理方法、案例以及辅助工具,请您根据您的需要选择相应的章节阅读。

     

    注意

     

    由于此手册可能牵涉一些K/3在技术方面的细节,为了防止有些人用意不良,断章取义来攻击K/3和公司,请注意保密。

     

     

     

     

     

    目录

    1. 环境准备    4

    2.    问题处理流程和分析方法    7

    2.1 问题处理流程    7

    2.2 问题分类    8

    2.2.1 K/3软件问题    8

    2.2.2 K/3软件问题     9

    2.3 问题分析方法    9

    2.3.1 排除法    9

    2.3.2 像医生看病    10

    2.3.3 从现象入手    10

    3.    网络与Citrix应用问题    11

    3.1 网络引起的性能问题介绍    11

    3.1.1 网络配置不符合K/3应用需求,带宽不足    11

    3.1.2 网络不稳定或存在丢包现象    11

    3.1.3 网络安全性问题    12

    3.2 Citrix应用引起的性能问题介绍    13

    3.1.1 Citrix应用硬件配置指南    13

    4.    数据库性能问题    14

    4.1 数据库常见性能问题介绍    14

    4.1.1 数据库服务器硬件配置    14

    4.1.2 数据库维护策略不当    17

    4.1.3 数据库表结构不合理    21

    4.1.4 数据库性能优化方法总结    22

    4.2 数据库性能常见问题解答    22

    Q 影响系统运行性能的主要因素有哪些?    22

    Q 如何评价并发客户数量?    22

    Q 数据库服务器要注意什么事项?    22

    5.    中间层性能和稳定性问题    23

    5.1中间层COM+性能和稳定性问题优化指导    23

    5.1.1 中间层服务器硬件配置    23

    5.1.2 中间层与客户端不同域性能优化    24

    5.1.3 COM+常用处理方法    24

    5.1.4 Win2003下中间层EBO组件包安全设置    30

    5.1.5 杀毒软件对中间层的影响    32

    5.1.6 Windows2003IIS6.0进程管理    32

    5.2 COM+问题常用分析方法    32

    5.2.1 排除法    32

    5.2.2 信息收集综合分析法    33

    5.3中间层COM+问题解答    36

    5.3.1 如何解决COM+/MTS 4097 错误事件?    36

    5.3.2 不支持事务的组件是否能放入COM+应用程序中?    36

    5.3.3 如何在安装完COM+ Application Proxy之后修改远端服务器名?    36

    5.3.4 VBCOM+MTS中创建对象有何异同点?    36

    5.3.5 需要开启哪些端口以使MSMQ能够透过防火墙存取?    36

    5.3.6 COM+ 应用程序导出为Application Proxy后, 安装到Windows NT  Windows 98上时, 为什么CreateObject()会产生"class not registered"错误?    36

    5.3.7 如果COM+应用程序中的组件依赖于其他的组件或动态链接库,将COM+应用程序导出为Application Proxy并试图安装在Windows 2000上时, 会出现下列错误:Error registering COM+ Application. Contact your support personnel for more information    36

    5.3.8 做大的查询时COM+组件调用时间过长,此时若客户端用户人为结束进程,COM+还是一直在转,需要几分钟后COM+才能释放    37

    5.3.9 如何优化进程间通讯(包与包间的调用),提高性能    37

    5.3.10 防火墙导致COM+不能访问的问题    37

    5.3.11 COM+[安全属性]设置中如果设置身份验证级别为无会有什么影响,对性能提升有无帮助?    37

    5.3.12 如何更好地部署COM+,需要遵循什么原则    37

    5.3.13 VB组件能否支持对象池    37

    5.3.14 3G补偿的作用    37

    5.3.15 在中间层MODULE能不能执行SQL    38

    5.3.16 .Net调用自动COM+时,并发性能较差    38

    5.4中间层非COM+性能优化    38

    5.4.1 停止K/3系统相关服务    38

    5.4.2 域服务器、中间层服务器、数据库服务器分开部署    39

    6.    客户端性能问题    40

    6.1 客户端性能问题介绍    40

    6.1.1 某些客户端的速度比以往使用K/3慢一点    40

    6.1.2 某些局部功能速度太慢    40

    6.1.3 客户端出现Automation 错误    40

    6.1.4 如何查看具体哪个组件存在性能问题    41

    6.1.5 关于趋势防火墙与K/3的冲突    41

    6.1.6 使用了严重影响K/3系统性能的系统选项    42

    6.1.7 其他    46

    6.2.5 系统突然出现全面的死机现象    46

    6.2.6 客户端出现"新事务不能登记到指定的事务处理器中"    47

    附录1SQL Server 的大内存管理    50

     

     

     

    1. 环境准备

        客户使用K3出现问题时,导致的原因可能是多种多样的,为了更好的确定导致问题的原因,我们需要核对一下系统的环境。

    • 操作系统
      • WINDOWS2003是否安装SP1以上的补丁,WINDOWS 2000是否安装SP4补丁
      • 32位系统,物理内存大小,对于操作系统可以支持最大内存见    (下面设置需要重新启动才能生效)
        • 4GB:在BOOT.INI文件中增加/3GB开关
        • >4GB:在BOOT.INI文件中增加/PAE开关

        例如:multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003 Datacenter Edition" /PAE

      • 安装病毒实时防护或者启用微软防火墙
        • 如果数据库和中间层服务器启用防护,可以暂时停一段时间看是否性能有所改善,以确定是否防护产生的影响
        • 客户端需要将K3的应用放在例外中
      • HOSTS文件(%SystemRoot%\system32\drivers\etc)
        • 中间层服务器将数据库服务器的IP地址和名称加到HOSTS文件中
        • 数据库服务器将中间层服务器的IP地址和名称加到HOSTS文件中
      • 如果数据库内存大于2GB,但物理内存一直在2GB左右,检查组策略中【内存中锁定页面】是否设置(gpedit.msc)
        • 【计算机配置】/【windows设置】/【安全设置】/【本地策略】/【用户权限分配】/【内存中锁定页面】 添加当前机器下的SYSTEM用户和登录该机器的Administrators组中的用户
        • 如果是SQL SERVER2005,不进行上面的设置将无法启用AWE设置
      • 中间层和数据库服务器MSDTC设置(Windows2003+SP)是否如下

          

     

    • 数据库
      • 版本
        • SQL SERVER2000标准版只支持最大2GB内存
        • 需要支持超过2GB内存,需要选择SQL SERVER2000企业版本和SQL SERVER2005标准/企业版本
        • 如果操作系统为64位机器,建议安装64位版本SQL SERVER
        • SLQ SERVER 2005标准版支持4CPU【物理CPU】,超过4CPU【物理CPU】必须使用企业版本
      • 补丁
        • SQL SERVER2000安装SP4
        • SQL SERVER2005安装SP2
      • 如果在企业管理器中看到阻塞导致的情况是同一个SPID把自己阻塞了,检查处理器并行

      查询分析器中执行sp_configure 'max degree of parallelism',如果返回为0,运行下面语句:

          sp_configure 'show advanced options', 1

      RECONFIGURE

      GO

      sp_configure 'max degree of parallelism',1

      RECONFIGURE

      GO

      sp_configure 'show advanced options', 0

      RECONFIGURE

      • 32位系统下AWE设置(如物理内存为8GB设置数据库的最大内存为6GB)

      在查询分析器中执行sp_configure 'awe enabled',如果返回为0,表示未启用AWE。

      sp_configure 'show advanced options', 1 

      RECONFIGURE 

      GO 

      sp_configure 'awe enabled', 1 

      RECONFIGURE 

      GO 

      sp_configure 'max server memory', 6144 

      RECONFIGURE 

      GO

      • 数据库的故障还原模式是否为【简单】,如果采用事务日志备份,不需要修改故障还原模式
      • 数据库的【自动收缩】属性是否取消
      • 再查询分析器中执行DBCC SHOWCONTIG(ICSTOCKBILL)查看表的索引碎片情况,如果【扫描密度】低于85%,那需要重新执行索引重建工作
      • 数据库文件和TEMPDB文件所在磁盘是否有可用空间
    • 组件包设置
      • 组件包启用帐号设置为【指定用户】或者将【交互式用户】,需要将【调用的身份验证级别】设置为【连接】,【模拟级别】为【标识】
      • 组件包的【安全级别】设置为【仅在进程级别执行权限检查】
    • 二次开发
      • 如果有自定义的报表,是否设置脏读的事务隔离级别,即在报表语句前面加上

      SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

    • 网络
      • 在DOS模式下执行ping 【服务器IP地址】 -l 1204 –n 100

      不能出现丢包现象,如果出现丢包的现象,需要检查网络

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

       

    1. 问题处理流程和分析方法

    2.1 问题处理流程

    一般问题的处理步骤如下:

    客户反馈性能或稳定性问题,不要着急,按照如图上的步骤我们逐步分析,正确的方法是解决问题的前提,下面为你快速定位问题作一个简单的说明:

    第一步:引导客户了解具体问题;

    当客户出现性能问题时,首先你要找到发现该问题的客户关键人员(一般都是操作人员),然后和他进行交流沟通。

    找到关键人员以后,引导客户交流,确认问题所在,确认详细的操作步骤,问题发生的模块,相关的业务场景和机器环境等。

    经过前面的交流,如果有可能首先要落实问题的真实性,避免前面描述和交流导致的错误引导。

    第二步:收集用户计算机信息;

            自动收集服务器的事件日志,系统配置环境,操作系统版本等信息。

    第三步:判断问题来源

    根据获取的信息,定位问题对于系统的日志文件和数据库日志文件中的异常。在http://support.microsoft.com/ 网站查找相关的技术或者解决文档,看是否可以解决问题。

    第四步:参照案例解决问题

    初步定位客户问题以后,首先查看一下是否存在类似案例,如果有,可以参照案例集,我们就能够快速有效解决问题。

    如果没有类似案例,我们可以参照相应的分析方法进行分析定位,解决问题(见下面章节的问题分析和解决)。

    第五步:定期收缩数据库和定时优化帐套

    第六步:检查数据库表结构设计是否合理

    常见有:

    二次开发的表没有索引,造成性能隐患;不恰当的触发器和游标的使用,大数据表缺少聚集索引。

    对于K3已经存在的数据表,可以根据用户实际使用业务情况进行索引优化。

    第七步:寻找合适的补丁

    第八步:与研发沟通,获得解决方案

    以上描述的是最基本的步骤,对于客户的性能问题我们最好是及早解决,如果不能解决尽快反馈到研发,往往发现有些客户刚开始有性能问题时,通过重启服务器等方法凑合。当客户这样使用一段时间后可能会越来越不满满意,导致后面解决问题的阻力很大,所以要积极面对,尽早解决。

     

    2.2 问题分类

     

    2.2.1 非K/3软件问题

    这类问题大多是K/3系统的运行环境问题,还有些是应用和实施问题,下面列举一些问题的描述,主要帮助认识问题的本质分类。

    2.2.1.1 网络问题

    网络出现问题时一般有些客户端不能操作并且有明显错误提示。一般表现为网络不畅通,网络带宽不足,网络不稳定有丢包情况,网络安全性问题等,详细请参考手册第五章。

    2.2.1.2 硬件配置

    硬件配置尤其是服务器的硬件配置问题,在很多客户那儿发现硬件配置偏低,从而引起性能或稳定性问题。

    数据库服务器建议使用高性能配置的机器,或通过增加CPU和内存来提升服务器性能。因为数据库是系统的所依赖的平台,如果平台本身有问题,那么应用在上面的系统肯定也会有问题。

    对于硬件配置尽可能在实施时防患于未然,否则如果在使用过程中出现问题时再提议客户升级硬件,可能会受到客户的抵制。一定要对客户的未来业务量有一定的预估,给出合理的硬件配置方案。具体的应用配置请参考后面各个章节的硬件配置部分。

    2.2.1.3 软件环境

    软件环境主要是指数据库服务器的操作系统和SQL Server版本,以及安装的其它软件。在此特别强调数据库服务器的操作系统尽量采用WIN2003 企业版本,SQL Server使用SQL Server2000 企业版,并至少安装 SP4补丁程序。关于客户端尽量采用WIN2000操作系统,不要使用WIN98。这样有助于K/3系统更加健壮的运行。

    2.2.1.4 实施和应用问题

    有些性能问题可以通过合理的实施和应用来避免,主要是通过调整系统参数或使用方式让系统速度得到提升。例如序时簿的查询在过滤界面少选择要显示的列,尽可能使用严格的过滤条件,不要使用显示关联标志的系统选项都会一定程度的提高系统速度。这些问题在手册的不同部分会有相关的内容,以后也会逐步补充。

    在这里还要强调一点在实施中做的二次开发很有可能引发性能问题。对于有二次开发的系统一定要对二次开发作检查,看看是否有性能问题。

     

    2.2.2 K/3软件问题

    对任何软件,都可能会存在一定的性能问题。K/3作为一个复杂的企业应用软件,同样也不可避免会存在性能问题,这需要我们积极去解决。

    2.2.2.1 局部功能速度太慢,不能满足日常的业务要求

    这些慢的功能点大多数是一些查询和计算功能,如物料(商品)收发汇总表查询,期末结账,成本计算等功能。执行慢的原因在于业务处理逻辑复杂,需要访问的数据量很庞大,需要使用更多的系统资源,从而可能导致所有其它功能点都变得很慢,或者系统一段时间无法响应的(实际是得不到系统资源,处于长期的等待中)现象。当然也有些功能可能是由于当初设计的时候考虑不周,算法不够优化,导致单项功能的性能较差,对于这样的问题,可以错开业务使用高峰,优化算法,或对数据库建立索引来提升性能。

     

    2.2.2.2 整体应用存在性能问题

    有些性能问题是由于当时设计系统时没有考虑到数据量的规模,当数据量达到一定规模后系统运行不能达到预期。由于这些问题从软件本身来说可能牵涉很多模块和代码,如果优化需要投入很多的资源,只能在新版产品中改进。如10.2数据授权问题就是这样一个问题,在V10.2SP1中已经做了全面优化。

     

    2.2.2.3 系统突然出现全面的等待现象

    对这类问题,大多数情况是客户端提示"调用程序忙,切换到…","正在调用中间层…"等提示,首先要判断是否网络或硬件问题;然后看数据库是否阻塞,COM+是否出现问题等等,否则有可能是组件本身存在问题,具体可以参考下面各个章节的内容。

     

    2.2.2.4 有规律的在某个时段系统速度变慢

    大多数是月末,或者某段业务高峰期。在发生问题的时段可能会是某一个计算型功能如结账操作耗用系统资源太严重,或者是并发程度高引发系统资源不足.

     

    2.3 问题分析方法

        在处理客户问题时,我们要对问题本质有一个清晰的认识,同时我们要采取有效的方法去逐步发现和解决问题。

     

    2.3.1 排除法

    在处理性能问题时,排除法是最有效的方法。因为大多数客户性能或稳定性问题,尤其是无规律,全面性的性能或稳定性问题,定位问题所在是很重要的。当然对于那些能够明确定位的问题,可以直接进入下面的章节寻求解决方法。

    首先看看是否是非软件的问题。网络是否畅通,硬件配置是否合理,操作系统和SQL Server是否符合建议性的要求(如查看数据库表的统计信息,是否存在碎片),应用方式是否合理。

    如果是软件问题主要就是定位是何功能影响了系统的运行速度。首先可以参照2.1网络与Citrix应用问题4.1 数据库常见性能问题介绍5.1 中间层COM+常见问题介绍判断是数据库、中间层、客户端还是网络存在问题,然后在各自的章节中寻求解决方法。

    如果是数据库性能问题,我们可以从硬件,数据库配置及大小,SQL跟踪优化,数据表索引,数据库日志文件等几个方面进行排查;如果是中间层COM+问题,我们可以参照5.2 中间层COM+常见问题处理中分析和处理方法进行问题处理;如果客户端问题,一般要通过排除确定是数据库、中间层存在问题还是客户端本身程序存在问题。

     

    2.3.2 像医生看病

    解决性能问题就和医生看病一样,分支机构和客户的系统管理员一定要亲自观察现场,可以获取一些从用户描述的现象很难得到一些有价值的信息。就和医生看病一样他不可能只凭病人的描述来诊断。

     

    2.3.3 从现象入手

    解决性能问题总让人有无从下手的感觉,我们定位问题方法更多,最简单的方法从我们看到的现象入手,逐步分析细化,然后根据分析收集的指标数据,定位或解决问题。例如现象是发生在客户端cpu100%,那么直接从客户端入手即可,判断该现象是只有在一台客户端出现,还是所有客户端都出现,然后根据这个我们就可以重新定位问题或者查找原因了。

    1. 网络与Citrix应用问题

    3.1 网络引起的性能问题介绍

    网络引起的性能问题,反映到整个网络系统,或者单独某台计算机上。现象为K/3系统使用不稳定,时快时慢,甚至出现客户端挂起的现象。

    由网络引发导致的性能问题,主要包括下面几个方面:

     

    3.1.1 网络配置不符合K/3应用需求,带宽不足

    当网络带宽不符合K/3应用需求时,最直接的后果是导致K/3应用出现性能问题,特别是进行大数据量的查询时速度更慢。

    检测带宽可用带宽测试软件,例如Chariot;或者服务器架设HTTP/FTP服务,在客户端查看单线程下载文件速度来判断有效带宽,如在100M到桌面网络环境里,客户端通过文件下载实测约5—7MByte/s,据此推算该百兆网实际有效带宽40—56Mbit/s。

    下表是K/3应用对网络的基础要求:

    网络类别

    设计要求

    局域网应用

    1. 核心交换机1000M,数据库、中间层服务器、HR/Web服务器直连核心交换机
    2. 100M交换到客户端桌面,客户端到中间层有效带宽≥40M
    3. 全局域网网络延迟小于10ms,丢包率小于2%

    广域网应用

    1. 核心交换机1000M,数据库、中间层服务器直连于核心交换机
    2. 100M交换到接入服务器(Citrix/终端服务)、HR/Web服务器局域网连接
    3. 10M光纤到接入服务器(Citrix/终端服务)、HR/Web服务器因特网连接
    4. ≥64K有效带宽到每个远程客户端(Citrix/终端服务客户端)
    5. ≥512K有效带宽到每个HR/Web客户端
    6. 若采用VPN+K/3 GUI模式,需≥2M有效带宽到每个远程客户端有效带宽需要
    7. 远程连接网络延迟小于100ms,丢包率小于2%

     

    3.1.2 网络不稳定或存在丢包现象

    出现网络不稳定或存在丢包现象问题时一般有些客户端不能操作并且有明显错误提示。首先应该检查网络是否畅通,如果出现所有客户端都无法操作,要检查中间层和数据库服务器是否互通,并且两台服务器的IP地址和计算机名是否正确。

    一般检查网络是否通畅可以使用PING的方法:

    通过ping Ip地址看是否网络畅通

    通过ping xxx.xxx.xxx.xxx –n 1000 –l 2000命令实测察看是否丢包和网络的平均速率

    通过pathping xxx.xxx.xxx.xxx命令实测察看是否丢包

    time<1ms,sent=1000,received=999,lost=1(0% loss),Min=0ms,Max=9ms,Average=0ms

    for 25 second statistics中,Pct=Lost/Sent=0%即:无丢包,丢包率0%.

     

    一般出现丢包掉线的可能原因主要有:

    1. 局域网中的某台或者多台机器感染了病毒,在疯狂发包,导致路由器NAT连接很快占满;
    2. 可能是交换机长时间没有重启其内存已用光,导致交换数据速度缓慢,或受网络风暴影响导致阻塞或交换机的某一个或几个接口模块损坏,或交换机故障引发的网络内暴

    建议处理方案:

    (1)试着断开某台交换机,进行逐一排查,进行隔离杀毒,找到该台机器,将其隔离;

    (2)关闭局域网内所有交换机4-5分钟后,重新接通电源,观察网络是否恢复正常;

    (3)联系您的网络供应商协助解决。

     

    3.1.3 网络安全性问题

    随着计算机病毒不断变种和蔓延,其危害程度也越来越高,因此网络安全最大的隐患就是病毒,它能直接导致K/3操作缓慢,出现性能问题。

    保障系统安全,一般考虑几个主要因素:

    1、操作系统安全

    ?    及时安装Windows安全补丁(SP和Hotfix)。

    ?    AD域控制器及成员服务器组策略设置、安全模板选择。

    ?    IPSec(IP安全策略,例如,数据库服务器仅允许某IP进行访问,防止非法访问)。(可选项)

    ?    数据库服务器IP地址对客户端不可见,特殊岗位可采用路由或VPN连接。(可选项)

    2、防火墙管理

    防火墙应用目的:设置策略,授权控制访问,诸如:IP地址、端口、网站等等;发布局域网应用(FTP、MAILServer、Web应用、局域网服务器应用程序端口)至Internet。

    例如,Citrix WI服务应透过防火墙发布,而不是将Citrix-K/3服务器直接暴露在互联网招致攻击。

    应用场景:数据库服务器完全受防火墙保护、HR服务器仅发布80等端口。

    特别说明:防火墙目前市面上流行很多品牌型号,防火墙性能高低直接影响K/3 HR,其系统策略复杂程度均会影响网络传输。特别是K/3 HR大量并发用户应用,数据库与HR服务器之间的有效带宽达到100M,甚至更高达1G。所以,在部署防火墙的同时,要求同步考虑防火墙策略是合适,必要时,建议将HR服务器与数据库之间同属防火墙保护范围之内。

    3、建立SSL安全机制(可选)

    IIS的身份认证除了匿名访问、基本验证和Windows NT请求/响应方式外,还有一种安全性更高的认证,就是通过SSL(Security Socket Layer)安全机制使用数字证书。

    建立了SSL安全机制后,只有SSL允许的客户才能与SSL允许的Web站点进行通信,并且在使用URL资源定位器时,输入https:// ,而不是http:// 。

    简单的说默认情况下我们所使用的HTTP协议是没有任何加密措施的,这点危害在一些企业内部网络中比较大,对于使用HUB的企业内网来说简直就是没有任何安全可讲,因为任何人都可以在一台电脑上看到其他人在网络中的活动,对于使用交换机来组网的网络来说,安全威胁性要小很多。

    所以,对安全性要求较高的企业,全面加密整个网络传输隧道的确是个很好的安全措施。

    4、定时查杀病毒

    定时地更新病毒库并在非业务操作时间进行定时的病毒查杀,可以更有效地防止病毒危害,同时也避免对K/3业务操作的性能影响。

     

    3.2 Citrix应用引起的性能问题介绍

    Citrix应用引起的性能问题一般主要在Citrix服务器的配置上面。

     

    3.1.1 Citrix应用硬件配置指南

    一般去除操作系统和Citrix服务器的的消耗,每个Citrix K/3客户端大概耗用50~150兆左右内存。因此对于30个客户端的并发,最少需要30*50 + 500(操作系统和Citrix服务器的消耗) = 2000 (M)的内存。如果内存不足时,操作系统将会自动进行换页处理,这时需要空余的磁盘空间作为交换文件,但也会极大影响程序的性能。

     

     

     

    1. 数据库性能问题

    4.1 数据库常见性能问题介绍

    本章主要对目前K/3数据库与性能有关的问题进行描述,帮助用户更好地优化数据库服务器性能,以提升K/3整体应用的性能。主要包括数据库服务器硬件性能、数据库维护策略、数据库表结构优化等以及一些其他注意事项。

     

    4.1.1 数据库服务器硬件配置

    从很多客户反馈的性能问题发现:数据库服务器硬件配置偏低,对系统运行性能产生了一定的影响,导致客户出现整体性的性能问题。

    数据库服务器作为账套数据的存储平台,无论从性能还是可靠性方面都提出了很高的要求,其配置的基本要求如下:

     

    经济型配置建议(100个在线用户以内应用,账套大小在4G以下)

    项 目

    配 置

    OS

    Windows Server 2003企业版 + 最新SP (目前SP2)

    MSSQL

    SQL Server 2005标准版 + 最新SP (目前SP2)

    CPU 

    双核Xeon 5100系列,配置双路CPU,合共4物理核心

    内存

    4-8GB

    存储

    UltraSCSI或SAS,RAID 5 或 RAID 10

    网络

    1000M交换

     

        标准型配置(100-200个在线用户应用,账套大小在4-8G)

    项 目

    配 置

    OS

    Windows Server 2003企业版 + 最新SP (目前SP2)

    MSSQL

    SQL Server 2005标准版或企业版 + 最新SP (目前SP2)

    CPU 

    四核Xeon 5300系列,配置双路CPU,合共8物理核心

    内存

    8-16GB

    存储

    SAS,RAID 5 或 RAID 10

    网络

    1000M交换

     

    高端应用(200-400个以上在线用户应用,账套大小在8G以上)

    项 目

    配 置

    OS

    Windows Server 2003企业版 + 最新SP (目前SP2)

    MSSQL

    SQL Server 2005企业版 + 最新SP (目前SP2)

    CPU 

    四核Xeon 7300系列,配置四路CPU,合共16物理核心

    内存

    16-32GB

    存储

    FC-SAN

    网络

    1000M交换

     

    通过增加内存和CPU可以提升数据库服务器的性能,利用RAID来存储数据可以提高数据的安全和可靠性,同时也会带来一定的I/O性能提升。另外也可以考虑将账套分布到不同的数据库服务器上。一般通过观察服务器上任务管理器的性能监控可以大概判断硬件配置是否有问题。下面主要谈谈CPU和内存因素。

    4.1.1.1 与CPU有关问题

    症状1:

    数据库服务器中任务管理器CPU持续100%很长一段时间

    分析:

        当发现数据库服务器的CPU很长一段时间都是100%占用,首先确认是否为很少使用的计算功能或者是大数据量查询,还是日常业务功能;若为前者,建议适当安排系统空闲时间,尽量不要在业务高峰期运行;若为后者,请通过SQL事件探查器跟踪执行时间较长的SQL,对SQL进行优化(参考),如果仍然不能解决,请将耗时比较长的SQL发回研发中心进行分析和定位。

     

    症状2:

    数据库服务器CPU绝大多数时间保持在40%以上

    分析:

        数据库服务器CPU长期保持在40%以上,系统的运行速度时快时慢,这表示CPU的负荷已经很重,建议升级硬件,增加CPU的个数可能是需要的。

     

    症状3:

    数据库服务器CPU耗用很低,但系统整体性能很差

    分析:

    这种情况很可能是数据库发生阻塞。

    对执行结果进行分析并寻求解决方法,如果不能解决,请把结果保存为文件反馈到研发中心,研发人员会根据此结果进行处理。

    4.1.1.2 与内存有关问题

    1. 简单判断数据库服务器内存是否够用

    在任务管理器中选择查看-显示内核时间,会显示一条红线,如果红线很高,证明大量的磁盘读写操作,说明内存可能不够,需要大量的内存切换。

    打开性能计数器,查看【磁盘的平均队列长度】,如果长时间大于2,可能内存不够用

    2. 数据库服务器内存居高不下

        首先明确,K/3中数据库服务器的内存只上升,不下降,不是我们的软件问题,而是SQL Server使用内存的策略造成,是正常现象,相关的内容可以在微软的技术支持网站上查到http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_config_9zfy.asp

    3. 数据库服务器内存配置

    数据库的物理内存一般来说越大越好,由于考虑到成本问题,需要对用户未来的业务有一个估计,业务数据量和业务的频繁度可以作为配置服务器硬件的一个依据。数据量对数据库服务器的内存配置有直接的影响,从经验的数字来说最好是物理内存要大于账套的数据文件,如果账套数据文件小于1G,应该配置至少1G内存,如果账套数据文件大于1G, 物理内存应该和数据文件大小相当,例如账套数据文件为2.4G,那么应该配置至少2-3G内存。

    4.如果物理内存超过4GB,请参照附录中《SQL Server 的大内存管理》设置

    4.1.1.3 数据库实例默认选择【并行】导致死锁和阻塞问题

    1:由于启用了【并行】可能导致死锁。主要表现为同一功能,隔一段时间就会出现死锁,此时客户端现象为:

     

    如果出现这样的情况时,请在SQL 查询分析器中执行dbcc traceon(1204,3605,-1)【SQL SERVER 2000跟着标记为1204,SQL SERVER 2005中为1222】,将死锁的信息记录到数据库的日志中。然后等待场景重现,再出现后这时候运行数据库的企业管理器,查看数据库的日志,将会看到类似下面的信息:

    ResType:LockOwner Stype:'OR' Mode: S SPID:64 ECID:13 Ec:(0x8E0480C0) Value:0xaa

    Requested By: Owner:0xa9617ba0 Mode: S Flg:0x0 Ref:1 Life:00000001 SPID:64 ECID:14

    Wait List:

    PAG: 16:1:319244 CleanCnt:5 Mode: IX Flags: 0x2

    Node:4

    Producer: Xid Slot: 7, EC = 0x8d26a0c0, SPID: 64, ECID: 16, Blocking

    Producer: Xid Slot: 5, EC = 0x8dffc0c0, SPID: 64, ECID: 14, Blocking

    Producer: Xid Slot: 4, EC = 0x8b6ae0c0, SPID: 64, ECID: 15, Blocking

    Producer: Xid Slot: 3, EC = 0x8e0480c0, SPID: 64, ECID: 13, Blocking

    Producer List::

    Consumer: Xid Slot: 6, EC = 0x8b4dc0c0, SPID: 64, ECID: 2, Not Blocking

    Consumer: Xid Slot: 2, EC = 0x8db4e0c0, SPID: 64, ECID: 4, Not Blocking

    Consumer: Xid Slot: 1, EC = 0x8deb80c0, SPID: 64, ECID: 3, Not Blocking

    Consumer: Xid Slot: 0, EC = 0x8a00e0c0, SPID: 64, ECID: 1, Not Blocking

    Consumer List::Coordinator: EC = 0x8885d560, SPID: 64, ECID: 0, Not Blocking

    Port: 0x800b0480 Xid Slot: 0, EC: 0x8a00e0c0, ECID: 1 (Consumer), Exchange WaiNode:3

        这样可以确定是"涉及并行的死锁",即SPID为64的进程出现了自我阻塞而导致的死锁,该死锁主要是SQL SERVER执行的策略上的问题,SQL语句的写法上可以解决,但在不同的服务器上可能有不同表现,所以通过禁用并行来解决。如果要开启处理器支持并行计划,请确保数据库服务器的配置足够好【如16CPU【物理CPU】,32GB内存】

        解决办法:

    如果是早期超线程的机器,需要关闭超线程,修改CMOS

    a):开机--〉进入BIOS设置画面

    b):将HYPER-THREADING设为DISAB

    取消并行执行;

    sp_configure 'show advanced options', 1

    RECONFIGURE

    GO

    sp_configure 'max degree of parallelism',1

    GO

    sp_configure 'show advanced options', 0

    RECONFIGURE

    根据提示,重启数据库服务

    4.1.1.4 与17883错误相关

        如果出现数据库HANG,查看数据的日志文件,可以看到类似下面的信息:

    server    错误: 17883,严重度: 1,状态: 0

    DBCC TRACEON 208,服务器进程 ID (SPID) 60。

    server    进程 191:0 (8d0) UMS 上下文 0x074BECC8 似乎不是在调度程序 0 上生成的。

    出现上面的问题时,可以确认是SQL SERVER本身的问题,产生该问题的原因比较多,微软提供的补丁SP4也未能解决所有的17883问题。

    解决方式:(本补丁只针对SP4)

    http://hotfixv4.microsoft.com/SQL%20Server%202000/sp4/SQL_Server2000_SP4_Hotfix2171/08.00.2171.00/free/255994_CHS_i386_zip.exe

    Password: lUn)1p3h

    如果SQL SERVER已经出了最新的补丁,则直接升级到最新的补丁即可。

    相关17883问题描述:请查看微软网站的815056319892810885等文章

     

    4.1.2 数据库维护策略不当

    对于任何一个数据库系统,日常的维护是必要的,在日常的系统维护中分支机构应该引导客户的系统管理员做维护,防性能问题于未然。

    但有时候不当的维护策略也对性能造成一定的影响。结合常见维护策略进行介绍,旨在防性能问题与未然。

    在应用K/3时为了提升整体应用性能,数据库需要做如下的维护策略:

    4.1.2.1 设置数据库故障还原模型为"简单"

    在SQL Server企业管理器中选择一个数据库,右键点击弹出快捷菜单,选择"属性",如下图界面。数据库的故障还原模型建议使用"简单"模式。

    如果采用"简单"以外的故障还原模式,将可能产生大量的日志文件从而影响数据库系统性能

    注意:选择简单模式后数据库将不能做事务日志备份。

    4.1.2.2 取消"自动收缩"数据库选项

    将数据库"属性"中的"自动收缩日志"选项取消(如2.1.2.1下图)。由于需要频繁检查数据库的空间使用情况以及自动收缩有可能发生在数据库文件自动增长之后而增加额外的开销。

    4.1.2.3 定期收缩数据库

    SQL Server数据库的事务日志会由于各种原因,有时候暴涨,事务日志太大有时候会引发性能问题,因此要有计划地收缩数据库来缩小事务日志。收缩数据库时不但要收缩账套数据库,同时也要收缩SQL Server自带的TEMPDB数据库。可以通过SQL Server企业管理器做一个收缩计划,在没有业务运行的时候定期做收缩,尽量不要在平时做收缩操作,因为收缩操作耗用资源很多,且需要一段时间。

    在SQL Server企业管理器中选择一个数据库,右键点击弹出快捷菜单,选择"所有任务"---〉"收缩数据库",如下图界面。

    选择根据本调度来收缩数据库(收缩的频率不要过于频繁,否则容易产生更多的碎片,导致数据库性能更差),然后点击更改按钮,如下图界面做调度安排。

     

    4.1.2.4 定期优化帐套

    在SQL Server运行一段时间后,表空间和索引的存储可能会产生碎片,这会极大的影响系统的性能。数据库表是否存在碎片可以通过在SQL查询分析器中使用下面的命令来查看:

    如:dbcc showcontig(icstockbill) 显示结果为

    DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表...

    表: 'ICStockBill'(1180583294);索引 ID: 1,数据库 ID: 15

    已执行 TABLE 级别的扫描。

    - 扫描页数.....................................: 9935

    - 扫描扩展盘区数...............................: 1252

    - 扩展盘区开关数...............................: 8485

    - 每个扩展盘区上的平均页数.....................: 7.9

    - 扫描密度[最佳值:实际值]....................: 14.64%[1242:8486]

    - 逻辑扫描碎片.................................: 41.35%

    - 扩展盘区扫描碎片.............................: 60.46%

    - 每页上的平均可用字节数.......................: 3763.6

    - 平均页密度(完整)...........................: 53.50%

    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

    可以看出icstockbill表的扫描密度为14.64%,逻辑扫描碎片为41.35%;扩展盘区扫描碎片为60.46%说明存在较多的碎片,并且统计信息很多记录都未进行更新,这将严重影响使用该表时的查询速度,需要对该表进行重建索引。那么我们使用dbcc dbreindex(icstockbill)对icstockbill表重建索引,再对icstockbill表进行统计可以看到下面的结果:

    DBCC SHOWCONTIG 正在扫描 'ICStockBill' 表...

    表: 'ICStockBill'(1180583294);索引 ID: 1,数据库 ID: 15

    已执行 TABLE 级别的扫描。

    - 扫描页数.....................................: 5444

    - 扫描扩展盘区数...............................: 682

    - 扩展盘区开关数...............................: 681

    - 每个扩展盘区上的平均页数.....................: 8.0

    - 扫描密度[最佳值:实际值]....................: 99.85%[681:682]

    - 逻辑扫描碎片.................................: 0.00%

    - 扩展盘区扫描碎片.............................: 29.91%

    - 每页上的平均可用字节数.......................: 189.7

    - 平均页密度(完整)...........................: 97.66%

    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

    可以看出icstockbill表的扫描密度为99.85%,逻辑扫描碎片为0.00%;扩展盘区扫描碎片为29.91%,数据页从原来的9935调整为5444,说明碎片已经得到了很好的整理。

     

    可以通过两种方式进行整理,我们称之为"优化帐套",下面介绍两种方法:

     

    方法1:只对部分核心表进行整理,选择"账套管理" —〉"数据库" —〉"优化帐套",缺点是账套优化功能不能做调度定时执行,需要每次手工点击执行;

    方法2:在SQL Server企业管理器中做维护计划,使用企业管理器中管理—〉数据库维护计划—〉新建维护计划向导,在第三步,选择重新组织数据和索引页,如图4。

        由于碎片是由于日常的业务操作导致表中的数据处于不断的删除,新增中造成的,所以应该定期进行优化帐套的操作。建议每周执行一次,同时避开使用K/3系统的高峰期。

        注:如果通过重建索引后,扫描密度,逻辑扫描碎片和扩展盘区扫描碎片依然不能得到较大的下降,这时候请先记录下原来建立的索引信息,手工删除所有的索引后,然后再重新建立索引来达到降低碎片。

        另外导致该问题还有可能由于数据库文件本身的碎片过多,这时候可以通过进行磁盘碎片整理后,备份后还原新账套的方式来处理。

    4.1.3 数据库表结构不合理

    针对客户一些特殊需求我们都是以二次开发方式来满足,因为开发周期比较短,更多关注功能实现,忽视了性能问题,常见有:二次开发的表没有索引;不恰当的触发器和游标的使用;不合适的事务隔离级别;以及不正确的SQL语句写法。

     

    对于K/3已经存在的数据表,可以根据用户实际使用业务情况进行索引优化。这个需要一定的数据库知识,可以通过使用SQL Server事件探查器和查询分析器,分析执行时间长的SQL, 对于经常出现在where子句中的字段,并且该字段对应的值在数据表中重复数不高时可以考虑对该字段建立索引,还有就是观察表是否主要用于查询(SELECT)的表,则索引可以根据实际情况多建。但索引也并非越多越好应该限制在10个以内。

        对于二次开发的数据表,可以参考下面的原则:

    1)必须对表建立聚集索引

    2)选择WHERE,ORDER BY,GROUP BY 子句中的字段建立为索引

    3)尽量不要使用触发器和在触发器和存储过程中使用游标

    4)报表采用脏读的事务隔离级别

    5)不要关联不必要的表

    6)可以关联物理表的不要关联视图

    7)排序操作通过控件而不是SQL 语句来实现

    8)WHERE子句中不要对字段使用函数进行比较操作

        

    4.1.4 数据库性能优化方法总结

    1、合理的硬件配置

    2、改变和调整应用方式

    3、正确的数据库维护策略

    4、优化数据库索引

    5、与研发沟通,获得解决方案

     

    4.2 数据库性能常见问题解答

     

    Q: 影响系统运行性能的主要因素有哪些?

    总体来说有以下几方面:

    数据量

    并发客户端的数量

    硬件配置和软件环境配置

    二次开发

    数据授权

     

    Q: 如何评价并发客户数量?

    正确的评价客户客户端的数量:在业务高峰期同时使用的客户端的数量,并发数越多,速度越慢,很容易造成阻塞甚至死机

     

    Q: 数据库服务器要注意什么事项?

    1、强调数据库服务器的操作系统尽量采用WINDOWS SERVER 2003,SQL Server使用SQL Server2000 企业版或者SQL SERVER2005。确认SQL Server2000是否已经打上SP4补丁,SQL SERVER2005是否打上SP2补丁。

    2、 尽量将数据库服务器和中间层服务器分开在两台机器上部署,数据库建议使用64位(x64)服务器,并配置双路或四路处理器,处理器推荐Xeon双核/四核2.4G或以上,内存8G或以上,SAS或FC-SAN存储系统,1000M服务器专用网卡。

     

    K/3数据库的性能案例请参照《金蝶K/3产品性能稳定性案例集.doc》

     

    1. 中间层性能和稳定性问题

    5.1中间层COM+性能和稳定性问题优化指导

    本章主要对目前K/3中间层应用中与性能稳定性相关的问题进行描述,包括中间层服务器配置、COM+组件挂起、CPU100%、Crash,内存泄露等问题症状,以提升中间层应用的整体性能和稳定性。

     

    5.1.1 中间层服务器硬件配置

    中间层的任务是运行K/3系统的业务组件,一个中间层服务器往往要为多个客户端提供服务,因此对中间层机器的配置要求一般较高,以提升系统应用的并发能力。

     

    经济型配置建议(100个在线用户以内应用)

    项 目

    配 置

    OS

    Windows Server 2003标准版 + 最新SP (目前SP2)

    CPU 

    双核Xeon 5100系列,配置单路CPU,合共2物理核心

    内存

    2-4GB

    存储

    UltraSCSI或SAS,RAID 1 或 RAID 5

    网络

    1000M交换

     

        标准型配置(100-200个在线用户应用)

    项 目

    配 置

    OS

    Windows Server 2003标准版 + 最新SP (目前SP2)

    CPU 

    双核Xeon 5100系列,配置双路CPU,合共4物理核心

    内存

    4GB

    存储

    UltraSCSI或SAS,RAID 1 或 RAID 5

    网络

    1000M交换

     

    高端应用(200-400个在线用户应用)

    项 目

    配 置

    OS

    Windows Server 2003标准版 + 最新SP (目前SP2)

    CPU 

    四核Xeon 5300系列,配置单路CPU(可扩双路),合共4物理核心

    内存

    4-8GB

    存储

    SAS,RAID 1 或 RAID 5

    网络

    1000M交换

     

    业务量的大小,客户端的数目会影响中间层服务器的处理和响应能力,通过增加CPU、内存可以对性能的提升带来一定的好处,但这并不是万能的,当达到一定的并发数量后,配置的提升可能对性能的改进成效并不明显,此时应该考虑中间层的分布处理。

        中间层使用部门级的服务器即可。根据实际测试的结果,K/3系统中,一台配置为:主流双路双核XeonCPU、2GB内存的中间层服务器,所能负载的并发用户数为100个左右。在超过该并发数目时,可通过提升服务器的硬件配置解决,当单台服务器增加配置仍无法满足性能要求时,此时需要采用多台中间层服务器进行分布式处理。

     

    5.1.2 中间层与客户端不同域性能优化

    客户端和中间层最好是配置在同一域中,如果无法配置在同一域中。可以修改组件服务中COM+组件的安全验证选项,如下所示。降低身份验证级别,能够在一定程度上改善调用中间层组件的性能。

    另外,使用组件信任注册中间层组件,以提升安全性或降低域服务器负载。

    采用信任注册,需要将调用的身份验证级别设置为【连接】,模拟级别设置为【标识】

     

    5.1.3 COM+常用处理方法

        这里先列出所有常见的处理COM+问题的方法,后面针对COM+的挂起、CPU100%、性能问题、Crash,内存泄露问题的分析和处理会相应地说明各类问题可以使用哪些常用的处理方法。遇到相关中间层COM+问题时,你可以尝试下面的解决方案看能否解决问题。

        出现这些问题时,可以在系统的事件查看器中查看到相应关于COM+,MSDTC,DCOM类别的错误和警告信息【通过CMD模式下运行eventvwr.msc打开事件查看器】。

    5.1.3.1 重装MSDTC

    方法:在CMD模式下运行msdtc –uninstall,然后重启,运行msdtc –install重新安装

    说明:如果在日志中发现MSDTC服务自动停止的情况,或者你的机器是克隆并出现事务无法提交,那么可以尝试重新安装MSDTC。

    注意: 该操作需要重启电脑!

    5.1.3.2 MSDTC的Log文件路径错误

    方法:打开组件服务—我的电脑属性—MSDTC页签,检查MSDTC的Log文件路径是否是%SystemRoot%\System32\Dtclog

    说明:如果出现MSDTC无法启动的问题,请检查MSDTC的Log文件路径是否正确。

    5.1.3.3 配置线程(For windows2000)

    方法:修改注册表,见complusthread.reg

    HKEY_LOCAL_MACHINE\Software\Microsoft\COM3\STAThreadPool

    Value name: EmulateMTSBehavior

    Data type: REG_DWORD

    Value data: 0x64

    让单个COM+ VB组件同时服务最多100个线程,以提高处理并发请求的数量。

    请参考: http://support.microsoft.com/kb/303071/EN-US/

    说明:WINDOWS启动的每个进程,所允许的STA线程数,一般为7+CPU个数,默认最大为10*CPU个数,当并发用户较多时,在一个进程池内组件的线程数量超过此数值时,组件的调用会发生阻塞,也容易导致组件崩溃,这也是产生"COM+ 4689错误: 运行时环境检测到其内部状态存在不一致。这说明进程中存在潜在的不稳定性,可能是由于 COM+ 应用程序中运行自定义组件、COM+ 应用程序使用的组件或其他因素引起的。d:\srv03rtm\com\complus\src\comsvcs\threads\stathreadpool.cpp(1223)中的错误,hr = 8000ffff: CSTAThreadPool: Unable to get bind thread."的原因。

    由于vb组件对多线程支持较差,所以需要通过修改注册表,增加最大线程数,来解决此问题。

    注意:改完注册表需要重启机器才能生效。

    5.1.3.4 组件多进程池配置(For Win2003)

        方法:选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包,单击右键,选"属性"菜单,进入界面后选"共用与回收"标签页,更改"池大小"。

    根据目前中间层服务器的配置情况和软件的实际情况,对于大多数组件建议设置为1,如果出现中间层组件堵塞同时服务器内存充裕的情况下,对于EBOK3等应用并发调用极其频繁的组件可根据其线程数增大进程池数目。例如对于像EBOSYSTEM、EBOPUBLIC这样应用比较频繁的组件设置为2,对于EBOK/3应用极其频繁的组件设置为2-3。

    说明:WINDOWS允许为每个COM+包的组件开辟多个进程池,这样就可以将该组件的线程分散到不同的进程池中,有利于系统调度,减少进程的阻塞,提高系统服务性能。

    注意:在资源——CPU、内存许可的情况下,理论上进程池数量越大越好,但其受系统核心的desktop heap的限制,进程数不能无限加大,如果过大,可能导致desktop heap不足,引发组件创建失败错误。为了发挥最佳性能,必须根据COM+组件应用的情况,合理设置每个com+包的进程数。

    金蝶K3中间层组件包EBO*,目前已经达到40多个,一般情形下,不要随意更改该组件包得其他属性,除非本文档中有介绍可以使用以外,否则,可能产生负面影响。一般如果操作系统剩余内存比较充足,建议对应用较多的中间层组件包EBO*进程池数量为2个,特别充裕时可以设置为3个。

    5.1.3.5 Desktop heap设置

        方法:扩大Desktop Heap以增加创建Apartment的个数。

    a)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SessionViewSize

    缺省是48M, 是系统范围的desktop heap 的大小,将SessionViewSize改成96M来增加整个系统范围内的desktop heap的大小。

    b)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\SubSystems\Window的值:

    %SystemRoot%\system32\csrss.exe

    ObjectDirectory=\Windows SharedSection=1024,3072,512 . . . . . .

    1024, 3072, 512 是default setting, 将512改成4096, 以增加可创建窗口的数量。

    说明:每个系统Desktop对象都有heap 与之对应,Desktop对象使用heap(堆)存储菜单、字符串和窗体等。系统从核心缓存(48M)中分配desktop heap。一个WINDOWS操作系统可以有多个desktop heap。

    其分配可以通过注册表进行控制,上面b)的SharedSection=1024,3072,512的三个数字控制heap的分配

    第一个键值是Desktop所有对象共享的heap大小。包括全局句柄表(窗体、菜单、图标等的句柄)

    第二个键值对应交互式window station Winsta0的desktop heap的大小。用户对象如钩子、菜单、字符串、窗体等消耗desktop heap的内存。此值不必修改。

    第三个键值对应非交互式window station的desktop heap的大小。如果没有这个键值,那么其大小和第二个键值一样。

    在非交互式工作站下,SCM(服务控制管理台)为一个用户账号的每一个服务进程创建一个新的desktop,因此,一个用户账号的每一个服务将消耗desktop heap 的数千字节。

    减少第二个或第三个键值的大小会增加相应工作站desktop的可创建数量。但较小的键值会限制每个desktop内钩子、菜单、字符串和窗体的数量,即限制此进程内组件的创建。另一方面,增加第二个或第三个键值的大小会减少desktop的可创建数量,但每个desktop内钩子、菜单、字符串和窗体的数量会增加。

    因为在非交互式工作站下,SCM为一个用户账号的每一个服务进程创建一个新的desktop,较大的desktop heap值将减少此系统可以服务的用户账号数量。

    全部的desktop heap 必须适应于48M系统范围的缓存。

    当发生组件创建失败/超出内存的错误时,可以适当加大这些键值,如将SharedSection=1024,3072,512的三个数字改为2048,3072, 2048。

    参见http://support.microsoft.com/?id=184802

    5.1.3.6 应用程序回收时间限制

        方法:选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包,单击右键,选"属性"菜单,进入界面后选"共用与回收"标签页,设置[应用程序回收],使用默认值。

    Lifetime Limit: 0

    Memory Limit: 0

    Expiration Timeout: 15

    Call Limit: 0

    Activation Limit: 0

    说明:应用程序回收中的参数意义:生存时间限制——表示组件从创建到销毁的时间,默认为0,即按照组件自身的生命周期存活;内存限制——表示COM+占用的最大内存数,一旦实际占用达到此限制,系统会自动销毁一些组件,在确认使用情况的前提下,可以根据机器配置设置此值;过期超时——表示在组件销毁时因为尚在激活状态或其他原因,不能立即销毁情况下等待的最大时间,默认为15分钟;调用限制/激活限制——表示允许的最大调用/激活进程数,建议使用默认值0。

    系统默认不限制,金蝶K3软件在Windows2000系统最大的性能问题,组件进程出现"死锁"现象,随着用户数量递增,出现的频率也越高,至今仍然没有一个较好得解决办法。在Windows2003操作系统下,略做组件服务设置,那么可以基本上解决上述"死锁"现象。一般来说,该"死锁"问题解决,那么数据库中的记录"死锁",相应也大大缓解。可以这样理解,同样硬件条件下服务器,在Windows2003做上述进程池设置和应用程序回收时间限制,其综合性能指标比Windows2000要优越很多。也许有人会问,如果某单一业务处理时间(例如40分钟)大大操作回收时间限制?其实该系统它不会强制关闭您业务正在处理得请求,直到完成后该进程将自动关闭。简略设置如下图所示

    注意:合理设置Lifetime Limit的值对解决数据库的死锁有一定帮助,但其值不要设置太短,否则会导致COM+ Runtime频繁关闭和启动DLLHOST进程,增加系统的资源压力。

    5.1.3.7 MSDTC超时设置

        方法:选择"管理工具-组件服务-计算机-我的电脑",单击右键,选"属性"菜单,进入界面后选"选项"标签页,设置[事务超时]。

        设置时可以根据目前的事务性能日志——例如在118S左右,因此可以设置为120S。

        说明:MSDTC超时时间表示分布式事务的提交时间,与数据库访问事务有密切关系,优先级低于数据库的超时设置,分布式事务如超过此时间将中止。此时间需要根据事务的平均耗时来设置,设置过大容易导致数据库产生死锁,过小会使一些耗时较长的事务不能提交,使一些长事务被频繁的KILL,导致客户端业务不能正常完成。增大Transaction Timeout值可以减少保存数据引起过多的失败操作。

    5.1.3.8 空闲等待时间设置

        方法:选择"管理工具-组件服务-计算机-我的电脑-COM+应用程序"下某个应用程序包,单击右键,选"属性"菜单,进入界面后选"高级"标签页,设置[空闲等待时间]。

    此参数与上述回收参数设置的生存时间限制参数综合作用,协调处理组件的销毁工作;需要根据客户用户数量与频繁调用状况来决定。

        说明:空闲等待时间表示一个进程在空闲状态时的等待时间,超过此时间则会进行销毁,此时间需根据组件调用情况合理设置,设置过长将导致组件进程不能及时释放,设置过短将导致组件频繁销毁创建。

        注意:该参数不能设置太大,以尽量减少空闲进程对系统资源的占有。

    5.1.3.9 确保中间层组件编译参数的正确

        方法:使用工具VB CheckW2K进行检查,对没有选中Unattended Execution和Remained In Memory选项进行编译的中间层组件重新编译(主要指二次开发组件)。

        说明:如果中间层没有选中Unattended Execution和Remained In Memory选项进行编译,运行COM+组件会导致COM+的不稳定,甚至导致内存泄露,因而对中间层组件要求编译时参照下面要求进行编译:

    General页面

    1.Unattended Execution 必选

    2.Upgrade ActiveX Controls 必选

    3.Retained In Memory 必选

    4.Threading Mode :选Apartment Threaded

    5.1.3.10 更新服务器环境

    方法:此部分主要是更新COM+应用服务器的环境,保证服务器的稳定,主要包括

    (1)服务器端使用最新的VB运行时文件。安装最新的VB SP6 Runtime,将msvbvm60.dll从版本96.90升级到版本97.82

    (2)升级操作系统到最新的Service Pack,WIN2000请打SP4,WIN2003请打SP1。

    (3)升级MDAC到最高版本。

     

    5.1.4 Win2003下中间层EBO组件包安全设置

        在Windows 2003环境中安装K/3中间层,特别是早期版本,要求对EBO包属性中安全设置部分进行修改,否则,当客户端数量超过一定数量时,将不定时出现COM+服务错误致使客户端全部中断。所以要求按照如下图设置,否则K/3系统运行不稳定。

    如果组件包采用【交互式用户】和【下列用户】的方式运行,将【调用的身份验证级别】设置为【连接】,【模拟级别】设置为【标识】

     

    5.1.5 杀毒软件对中间层的影响

    杀毒软件对中间层的影响主要产生原因是:

    (1)中间层运行将再内存中产生大量的Dllhost.Exe进程

    (2)杀毒软件启用实时监控进程,将监督Dllhost.Exe

    (3)系统CPU内存急剧上升

    可以采取的防御措施包括:

    (1)定期空闲时间杀病毒。

    (2)K3业务进行时,停止杀毒软件实时监控服务。

     

    5.1.6 Windows2003中IIS6.0进程管理

    相比Windows2000中IIS5.0,IIS6.0同样存在进程管理得优点。经典案例:"金蝶集团人力资源管理系统",也就是说金蝶数字神经系统中的HR.,往年金蝶员工清楚记得在做绩效评估时,要求员工分部门,按照不同时段去完成,而且即使这样还无法保证系统"死机",而2004年1月自从Hr更换为Windows2003操作系统后,还没有发现过上述现象。系统非常稳定。

     

    5.2 COM+问题常用分析方法

        

    5.2.1 排除法

    COM+挂起、死锁和异常问题一般可以从数据库,系统环境和组件本身出发进行分析,通过逐个排除来定位问题具体在数据库、系统环境还是组件本身。

    (1)对数据库我们可以通过SP_LOCK和select * from sysprocesses 查看数据库锁的信息和进程阻塞情况,通过 KILL SPID结束长时间未响应的进程;

    (2)对于系统环境和组件本身,我们可以创建一个简单的测试组件进行测试,如果简单的组件也出问题,该问题很可能是由于环境导致的,否则,是代码导致的。

    (3)对于环境问题,我们可以通过方法4.1.3.3 配置线程修改DIIHOST的MAX THREAD来看是否是由于线程限制引起,如果是我们可以更改加大DIIHOST的MAX THREAD,同时了解系统是否克隆,系统的事务处理是否出问题,如果是,可以通过5.1.3.1 重装MSDTC的方法重新安装MSDTC看问题能否解决,或者我们可以尝试重新安装操作系统来解决。同时,还可以检查下面一些因素:病毒防护程序,注册表,用户权限,网络连接情况。我们还可以通过一些工具,比如filemon来检视问题发生时候文件访问情况,看看有没有什么异常。

    (4)对于代码问题,我们可以通过记录log文件来跟踪死锁发生在什么方法上,看是在哪一行发生了错误,错误代码是什么,然后尽可能简化该方法来找到问题的根源。

    How To Create Error Handlers in Visual Basic COM Components

    http://support.microsoft.com/?id=269797

    (5)如果问题不是每次都发生,我们需要在问题发生后抓dump文件,也就是相关进程的内存镜像来分析,分析方法见【金蝶K3产品性能稳定性优化指导手册(辅助工具).doc COM+问题分类分析和处理方法】部分

     

    5.2.2 信息收集综合分析法

        发生COM+问题后,如果我们很难确定发生问题的原因,我们可以收集下面的信息,然后综合收集的信息综合分析,看问题的根源是在哪一部分。

    1. 根据日志收集com+错误信息,根据COM+错误信息分析和处理问题
    1. 根据应用程序ID,定位到具体的com+组件和类上,查看相关的组件和类运行是否正常,是否能正确被创建和实例化。
      1. 收集desktop heap内存消耗情况,如果消耗太大可以参照5.1.3.5 Desktop heap设置处理。

             收集方法:

    • 拷贝heapmonpkg.exe到要检测的机器上;
    • 打开命令行窗口,运行heapmonpkg.exe (安装目录设在C:\Heapmon);
    • 运行instheapmon.bat (这会从微软的public symbol server下载win32k.sys的调试符号并且安装一个driver,所以请保证能访问internet);
    • 运行heapmon.bat,显示结果在屏幕上,并且输出到C:\Heapmon\stats.txt。
    1. 收集进程池数,线程数,看设置是否合理。通过5.1.3.3 配置线程5.1.3.4 组件多进程池配置(For Win2003)反向查看。
    2.     收集事务并发数量,最长事务执行时间。
    3.     收集站点并发数量。
    4.     检查vb组件编译设置,见5.1.3.9 确保中间层组件编译参数的正确
    5.     收集内存/cpu信息,看是否存在性能或内存泄露问题。
    6.     收集数据库大小,索引信息,表的大小,看是否数据库存在瓶颈。
      1. 按照KB287643设置DebugBreakOnFailFast为Y,收集相关信息,然后设置为N. 当COM+发生异常时会弹出提示,这是可以抓一个完整的COM+DUMP文件进行问题的分析和处理,DUMP分析见 【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分

        How To Obtain a Userdump When COM+ Failfasts

        http://support.microsoft.com/default.aspx?scid=kb;en-us;Q287643

      2. MPSReport

        http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en

        使用alliance版本收集MPSReport, 直接运行即可,文件会生成在% Windows%\MPSReports\Alliance\cab目录下。

      3. COM+ Catalog Dump

        命令行: comcatdump.exe > c:\comcatdump.log

     comcatdump.zip 密码123456

    1. 客户机器上system32下面msvbvm60.dll的版本,参照5.1.3.10 更新服务器环境。关于msvbvm60.dll 在Windows Server 2003上应该是不需要组件勾选这些options的,请参考,http://support.microsoft.com/?id=833891。
    2. 通过性能日志查看系统性能情况

    在服务器上打开性能监视器

    1) 展开 "性能日志和警报"

    2) 右键点击"计数器日志"

    3) 选择"新建日志设置..."

    4) 输入描述名称

    5) 注意日志文件的位置 (或转到"日志文件"选项卡更改位置)

    6) 点击"添加对象"按钮,加入Process, Memory两个对象,选择"关闭"。

    7) 点击"添加计数器",弹出对话框,在性能对象下拉框中选择Process对象,选中 "所有计数器" 和 "所有实例" 单选按钮,选择Memory对象,选中 "所有计数器",选择"关闭"

    8) 点击 "确定"。

    1. 抓dump,具体命令如下,分析见【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分
      1. 下载Debugging Tools For Windows安装到比如,C:\debugger目录。

        http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

      2. 打开cmd.exe,切换到C:\debugger目录,键入命令行: cscript adplus.vbs –quiet –pn dllhost.exe –crash –o C:\dllhost_dmp抓DUMP文件的命令参数对各种具体问题会有一些不同,请参见【金蝶K3产品性能稳定性优化指导手册(辅助工具)COM+问题分类分析和处理方法】部分
      3. 对Windows Server 2003 请用下面的方法生成dump, 如果已经使用adplus来抓取dump,就打开命令行,切换到c:\debugger, 键入kill cdb.exe,即可杀掉debuggerdllhost.exe. 然后请如下图示enable Windows Server 2003COM DUMP抓取。

        设置后请restart组件进程。

        dump会自动生成在 %systemroot%\system32\com\dmp下,请保证dllhost运行的账户对这个目录有写入权限。

     

     

    5.3中间层COM+问题解答

     

    5.3.1 如何解决COM+/MTS 4097 错误事件?

    当COM/COM+应用程序发生违例时, 会在操作系统事件日志中产生4097事件。当发生这个错误时,可以按照下列步骤检查:
    (1)升级MDAC到最高版本
    (2)如果应用程序存取第三方数据库软件,确保客户端软件与COM+/MTS兼容
    (3)使用OleView.exe确认组件能够被实例化
    (4)升级操作系统到最新的Service Pack
    (5)如果程序由VB编写,在编译前, "Unattended Execution" 和"Retained in Memory"选项需要使能
    (6)服务器端使用最新的VB运行时文件
    (7)具有强健的出错处理程序

     

    5.3.2 不支持事务的组件是否能放入COM+应用程序中?

    事务处理和对象请求代理是COM+/MTS 编程模型的两个重要的组成部分。 不包含事务处理的组件仍可以利用分布式组件对象模型和COM+/MTS的进程级安全系统。这样, COM+/MTS 被用来管理对象实例和对象生命周期。

     

    5.3.3 如何在安装完COM+ Application Proxy之后, 修改远端服务器名?

    首先要安装Windows 2000 Service Pack 1 或以上版本。 然后在应用程序属性中选择Activation对话框,在里面填入远端服务器的IP地址或机器名。

     

    5.3.4 VB在COM+和MTS中创建对象有何异同点?

    在MTS中,必须在根对象中用ObjectContext.CreateInstance来创建子对象。 这种方法在COM+仍然可行, 但不是必需的。 COM+可以使用VB标准的CreateObject函数, 正确将事务转移到子对象。

     

    5.3.5 需要开启哪些端口以使MSMQ能够透过防火墙存取?

    只发消息: TCP 1801
    发消息和活动目录存取: TCP 1801, RPC 135, 2101
    收发消息和活动目录存取: TCP 1801, RPC 135, 2101, 2103, 2105。

     

    5.3.6 把COM+ 应用程序导出为Application Proxy后, 安装到Windows NT 或 Windows 98上时, 为什么CreateObject()会产生"class not registered"错误?

    在客户端用regedit观察, 发现组件CLSID并没有注册。 这个问题将在安装Windows 2000 SP3之后解决。

     

    5.3.7 如果COM+应用程序中的组件依赖于其他的组件或动态链接库,将COM+应用程序导出为Application Proxy并试图安装在Windows 2000上时, 会出现下列错误:Error registering COM+ Application. Contact your support personnel for more information。

    这个现象只发生于安装Application Proxy到Windows 2000客户端时。即使安装的是Application Proxy,Windows Installer也会试图对所依赖的动态链接库等调用LoadLibrary()。因此,如果LoadLibrary()找不到相应的动态链接库, 就会出现此错误。有下列方法可以解决此问题:
        1)先将所依赖的动态链接库拷贝到客户机的winnt\system32目录, 再安装Application Proxy。
        2)生成自己的安装程序,写入DCOM所需的注册表项目。

     

    5.3.8 做大的查询时COM+组件调用时间过长,此时若客户端用户人为结束进程,COM+还是一直在转,需要几分钟后COM+才能释放

    客户想强行关闭时,告诉用户还在运行,有一种通知机制,避免用户以为没有在执行而人为结束进程。

    若事务运行时间真的这么长,可以优化设计,改成多个小事务或采用异步查询(马上返回,用户查询状态:进行,完成)。

    可以通过com+admin的killComponent方法停止COM+组件,但不建议使用,会影响其他用户。

     

    5.3.9 如何优化进程间通讯(包与包间的调用),提高性能

    K/3有很多基础的COM+组件经常要被其他包的COM+组件调用,这样会影响系统性能,建议对一些经常调用的基础组件配置为Library application,即通过中间层包的分层解决,减少调用的性能损耗,但需要注意:

    (1)远层不能调用配置为Library application的COM+组件,需要再包多一层供远程调用

    (2)防止组件导致进程崩溃影响其他同一进程内的其他组件,要有完善的出错处理机制。

    也可以考虑在实现外部接口时,如果同时存在进程间通讯或包内的组件间调用,通过公共类的引用来实现,以便减少性能损失。另外,可以使用K/3性能监控工具查看各方法调用的占用时间。

     

    5.3.10 防火墙导致COM+不能访问的问题

    WIN2003启用防火墙后不能创建COM+组件,安装瑞星杀毒软件后不能连接COM+组件,这些都是因为防火墙禁止某些端口造成COM+不能访问,可以通过放开一些端口,然后修改REG使COM+使用这些端口即可。可以使用http://www.sysinternals.com上的TcpView工具查看相关端口。

     

    5.3.11 COM+包[安全属性]设置中如果设置身份验证级别为无会有什么影响,对性能提升有无帮助?

    COM+的身份验证级别改为无会提高性能,但其他用户若知道COM+接口可随意调用,存在安全性问题,建议按默认设置。

    有安全性级别认证需要域用户。

     

    5.3.12 如何更好地部署COM+,需要遵循什么原则

        COM+分包原则:按工作量分包,保证各个包工作量的均衡。

     

    5.3.13 VB组件能否支持对象池

    实现对象池组件需要实现IOBjectctrol接口并设置canbepooled为true,同时组件需要支持聚合,即组件释放时会聚合到COM+对象池中,并没有真正释放。因而VB组件实现不了。

     

    5.3.14 3G补偿的作用

    内存的一个设置,WIN默认每个进程的最大内存为4G:其中2G用户空间,2G核心空间。使用3G后,用户空间会涨到3G,而系统核心空间缩小到1G。主要为应用程序增加内存使用。

     

    5.3.15 在中间层MODULE能不能执行SQL

    可以,但是不能定义ADO或CONNECTION为全局变量,否则会成为性能瓶颈。任何COM对象一般都不建议声明成全局变量。COM+是无状态(Stateless)的。

     

    5.3.16 .Net调用自动COM+时,并发性能较差

    在.Net调用自动COM+时,在压力测试情况下发现30%的时间都消耗在建立COM+对象上,并发性能较差。

    .net由于是托管的代码,在调用COM+性能会比VB调用COM+慢很多。但是随着微软新操作系统的出现,到时候将会倒过来。

    1、由于采用自动事务的COM+都采用垃圾回收,每次调用时都会重新创建新的COM+对象,导致创建时间将会消耗大量性能,因此需要尽量减少COM+的调用。而HR现在采用的外围采用委托事务的方法将是很好的解决方案。

    2、对于仍然采用自动事务的COM+代码,建议采用COM+对象缓存池,具体使用案例由微软工程师提供。

    3、建议COM+组件要均衡配置,按工作量分包,保证各个包工作量的均衡。

     

    5.4中间层非COM+性能优化

     

    5.4.1 停止K/3系统相关服务

    1、若没有使用管理驾驶舱模块,请将中间层服务器上的Apache Tomcat服务停止。

    2、若没有使用人力资源系统(HR),请将中间层服务器上的HRJobProcess服务停止。方法同上。

    3、若没有使用远程传输系统(iMts),请将中间层服务器上的Kingdee iMTS Service服务和Kingdee iMTS Event Server停止,方法同上。

     

    5.4.2 域服务器、中间层服务器、数据库服务器分开部署

     

    1. 客户端性能问题

    6.1 客户端性能问题介绍

    客户端表现出来的性能问题,一般可以反映到数据库或中间层的优化上,最后没有办法才到代码级别的优化。

     

    6.1.1 某些客户端的速度比以往使用K/3慢一点

    客户反馈:

    某些客户端的速度比以往使用K/3慢一点

    处理分析:

    大多数是客户端的硬件配置可能偏低,而且使用了WIN98操作系统,建议客户适当升级客户端的硬件配置,使用win 2000 professional操作系统,或者建议客户把使用频繁的K/3客户端作较好的配置,在不增加硬件的情况下对已有的pc做调剂。同时,告诉客户K/3系统之所以可能比他们以前用的小系统慢,是因为功能的复杂性,如提供了并发控制的网络控制和严密的授权逻辑。重要的是能够满足客户的日常业务。

    硬件配置建议客户端CPU主频2G或以上,内存至少256兆(推荐512兆)

     

    6.1.2 某些局部功能速度太慢

    客户反馈:

    局部功能点速度很慢,很可能会引发整个系统的瘫痪,进而导致所有其它功能点都变得很慢,甚至出现死机(实际是得不到系统资源,处于长期的等待中)现象。这些比较慢的功能点一般包括大数据量的物料(商品)收发汇总表查询,期末结账,成本计算等功能

     

    典型示例:

    1. 计算类——期末结账,MRP运算,凭证生成,成本计算
    2. 查询类——报表(物料收发汇总表),序时簿
    3. 日常票据处理业务

       

      处理分析:

      对于上面谈到典型局部功能点慢的问题,首先寻求技术支持或者从技术支持网站查询相关补丁,若是一个通用的问题,可能已经有了相关的补丁。如果没有相关的补丁解决,请提交研发,这些与客户日常业务密切相关的操作,必须要能满足客户的要求。当然针对根据不同类别有不同处理建议。

      (1)对于计算类,如果不是日常功能,建议客户尽量不要安排在业务高峰期做,以免影响其它功能点;

      (2)对于查询类,建议客户根据自己需要设置查询过滤条件,避免不做任何过滤做大数据量的查询,从应用方式避免出现性能问题。

      (3)对于日常票据处理业务,特别是与客户日常业务密切相关的操作,如果没有相应的性能补丁,请迅速提交研发跟踪处理。

       

      6.1.3 客户端出现Automation 错误

      关于Automation错误的成因也是多方面的,最多的是支持软件如:WINDOWS文件、系统控件等,都有可能导致问题的出现。当然,K/3自身的问题也存在。Automation错误,是系统无法捕获的错误,根据以前遇到此问题的经验,通常有以下几种可能:

      1、客户端的MDAC程序出现问题,通过安装MDAC2.8来解决;

      2、服务器的MSDTC没有正常启动,或启动用户的权限有问题,请检查组件服务中的MSDTC并使用具有启动权限的用户来启动;

      3、客户端的分布式DCOM没有正常启动,请检查客户端的DCOM配置属性中是否选择上"在本机启用分布式COM"选项。

      4、 客户端或服务器中安装了相应的防火墙,截断了客户端与服务器的DCOM访问,比如XPSP2的内置防火墙设置、个人防火墙软件关闭了135和1024以上的端口,都会造成此问题。

      5、客户端或服务器安装某防病毒软件与K/3的DCOM访问存在冲突,如瑞星等。

      6、客户端的组件没有正常注册,请使用TS0026补丁工具进行注册,下载地址:

      <http://www.kingdee.com:8080/download/agentdown/tech/ts0026.rar>

      7、我们所遇到的多是在卸载其他软件后出现的(如用友的软件,等等),估计很可能是系统文件或公用文件受到损坏所致。所以也建议朋友们尽量保持系统文件的清洁,防止卸载文件导致错误。

       

      6.1.4 如何查看具体哪个组件存在性能问题

      可以通过K/3性能监控工具检测是哪个组件哪个方法存在性能问题,然后针对具体代码进行优化。

      工具使用说明:在局部客户端出现性能问题时,打开该客户端跟踪工具进行跟踪,将跟踪结果保存成.ktr文件传回研发中心进行分析(缓慢现象出现前后1分钟内的信息最有价值)。

       

      6.1.5 关于趋势防火墙与K/3的冲突

      当趋势防火墙升级到V6.5后,会不停的扫描K/3的主进程,导致K/3客户端越来越慢,以致感觉象死机。解决的方案就是把K/3的安装目录添加到趋势防火墙的例外列表中。如下图所示

      6.1.6 使用了严重影响K/3系统性能的系统选项

      功能和性能往往是矛盾的,有些系统选项能够从功能方面给客户带来方便,但是往往会造成严重的性能问题。所以要在功能和性能方面权衡,有时候可以说服客户不要使用一些严重影响性能的选项,其实只要让客户理解,大多数客户是可以接受的。

      1、工业系统中的序时簿显示关联标志

      在工业系统中如果选择序时簿显示关联标志会严重影响序时簿的查询速度,在大规模并发下还很有可能引发所有工业物流客户端的全面等待甚至死机。其实这个功能大多数客户并没有使用,甚至根本都不理解有何用途。所以建议在实施的时候直接关闭。

      2、商业系统中的自动填补断号

      在商业系统中如果选择单据自动填补断号,会严重影响单据的保存速度,而且数据量越大速度越慢,甚至引发死机,所以建议不要使用这个选项。

      相关案例以及解决方法:河北某客户反映零售单转换功能会造成阻塞、死锁。经分析发现,零售单转换的存储过程中取得单据编号的过程占了总时间的90%。并且存储过程涉及到商业的几个主要业务表的操作。由于这几个主要业务表长时间的锁定,造成了阻塞甚至死锁的出现。经分公司与客户协调,去掉填补断号选项并清楚了系统日志,系统达到良好的运行状态。

      3、大多数过滤条件中的包含未审核单据或包括未过帐凭证

      很多物流的报表有包含未审核单据的选项,很多财务的报表有包含未过帐的选项,这种选项都会严重影响报表的响应速度。建议尽量不要使用。

      4、减少序时薄显示字段提高性能

      现在K/3系统中序时薄显示的字段没有修改后缺省都是选择所有的字段,导致查询的时候关联表增多,数据量增大,从而导致成本增大,速度慢。

      解决方式:通过手工设置每次需要显示字段,或者使用下面的工具,设置只需要显示的字段。

      5、K/3系统选项建议设置

      1. 取消[显示所有下级明细数据]选项。

        请打开[物料],选择[查看]菜单下的[选项],取消[显示所有下级明细数据]的选项,需要每台客户端每用户都进行设置。上周五现场发现客户并没有设置,请请务必设置,这样每个客户端都减少一点压力就是对整体性能的提升。

         

      2. 序时簿查询慢
        1. 调整查询方式,尽量少用[包含]的查询条件

        2. 减少查询项,只显示需要的字段(可以保存成不同过滤方案)

        3. 如果可以的话,系统设置不使用"单据操作权限控制到操作员组"参数

      1. 选单慢

      选单调用序时簿,主要是上面序时簿查询慢的问题,出采取上面的措施外,请使用选项"选单时弹出过滤界面"[打开单据--"选项"菜单--选中"选单时弹出过滤界面"],这样在F7选单前可以先过滤你要的单据,减少数据量,提高性能。

      需要每台客户端每用户都进行设置。

      1. 修改系统设置选项

       

      6.1.7 其他

      1、如果使用客户端的消息平台功能,大量的消息读取SQL,可能引发阻塞,建议每个客户端关闭消息功能或将刷新时间减小。

       

      6.2.5 系统突然出现全面的死机现象

      1、问题描述:

      突然间所有客户端无法使用,大多数情况是客户端提示"调用程序忙,切换到…","正在调用中间层…"等提示,等了一段时间也没有反应,客户认为"死机"了。

      2、问题分析:

      (1)首先有可能网络中断或者不稳定,这种情况,一般客户端报告明显的网络错误;

      (2)如果网络畅通,有可能是网络中IP地址和计算机名称的不匹配。在这里,要注意的一种情况就是如果客户的中间层和数据库服务器是分开的,要确保这两台机器能够互通,这里常出现的一个问题就是ip地址和计算机名不匹配,也就是说,在hosts文件中记录的IP地址和计算机名称不匹配,假如数据库服务器记录了错误的信息,就会造成在客户端报一个"定义的应用程序和对象错误"等错误,但实际是中间层服务器可以访问数据库服务器,但是数据库服务器无法访问中间层服务器。这时要确保网络中IP地址和计算机名称的匹配,保证地址解析的正确性。

      (3)如果客户端提示"调用程序忙,切换到…","正在调用中间层…"等提示,客户可以不停的切换重试,或者强行中断客户端程序,分析:第一种原因是服务器硬件资源不足,注意观察数据库服务器的CPU表现,如果CPU资源长期达到40%以上,这表明CPU资源已经严重不足,如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源;第二种原因是数据库阻塞,此时数据库数服务器CPU耗用很低,但是整体性能很差。

      3、解决方法:

      (1)请先保证网络畅通和稳定;

      (2)确认hosts文件中的网络中IP地址和计算机名称的匹配,保证地址解析的正确性;

      (3)如果客户端提示"调用程序忙,切换到…","正在调用中间层…"等提示,如果通过自己观察,数据库服务器的CPU资源长期达到40%以上,这表明CPU资源已经严重不足,需要升级硬件。如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源;第二种原因是数据库阻塞,此时数据库数服务器CPU耗用很低,这种情况请参考:3.1.1.1 与CPU有关问题

      (4)如果是中间层COM+出现问题,请参考第3章中间层COM+问题进行处理。

      (5)如果客户端的操作系统是XP,在服务器上和客户端上,都把MaxUserPort改为65534,然后重新启动服务器和客户端。设置方式参见

      http://support.microsoft.com/kb/Q196271

       

      6.2.6 客户端出现"新事务不能登记到指定的事务处理器中"

      1、问题描述:

          数据库和中间层服务服务器为WINDOWS2003+SP1或者WINDOWS XP,使用K/3时,出现"新事务不能登记到指定的事务处理器中"的错误。

      2、问题分析:

          1)数据库和中间层服务器是否在同一网段;

          2)查看中间层组件属性"标识"采用的信任模式;

          

          3)查看MSDTC的安全配置情况,系统缺省安装时是"要求对双方进行验证"的

          

      3、解决方法:

          1)如果数据库服务器和中间层服务器不在同一个网段,在中间层的HOSTS文件中加上数据库服务器的IP和计算机名,数据库服务器的HOSTS文件中加上中间层服务器的IP和计算机名。HOSTS文件在%SystemRoot%\system32\drivers\etc下。如果操作系统是WINDWOS 2000也需同样处理。

          2)如果未采用信任注册的模式,需要修改"COM安全"页下的"编辑限制"

          

          增加Everyone 用户

      3)MSDTC的安全配置情况,修改为"不要求方进行验证",如果为HR系统需要选择"启用XA事务"

      附录1:SQL Server 的大内存管理

      1. 概述:

       

      标准的 32 位地址最多可映射 4 GB 内存。因此,32 位进程的标准地址空间限制为 4 GB。默认情况下,在 32 位 Microsoft Windows 操作系统上,将为操作系统保留 2 GB 空间,另外 2 GB 空间可由应用程序使用。如果在 Windows NT Enterprise Edition 或 Windows 2000 Advanced Server 的 Boot.ini 文件中指定 /3GB 开关,则操作系统将只保留 1 GB 的地址空间,而应用程序最多可使用 3 GB 的地址空间。

       

      AWE 是 Windows 的内存管理功能的一组扩展,它使应用程序能够使用的内存量超过通过标准 32 位寻址可使用的 2-3 GB 内存。AWE 允许应用程序获取物理内存,然后将非分页内存的视图动态映射到 32 位地址空间。虽然 32 位地址空间限制为 4 GB,但是非分页内存却可以远远大于 4 GB。这使需要大量内存的应用程序(如大型数据库系统)能使用的内存量远远大于 32 位地址空间所支持的内存量。

       

      2. 在操作系统上配置AWE:

       

      在操作系统上配置 AWE 之前,请考虑下列事项:

    • AWE 允许在 32 位体系结构上分配超过 4 GB 的物理内存。只有当可用物理内存大于用户模式的虚拟地址空间时,才应该使用 AWE。
    • 若要支持大于 4 GB 的物理内存,必须将 /pae 参数添加到 boot.ini 文件中并重新启动计算机。例如:

      multi(0)disk(0)rdisk(0)partition(2)\%systemroot%="Windows Server 2003 Datacenter Edition" /PAE

    • 如果计算机上的可用物理内存超过 16 GB,操作系统就需要 2 GB 的虚拟内存地址空间供系统使用,因此只能支持 2 GB 的用户模式虚拟地址空间。为了使操作系统能够使用超过 16 GB 的内存,应确保 boot.ini 文件中没有 /3gb 参数。如果存在该参数,操作系统就不能使用超过 16 GB 的物理内存。

     

    注意:

    "/PAE"参数应用于Boot.ini文件的时候,操作系统从双层线性地址转换转移到三层地址转换。额外的转换层提供对于超过4 GB的内存的访问。所以,如果"/3GB"交换机也随"/PAE"一同使用,那么操作系统可能因内存匮乏而求助于磁盘分页。这一步骤将对服务器性能产生负面影响。详细信息,请参阅"Windows 2000中的Intel物理寻址扩展(PAE"

    1总结如何根据可用的内存容量配置扩展内存设置。

     等于或小于4 GB

    4 GB16 GB

    大于16GB

    /3GB参数

    禁用/3GB

    禁用/3GB

      

    启用AWE

    启用AWE

      

    启用PAEBoot.ini

    启用PAEBoot.ini

     

    表2 总结各32位操作系统的最大物理内存支持能力

    操作系统

    最大内存支持能力

    Windows 2000 Advanced Server 

    8 GB 

    Windows 2000 Datacenter Server 

    32 GB 

    Windows Server 2003企业版(32位)

    32 GB 

    Windows Server 2003 Datacenter Server32位)

    64 GB 

     

     

    3. WIN2000  WIN2003 AWE支持的差异

     

    WIN2000 / SQL2000

    WIN2003 /SQL 2005

    必须运行于Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server

    必须运行于Enterprise版本以上

    物理内存必须大于3GB, 否则不管 awe enabled 的参数设置如何,SQL Server 都将以非 AWE 的模式运行

    理论上适用于所有内存配置

    • SQL Server实例不对所用的内存地址空间的容量进行动态管理
    • 如果可用物理内存大于 max server memory 选项的值,SQL Server 实例会锁定 max server memory 中指定的内存量。
    • 如果可用物理内存小于 max server memory 选项的值或如果尚未设置 max server memory 选项,SQL Server 实例只留下 256 兆字节 (MB),而锁定所有其余的可用内存

    可以动态地管理 AWE 映射内存(在 min server memory 和 max server memory 选项的约束内)以平衡 SQL Server 内存的使用从而满足总系统要求

     

    可以考虑设置 SQL Server 的 max server memory 以保证其他内存能用于运行在计算机上的其他应用程序

    分配之后,直到 SQL Server 关闭才会释放 AWE 映射内存. Microsoft 极力建议在每次启用 AWE 时设置 max server memory 选项的值,并建议考虑服务器上运行的其他应用程序的内存要求。

    因为可以动态地管理 AWE 映射内存,如果需要更少的资源,SQL Server 会将 AWE 映射内存返还给操作系统,以供其他进程或应用程序使用

    SQL Server AWE 将忽略 min server memory

    min server memory 设置有效

     

    4. SQL Server 启动AWE的配置:

     

    操作步骤:

    1. 将"锁定内存页"权限赋于运行SQL Server的帐户。
      gpedit.msc à计算机配置-->Windows 设置-->安全设置-->本地策略-->用户权利指派-->内存中锁定页面,添加运行SQL Server服务的用户。

    2. 网络数据吞吐量设置。如果在"网络连接"中选中了"最大化网络应用程序数据吞吐量"选项,则操作系统将在文件系统缓存中缓存应用程序的 I/O 页面,从而优先处理执行缓冲输入/输出 (I/O) 操作的应用程序。此选项可能会限制可用于 SQL Server 正常操作的内存。所以要改掉。
      本地连接属性 à文件及打印机共享 à属性,如果选中了"最大化网络应用程序数据吞吐量",请任选一个相应的其他选项。
      1. 配置  awe enabled  选项

        方案一: SQL2005提供在管理器的配置如下图所示:

       

      方案二使用存储过程sp_configure配置

      sp_configure 将 awe enabled 选项设置为 1,然后重新启动 SQL Server。
      sp_configure 'show advanced options', 1

    RECONFIGURE

    GO

    sp_configure 'awe enabled', 1

    RECONFIGURE

    GO

    sp_configure 'min server memory', 1024

    RECONFIGURE

    GO

    sp_configure 'max server memory', 6144

    RECONFIGURE

    GO

    3:如果启用 Address Windowing Extentions (AWE) 支持,则单个 SQL Server 2000 实例最多只能使用计算机上 50% 的物理内存。

     

    注意:该问题只发生在运行于基于 x86 或基于 x64 的计算机上的 32 位版本的 Microsoft SQL Server 2000 Service Pack 4 中。

     

    例如,如果您的计算机具有 16 GB RAM,且启用了 AWE,则 SQL Server 2000 的单个实例只能访问 8 GB RAM

    解决方案

    修复程序信息

    要获得此修复程序,请访问下面的 Microsoft 网站:

    http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=7C407047-3F1F-48B8-9E4C-DC32875E1961 (http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=7C407047-3F1F-48B8-9E4C-DC32875E1961)

    重要说明:对于基于 x64 和基于 x86 的计算机,只存在一个下载。该修复程序使用将确定平台和安装正确文件的安装程序技术。

    先决条件

    SQL Server 2000 Service Pack 4

    要获取 SQL Server 2000 Service Pack 4,请访问下面的 Microsoft 网站:

    http://www.microsoft.com/technet/prodtechnol/sql/2000/downloads/default.mspx(http://www.microsoft.com/technet/prodtechnol/sql/2000/downloads/default.mspx)

    重新启动信息

    应用此修复程序后,不必重新启动计算机。

    注册表信息

    不必更改注册表。

    修复程序文件信息

    此修复程序仅包含解决本文列出的问题所必需的文件。此修复程序不包含将产品完全更新到最新版本所必需的所有文件。

    此修复程序的英文版具有下表中列出的文件属性(或更新的文件属性)。这些文件的日期和时间按协调通用时间 (UTC) 列出。当您查看文件信息时,该时间将转换为当地时间。要了解UTC 与当地时间之间的时差,请使用"控制面板""日期和时间"工具中的"时区"选项卡。

    适用于基于 x86 计算机的 SQL Server 2000 32 位版本

    日期 时间 版本 大小 文件名 ----------------------------------------------------------- 14-May-2005 01:11 2000.80.2040.0 9,150,464 Sqlservr.exe

    适用于基于 x64 计算机的 SQL Server 2000 32 位版本

    日期 时间 版本 大小 文件名 平台 --------------------------------------------------------------------- 14-May-2005 01:11 2000.80.2040.0 9,150,464 Sqlservr.exe x86



    http://zbqlh.blog.163.com/blog/static/3638022201171511435685/

    展开全文
  • RPA技术可行性方案确认-辅助手册

    千次阅读 2019-04-02 16:06:58
    renjie.li做过AA操作SAP的项目,开发模式,RPA尽量少的操作,和快速的作业时间是提高RPA稳定性决定性因素 4 Office软件(Excel,word, outlook, powerpoint) VBA,C# com组件,宏录制 特别...

    如下为基于个人经验整理的流程RPA技术确认分享,仅供参考。也期待朋友们更好的建议。

    Rule No.1 没有不能做的RPA项目,只有不能承受做RPA成本的项目

    Rule No.2 切记,尽量不Touch的案例

    1扫描件,尤其是手写扫描件OCR不能识别扫描件,尤其是手写扫描件,RPA不能从文字识别上来自动化,仅能通过案件管理,连带录入速度,网络导致的图片显示速度,案件分配,跟踪等方面来做优化
    2无明确的处理逻辑如需要员工根据comment内容来判断如何处理的,RPA也不能操作,也只能通过抓取comment,通过分类,集中处理,分level处理,案件跟踪管理等方面来做优化

    Rule No.3 系统及网络环境很重要--以下需要的支持不包含图形对比技术和键盘操作技术

    1必须Windows操作系统对于电脑作业环境而言,非windows的操作系统,基本上不考虑,目前也没有员工在非windows环境作业
    2网络环境--正常作业环境皆大欢喜,最好的作业环境,只需要考虑其它相关因素,
    3网络环境--客户环境需要确认软件部署的相关权限,具体如下:
    VBA程序---基本上OK,需要简单测试
    C#程序--Framework3.5及以下版本基本上OK,3.5以上存在版本风险,需要测试,一般IT也能安装对应Framework版本
    Java程序--需要IT安装对应的支持软件
    AA,BP,UIPath,Pega, -- 需要客户同意购买开发软件后,IT方能安装
    4网络环境--Citrix-Remote环境即作业人员登录Citrix网站后,通过remote远程进入另一个系统环境,需要确认软件部署相关权限,具体如下:
    VBA程序---基本上OK,需要简单测试
    其它语言的程序,都需要客户同意后,IT才能有权限安装
    5网络环境--Citrix-VDI环境即作业人员登录Citrix网站后,进入客户APP网页,点击网页上对应的APP,在本地环境打开,通过图形传输技术,在本地操作后,在客户的服务器端执行,RPA运行前提是,需要将程序通过IT放到对应的Citrix环境, 在citrix网站显示此RPA APP后,点击,方能运行,同时,也需要满足如上4所需的软件运行支持 

    Rule No.4 心中有刀,方能有谱--CS/BS技术简单确认

    1CS-Spy++使用介绍使用方法介绍:https://blog.csdn.net/qq_25408423/article/details/80884114
    2BS-F12使用介绍使用方法介绍:https://www.cnblogs.com/zhuzhubaoya/p/9758648.html

    以上仅为简单粗糙的技术确认,实际项目确认前,仍需做简单DEMO确认

    Rule No.3 历史经验教训--常见软件及开发语言介绍

    1. 语言:Java因为涉及到环境部署问题,一般不推荐Java
                 RPA代表,AA,BP,Pega,UIPath等RPA集成开发工具 
    2. 稳定性:以Com组件操作Excel为特别稳定举例
    3. 难易度:以Com组件操作excel为简单举例
    4. 开发成本:以Com组件操作Excel位为1举例
    No软件名称推荐开发语言涉及技术稳定性难易度开发成本依赖项备注
    1SAP(包括桌面和网页版)- GUI权限打开VBA,C#SAP脚本录制特别稳定简单1.2需要开启SAP权限一般而言,测试系统开启recording权限,正式环境开启play back权限即可。但不开启recording功能也能开发,开发成本多50%
    2SAP(包括桌面和网页版)- 无GUI权限C#,RPA键盘鼠标模拟操作
    图形对比
    不稳定困难3.0需要环境干净、不被打扰做过AA操作SAP的项目,开发模式,RPA尽量少的操作,和快速的作业时间是提高RPA稳定性决定性因素
    3OracleC#,RPA键盘鼠标模拟操作
    图形对比
    不稳定困难3.0需要环境干净、不被打扰renjie.li做过AA操作SAP的项目,开发模式,RPA尽量少的操作,和快速的作业时间是提高RPA稳定性决定性因素
    4Office软件(Excel,word, outlook, powerpoint)VBA,C#com组件,宏录制特别稳定简单1-1.5 一般VBA开发,对应版本即可,C#开发com组件需要安装office软件,开源epplus,NPOI等操作不需要安装office
    5网页程序VBA,C#,RPAcom组件操作,稳定一般1.5-2 C#,RPA相对会比VBA执行速度更快,IE操作的1.5难点在于部分网页涉及到framkework,或者是extJS这种纯JS生成的前端,需要我们通过JS来操作
    6PDF-拆分,合并,水印等操作C#,RPAcom组件或开源组件稳定一般1.5 部分操作需要对应安装PDF软件
    7PDF-文字读取,OCR,原格式导出C#开源组件一般比较困难2.0 需要安装对应的OCR识别或原格式导出组件。识别不包含扫描件识别
    8AS400-IBM小型机--接口开发C#,VBAAS400接口技术稳定困难2.0 通过as400自生提供的接口操作,难点在于后期测试
    9as400-IBM小型机--接口不开发C#,RPA键盘鼠标模拟操作
    图形对比
    特别不稳定特别困难4.0需要环境干净、不被打扰尝试过开发,效果极其不佳,因为没有快捷键,只能通过tab键跳转,且不同的tab键的调转时间不确认,因为部分地方需要判断校验
    10LotusNotes--Mailvba,C#domino组件开发稳定一般1.5 lotusnotes提供的接口方法相对于outlook来说还是较少,部分功能不能直接实现
    11LotusNotes--ERPC#,RPA键盘鼠标模拟操作
    图形对比
    不稳定困难3.2需要环境干净、不被打扰lotusnotes的ERP一般常用于表单的申请,填写等炒作,会涉及到较多的滚动轴的操作
    12用友C#,RPA键盘鼠标模拟操作
    图形对比
    特别不稳定特别困难4.0需要环境干净、不被打扰几乎没有快捷键,操作困难
    13FoxmailC#,RPA键盘鼠标模拟操作
    图形对比
    不稳定困难3.2需要环境干净、不被打扰快捷键较多

     

     

    展开全文
  • 技术研发团队管理计划方案

    千次阅读 2021-03-17 17:23:17
    第四部分 2021目标和计划 序号 团队稳定性 团队技术实力 业务支撑能力 协同能力 1 激励员工,积极参与任务,并且从中获取成就感 共同配合,适当迎接有些小挑战的任务 支持顺利完成基本业务规划 协助部门达成基本...
  • Smart Campus智能制造园区网解决方案 此园区网解决方案优势1:安全易管 Secure 在不增加管理负担前提下,实现网络安全管控,让网络安全,真正好用、常用。 此园区网解决方案优势2:业务永续 Stable 从设备、线路、...
  • 转 ADAS视觉方案盘点上篇:摄像头、芯片和算法 ...
  • 连锁百货企业数据系统整理解决方案 ...自带权限配置,确保各个局向负责人只能看到自己区域内的经营情况,不会发生越权等情况,而总负责人能查看到所有局向负责人地区情况,保证公司内部经营发展稳定。    
  • 对于在员工人数在500-2000人的中等规模企业, IT基础架构的设计需要对性能、稳定性与扩展性兼顾考虑。IBM向您推荐包括IBM Power 740服务器、IBM Storwize V7000存储系统、SAN24B-4光纤交换机及系统软件在内的IT基础...
  • 第56章 未雨绸缪:工作稳定性与工作保障 来,跟我复述一遍: 根本就没有所谓 “ 工作保障 ”。根本就没有工作保障这回事情。即使在日本,在相当长一段时间里有传统:一旦你开始为一家公司工作,你就得为那家公司...
  • MiCO 的安全性、稳定性、可靠性及易用性这些特点也得到了广大使用 MiCO 的开发者的认可,并且这是目前全世界唯一一个在多种不同硬件平台上装机量超过 1000 万的物联网操作系统,可以说我们在 MiCO 的商用方面迈出了...
  • 上海蓝光集团公司信息化建设规划方案 目录 一、 集团信息化背景... 1 二、 集团信息化存在的问题... 2 三、 企业信息化整体规划的必要... 2 四、 集团信息化建设规划... 3 一、集团信息化背景1.1集团背景介绍...
  • 游龙科技公司凭借其强大的研发实力和在电子商务网络管理领域积累的丰富经验,推出游龙电子商务企业网络管理解决方案,能帮助电子商务企业大幅度提升网络和 系统管理的可用性、稳定性和可管理性,有效降低电子商务...
  • MES系统整体解决方案

    千次阅读 多人点赞 2020-07-24 16:40:19
    以柔性制造系统、敏捷制造等信息化改造为建设目标,利用传感技术、无线通信技术、计算机网络技术、智能数字化技术、物联网应用服务平台技术等多种现代化技术,打造基于物联网的综合示范平台,建立起一个示范应用...
  • VR党建解决方案

    千次阅读 2020-04-07 16:24:04
    近年来,国家愈发重视党建工作,积极推行党建新方法,...本方案能够提供全民党建体验,为社会一般群众提供基础参观体验。通过趣味虚拟现实互动吸引普通群众一起加入到党建文化的学习中,可以培训提升社会普通民...
  • 场景特点:工业生产线监控、1+1高可用 主要诉求: 减低成本:工控PC,稳定性优于普通PC,但价格昂贵(单台1.5万以上) 软件兼容:工控软件普遍运行在Windows XP, 2000,当硬件升级后,OS无法兼容 便捷运维:普遍存在...
  • 性能测试方案

    千次阅读 2018-11-29 10:57:25
    性能测试方案 文档资料信息 服务名称: XX.XXX.XX.27~46(XXX应用服务器) XXX.XXX.XX.123~24(XXX数据库) 项目经理: XX 文档版本号: 1.0 服务阶段: 项目实施 文档版本日期: 准备者: XX 准备日期: 审定者:...
  • 支持的数据量大、允许并发访问的用户多、接口多、基础图形区域...方案完全满电力系统安全稳定运行的总体要求 良好的兼容 是电力企业员工的得力助手 方便电力用户及时了解其所需要的内容 为领导提供辅助决策的强大工具
  • 外包员工为什么要往甲方员工发展

    万次阅读 2018-09-10 22:14:10
    目的: 1.在外包的过程中,接到过甲方的offer,薪资也不错,但是没有去,因为感到...1. 公积金缴纳比率,甲方员工比率一般都是按最高缴纳的,乙方员工缴纳比率按最低缴纳 2. 年终奖奖励,外包员工固定一个月,而...
  • XX智能停车场系统项目技术方案

    千次阅读 多人点赞 2019-09-30 09:41:55
    在考虑技术先进性和开放性的同时,还应从系统结构、技术措施、设备性能、系统管理、厂商技术支持及维修能力等方面着手,确保系统运行的可靠性和稳定性,达到最大的平均无故障时间。 安全性及保密性 在...
  • 该企业对成本非常敏感,找我们的合作伙伴上了一套订单管理系统,出于成本考虑,客户只选1个节点服务器,我们也告知客户1个节点服务器的风险,企业既有网络安全不足的风险等,但是在成本面前,安全的问题让路了。...
  • 网站建设方案

    千次阅读 2019-02-06 23:08:25
    网络凭借其卓越的互动与便捷的交流手段正成为最有发展潜力与前途的新兴媒体,成为众企业倍为关注的宣传热点。许多行业的知名企业已经通过网站建设来为自己的企业带来显著的宣传效果。企业网站为对外宣传、服务和...
  • 分布式定时任务解决方案

    千次阅读 2019-11-06 21:06:45
    分布式定时任务解决方案 一、背景 服务有定时任务,当服务部署到多个节点时,每个节点在同一个时间点都会执行相同的定时任务,需要做的是,让同一个时间点,每一个定时任务只在一个节点上执行,避免重复执行。 二、 ...
  • 图谱从客户视角出发,结合相关零信任标准和国内外零信任最佳实践,针对企业用户如何构建零信任体系,提供具体的能力清单和指导框架,汇聚成通用的零信任安全能力谱图,旨在帮助企业进行安全能力转型和升级。...
  • IT基础架构规划方案

    万次阅读 2018-08-31 16:49:53
    IT基础架构规划方案一(网络系统规划) 背景   某集团经过多年的经营,公司业务和规模在不断发展,公司管理层和IT部门也认识到通过信息化手段可以更好地支撑公司业务运营、提高企业生产和管理效率。同时随着新建...
  • Linux下LDAP统一认证解决方案

    千次阅读 2016-05-04 11:31:45
    企业内部需要认证的服务很多,员工需要记住很多的密码, 即使对这些服务进行相同的密码设置,也存在很大的安全隐患。笔者目前工作的企业就是如此,每一个新员工的到来管理员都要初始化很多密码,而这些密码都被设置...
  • 目前物联网行业产业链条长,导致分工协作的复杂加大,产业有待进一步的标准化。其次,物联网产品经理角色缺失,如何把消费者的诉求和厂商的诉求结合到一起,既要做到洞悉用户需求,又要借助物联网探索企业新的商业...
  • OA办公自动化系统设计方案

    千次阅读 2019-01-12 16:40:26
    笔迹是人的一种稳定的行为特征,具有一定的不变和独特。 (1). 笔记保留   公文管理嵌入技术,在公文处理过程中,支持意见批示等功能,领导可按照自己的习惯圈圈改改,完全符合传统的办公习惯,极大地减低了办公...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 37,723
精华内容 15,089
关键字:

员工稳定性方案