K3客户性能问题.docx
- 文档编号:24974866
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:43
- 大小:425.90KB
K3客户性能问题.docx
《K3客户性能问题.docx》由会员分享,可在线阅读,更多相关《K3客户性能问题.docx(43页珍藏版)》请在冰豆网上搜索。
K3客户性能问题
第1版
K/3客户性能问题
工作指导手册
第一章:
前言
本章主要描述K/3现在面临的性能问题的现状、手册的目的、阅读对象、手册的组织方式以及阅读方法
✡面临的问题
毋庸置疑,K/3现在已经成为国内最优秀的ERP软件,但是随着K/3产品的不断壮大,K/3产品的功能越来越强,在我们的产品不断实现更加强大功能的同时,另外一个问题却慢慢浮现出来,这个问题就是性能问题。
问题以前也存在,但是现在暴露了出来,显得极为突出,客户在抱怨,分支机构在抱怨,性能问题已经严重影响了公司和K/3的声誉。
从一种角度这也说明了K/3的优秀,K/3已经有了广大的客户群,同时客户在K/3系统运行了大规模的业务。
当然我们要勇敢正视这个问题,积极的去解决问题,从管理层到研发的每一个人现在都在重视和解决这个问题。
✡解决问题:
手册的目的
软件尤其是企业应用软件的性能问题,可以说是一个比较复杂的问题,软件本身,软件的运行环境,实施,客户应用方式都可能引发问题。
同时解决这个问题也绝不是能和修改一个BUG一样,一次性解决,这个问题会成为一个长久的问题,这不是说我们金蝶一次性做不好,我想任何软件公司都不可能做到。
当然研发会全力以赴,精益求精,做好软件的每一个细节,把K/3做到极致。
同时我们实施人员,服务人员也要了解性能问题,掌握一些技能,处理非软件本身的性能问题,只有大家一起努力,才能让客户满意,让每一个客户的K/3系统稳定高速的运行。
写这个手册的目的就是希望能够让广大实施服务人员以及客户更好的了解性能问题,掌握处理问题的策略,方法,在以后的工作中有效的解决和处理性能问题
对于性能问题,我想我们应该这样说:
我们一直在努力,我们也必须这么做。
记得以前看过一篇关于SAP开发管理的文章,其中SAP的一位开发管理人员说过一句话,原话已不记得,但是大概的意思是,他们的程序员为提高每一个功能点的速度每天在努力,这反映了SAP的产品尽善尽美的追求,同时我想这也说明性能问题不是一天就可以解决的。
归纳起来本手册的主要目的和作用有以下几点:
1,指导分支机构服务人员和客户处理现有性能问题
随着K/3客户群的壮大,客户应用规模的不断扩大,现在有性能问题的客户不断增加。
面对性能问题,分支机构和客户不知道如何下手处理,在半年多的客户支持中,通过与分支机构和客户的直接接触,发现:
有些分支机构不知道性能问题应该找那个角色来支持;即使找到了研发,也存在严重的沟通问题,在描述问题时很笼统;有些问题其实很容易解决,但是缺乏一定的知识和能力,也需要研发来解决;
希望能通过阅读此手册,让分支机构和客户对性能问题有一定的认识,具备一定的处理问题的能力,掌握与研发交流的技巧,有效的解决解决现有性能问题。
2,指导实施人员在实施中避免将来可能发生的性能问题
有些性能问题本身就是实施不当引起的,有些问题可以在实施中通过变通的方式加以避免,在实施的时候就应该对客户的数据量和并发做一定的预计,在做实施方案时考虑性能问题。
实施人员通过学习此手册希望能够在实施中对可能存在的性能问题有一定的指导意义。
在半年的客户支持中发现有些项目在实施阶段就有了性能问题,所以在实施中避免将来可能发生的性能问题有很重要的意义。
3,理解性能问题,提高工作能力
正如前面所说,性能问题将会是一个应用软件长久存在的问题,所以掌握一定有关性能问题的知识,深入理解性能问题,对提高工作能力有很大的帮助,更好的帮助顾客成功。
✡阅读对象
本手册的主要阅读对象是技术支持人员、实施人员、客户服务人员、有一定技术能力公司授权的客户系统管理员。
✡手册的组织和阅读方式
第一章就不用说了,前言对于所有的手册都差不多,一带而过就可以了。
第二章是对性能问题的一个概述,手册的重点不在像教课书咬文嚼字说明概念,主要是根据工作经验,说明了K/3客户性能问题的表现,影响K/3系统性能的主要因素,K/3性能问题的本质和分类。
在以往的工作中往往发现向客户和分支机构询问客户系统的表现是一件很困难的事,有的甚至就是说“慢“或者“死机“,就好像你告诉医生说我病了一样,研发人员从这样的描述中得到的信息很少,很难进一步定位和分析问题.通过学习本章希望对性能问题有一定的深入认识,便于以后在工作中的交流。
很多客户的性能问题并不是由于软件本身引起的,至少不是绝对的,理解影响系统性能的因素和从本质上认识性能问题的分类,可以就地解决一些性能问题。
对于此章请认真阅读,相信这些内容都很简单,但是系统实用的描述对于你还是有一定的用处。
第三章主要说明了对于性能问题的处理策略和处理流程,让所有相关人员理解性能问题处理策略和了解处理流程,确保我们知道如何有效的利用合理的流程和资源高效的解决问题,这些与技术无关,但是对于分支机构和客户来说了解这些策略和流程能提高工作的效率。
花点时间在这一章应该有好处。
第四章主要对一些常用的性能监测工具的使用做了说明,同时对如何分析性能问题作了描述,希望通过这一章的学习能掌握分析定位性能问题的方法,这是本手册的重点
里面的内容在手册中写了很多,但是实际很少,这就是技术手册的尴尬。
第五章讲述了对于各种性能问题的解决方法和策略,这里有技术和非技术的解决策略,希望对分支机构自力更生解决客户的性能问题和在与研发交流中有帮助。
第六章是一些技术方面的专题和系统关于性能方面的维护策略,这些问题可以让你更深刻的了解K/3系统,让你在客户那儿游刃有余。
✡一些关于本手册的说明
Ø由于此手册牵涉一些K/3在技术方面的细节,为了防止有些人用意不良,断章取义来攻击K/3和公司,请注意保密。
Ø本手册的是从研发人员的角度写的,目的是为了和分支机构一起解决客户的性能问题,但是可能存在偏颇,欢迎提供建议和意见,同时此手册不止是针对性能问题,对一些常见的非功能问题也作了描述。
Ø本手册是K/3总体设计组半年来处理客户性能问题的一些经验的总结,不是一个逻辑严密的体系,当然文字方面的功底可能也不是太好(请谅解程序员的作文水平,写此手册的时候才发现自己WORD的操作技能太差),我们努力写的更好,但是能力有限,欢迎指正。
在写此手册的时候我最痛苦的就是如何组织内容的结构,就像一个医生无法把自己的治病经验一下子描述清楚,所以很多问题都翻来覆去的出现在不同的章节,我的原则就是宁可罗嗦,也要清楚,也许这样反而不清楚。
第二章:
性能问题概述
本章主要描述了什么是性能问题、性能问题的表面现象、影响K/3系统性能的因素、本质上性能问题的分类
什么是性能问题:
在这儿不想从其它的书上抄一段文字来定义什么是性能问题。
当客户突然对你说:
”我们的K/3死机了”、“你们K/3的销售出库单保存太慢了”,“老是出现中间层切换重试”、”我们不能出库了”、“我们的客户在排队”……这就是性能问题。
当出现这些问题的时候,你可能告诉客户重启服务器,一段时间后客户已经对此厌烦,如果不及时处理,我们K/3的声誉和公司的声誉在客户那儿可能就直线下降,作为服务人员和实施人员的你很着急,这些情况我都遇到过,这时候我们首先作的就是具体的了解问题,向客户询问系统的情况,这儿存在一个在软件行业普遍存在的问题那就是对问题的描述和沟通(告诉别人的和要告诉别人的误差往往很大),所以你要引导客户,询问具体的情况,当然如果你在现场那更好,即使你在现场,你如果不能处理,向研发寻求支持,你也要能够和研发很好的沟通,否则研发人员就只能到现场去处理,浪费不必要的资源。
你可以从客户那儿得到对性能问题的表面现象的描述,但是你要尽可能按照下面的分类引导客户描述问题,这样你能更快得到更准确的信息。
但是真正的问题隐藏在背后,我们需要把了解到的表面现象转换为问题的本质。
同时要了解影响性能问题几种主要因素,这些都有助于迅速的定位和分析问题。
第一节.客户性能问题的表面现象:
当客户出现性能问题时,他们给你的描述可能是五花八门,有的能够描述的很清楚,有的就说得很笼统,这取决于客户系统管理员对系统的了解和能力,但是你要引导客户和你的沟通,尽量得到一个比较准确的描述。
根据客户对现象的描述可以得到一些初步的解决方案。
以下是K/3总体设计组半年来从客户支持中的到一些现象的汇总和归纳,在每个现象中会给出一些初步的解决方法,当那些初步的解决方法无法解决时需要深入了解客户的情况,做进一步的分析,然后给出解决方案,这会在后面的章节中给出进一步的说明。
所有现象没法做一个逻辑严密按照某一个分类依据的完全分类,各种表象可能是交错的重叠的,希望我们能在后续的版本中做进一步的分类。
一.某些局部功能速度太慢,不能满足日常的业务要求
客户如果能给出这样的描述是最好的,证明他已经很明确的定位到问题的所在。
这些慢的功能点大多数是一些查询和计算功能,如大数据量的物料(商品)收发汇总表查询,期末结账,成本计算等功能。
这些慢的功能由于使用过多的系统资源,很可能会引发整个系统的瘫痪,导致所有其它功能点都变得很慢,甚至出现死机(实际是得不到系统资源,处于长期的等待中)现象。
对于大数据量的报表或序时簿查询,你要询问客户是否可以作适当的过滤,这种查询和大多数的计算型功能是否可以不在业务高峰期做,如果能够和客户达成一致的意见,从应用方式避免是最好的,有些客户尤其是不熟练的客户经常会不做任何过滤做大数据量的查询。
有些查询可能已经做过优化,可能在现有架构下已经没有办法做更进一步的优化,所以需要和客户沟通,从应用方式避免。
你也可以寻求技术支持或者从技术支持网站查询相关补丁,如果是一个通用的问题,可能已经有了相关的补丁,这样的话你打上相关补丁可能就很容易的解决了问题。
你要想到K/3数以万计的客户,你的问题可能在其他客户那儿早就发现了,早已经获得解决。
对于期末结账、成本计算、MRP运算等功能、大多数的查询功能类的性能问题,大部分问题都可以获得补丁或升级软件来解决,如果确实不能解决,或者不能说服客户改变使用方式,从客户的角度也确实需要更快的速度才能满足业务要求,应该迅速提交研发部门,研发来研究是否可以做优化。
这样的每次优化,一点一滴的优化,最终就会使K/3全面优化。
也许你要说研发为何不能未卜先知,我们已经作了很多,我们也一直在努力,但是客户的情况千差万别。
如果这些慢的功能点是票据和凭证的日常业务操作如保存,审核等,如果没有相关的补丁解决,应该迅速提交研发,这些与客户日常业务密切相关的操作,没有任何理由,必须要能满足客户的要求。
二.系统突然出现全面的死机现象
经常听到客户说他们的系统死机了,或许有些分支机构的人说是死锁了,关于这些说法后面的含义可能差别很大。
当听到这种说法时需要进一步的询问详细情况。
最好处理的情况,最简单的情况是网络问题,当然你首先要肯定网络的畅通,不过出现这种问题时一般会在客户端报告明显的网络错误。
在这儿要注意的一种情况就是如果客户的中间层和数据库服务器是分开的,要确保这两台机器能够互通,这里常出现的一个问题就是ip地址和计算机名不匹配,也就是说,在hosts文件中记录的IP地址和计算机名称不匹配,假如数据库服务器记录了错误的信息,就会造成在客户端报一个“定义的应用程序和对象错误“等错误,但实际是中间层服务器可以访问数据库服务器,但是数据库服务器无法访问中间层服务器。
在这时候要确保网络中IP地址和计算机名称的匹配,保证地址解析的正确性。
但是大多数情况是客户端提示“调用程序忙,切换到…”,“正在调用中间层…”等提示,这些提示本质上都是一样,或许你等一段时间(几分钟)系统又开始响应,这种情况就是和下面第三种情况描述的一样,或许你等了几十分钟也没有反应,实际上你不可能等那么长的时间,这时候你认为是死机了,要么你不停的切换重试,可能认为鼠标点的越快,系统会反应的更快(这不是笑话,在有一家客户那儿他们把回车键用重物压着,达到不停的切换重试的效果),要么你强行中断客户端程序。
之所以分为两种情况,是由于引发这两种情况的原因有些差异。
引发这些情况的原因主要有两种,第一种原因是服务器硬件资源不足,如果中间层和数据库部署在同一台服务器,或者数据库服务器配置偏低,这就会导致在数据量大和并发多的情况下系统资源不足,这时候你可以看看服务器的CPU表现,如果CPU资源长期达到40%以上,这表明CPU资源已经严重不足,如果CPU达到100%,则是某一个功能独占了数据库服务器CPU资源;第二种原因是数据库阻塞,此时数据库数服务器CPU耗用很低,这种情况下可能有些客户端的有些功能模块还可以用。
对于第一种情况,当然软件的原因不能完全排除,但是这时候硬件的提升可能是必要的,如果是CPU达到100%的情况就需要优化那个独占CPU的功能点。
对于第二种情况,软件的原因是主要的,需要从软件本身的改进来避免。
第一种原因可能更多引发第三种情况,第二种原因可能更多的引发所谓的死机。
看了上面的描述你就会觉得此手册在内容组织方面显得有些混乱,我也感觉到有些没有条理,但是有些不好做,努力吧。
三.系统所有功能频繁出现等待现象,且等待时间较长
在上面一种现象中已经对这种现象作了一些说明,其实之所以单独来描述,主要是说明此种现象下需要提升硬件资源。
如果系统所有功能点都很慢,且频繁出现,但是每次都在几分钟之内能够响应,这时候如果数据库服务器的CPU耗用持高不下(长期在40%)以上,这就说明数据库服务器的硬件资源尤其是CPU资源严重不足。
简单分析原因,这可能是数据量大,并发较高。
不过提升硬件对客户可能是一件很难接受的事,所以最好在实施中能够有预见性的避免。
在以后的章节中会对硬件的配置给出一个经验性的推荐.当然这种现象的发生软件也需要改进,但是改进的效果可能不是太明显,改进的难度可能比较大,改进的周期可能会比较长。
四.有规律的在某个时段系统速度变慢
大多数是月末,或者某段业务高峰期。
在发生问题的时段可能会是某一个计算型功能如结账操作耗用系统资源太严重,或者是并发程度高引发系统资源不足.实际上是上述三种现象由于用户业务的特点没有在平时暴露出来。
之所以分开来说,是让你不要这种时段特性所蒙蔽.在这种情况下也比较难处理,客户认为平时都很好,可能拒绝提升硬件等建议.这时候建议客户改变使用方式也很困难,但是有时候从成程序角度也不是太好优化。
此时我们只有这几方面的工作都努力了。
五.某些客户端功能好像比正常的速度慢一点
有时候你会感觉到某些客户端的速度可能比你以往使用K/3慢一点,这种情况下大多数是客户端的硬件配置可能偏低,而且使用了WIN98操作系统,当然我们尽量会优化客户端代码,但是这种优化确实比较难做,所以有时候需要向客户解释,最好是能够成功说服客户适当升级客户端的硬件。
这种情况下,有时候客户会拿其原先使用的系统的响应速度和K/3比较,这时候一个解释的理由就是功能和性能是有矛盾的,K/3的功能相对一般的软件要复杂,这就会适当的降低性能。
第二节.影响系统运行性能的主要因素:
系统运行性能表现不只是软件的问题,很多因素都影响系统的速度。
最主要的因素有以下几种,当然这只是我们认为最重要的,不要从理论和逻辑的角度去考究它。
对这些因素的分析,主要是让你对系统性能问题有全面的认识,曾经有分支机构的人对我说“我们以前怎么就没考虑过硬件问题呢”。
所以有必要对这些因素做些说明,让我们的实施人员和服务人员有时候更好的了解问题和处理问题。
一.数据量
一般来说,所有数据库应用软件的瓶颈都在数据库,数据量的大小对系统的运行速度有直接的影响。
账套大小是衡量数据量大小的一个简单实用的标准,但是注意要看数据库数据文件的大小,有时候SQL-SERVER日志会很大(关于这个问题在后面的常见问题中会作分析),但是数据文件并不大。
有时候数据文件本身的大小也不能真实反映数据量的大小,如果一个表没有聚集索引,SQL-SERVER有时候会使这个表占用很大的磁盘空间,这个关于SQL-SERVER的问题也会在后面的得常见问题中做分析。
在数据量的估计方面,有一些关键的基础资料和业务数据对整个账套的数据量可以作出一个大概的估计。
基础资料中财务部分的科目,物流中的物料可以作为衡量数据量的一个主要依据,同时财务中凭证的多少,物流中仓库单据的多少可以用来衡量业务规模。
当然有些特殊的客户由于其行业和业务的个性太强,可能需要其他的业务数据来衡量其业务数据规模
同样的功能,数据量越大其性能肯定会有所下降。
我们的实施人员应该在实施准备阶段对用户未来的业务有一个估计,对用户数据量的估计可以作为配置服务器硬件的一个依据。
数据量对数据库服务器的内存配置有直接的影响,从经验的数字来说最好是物理内存要大于账套的数据文件,如果账套数据文件小于1G,应该配置至少1G内存,如果账套数据文件大于1G,物理内存应该是数据文件的向上取整,例如账套数据文件为2.4G,那末应该配置至少3G内存。
对于高于3G内存的配置,SQL-SERVER如果要是用超过2G的内存需要一些其它的配置,这在后面的常见问题会专题论述。
数据量对查询功能的性能有显著影响,这时候从应用方式方面要调整,尽可能少使用查询功能,在查询的过滤条件中尽可能使用严格的过滤条件。
同时如果你具备一些关于数据库索引方面的知识,可以适当的通过索引来优化性能。
有时候结转新账套也是一个解决数据累计量太大的手段,这需要实施中有良好的计划。
研发一直和继续在大数据量应用方面研究和提升K/3的性能。
二.并发数
客户端的并发数量也是影响系统性能的一个主要因素,这不需要做太多的说明。
客户端的并发数有时候是一个模糊的概念,这里要注意区分客户购买的模块数量和客户实际同时使用的客户端的并发数量,有的客户可能购买了100个客户端,但是可能只有大概20个处于同时使用的状态,有的客户虽然购买了30个客户端,但是同时都在不停的使用。
我们应该以同时使用的客户端作为依据。
另一个值得注意的问题就是客户可能日常只有少量的客户端使用,但是在某个业务高峰期有大量客户端同时使用,最好是使用在业务高峰期的同时使用的客户端作为并发数量的依据。
一般来说,和数据量一样,在实施中应该对客户端的并发数做一个预估。
客户端并发数对硬件配置的影响最大。
经验的结论,一般来说都应该使用专业的服务器,如果同时并发客户端超过20个就应该分离中间层和数据库服务器,对于中间层服务器保持每20个并发1个CPU,对于数据库服务器保持每10个客户端一个CPU.这些经验数字中的并发数量指同时不停使用的客户端的数量。
并发量主要影响服务器CPU个数的配置。
对于并发量大引发的性能问题,可以考虑是否能把一些大数量的查询和计算功能放在非业务高峰期使用。
三.硬件配置和软件系统配置
系统的规模不同,要求的硬件配置也不同,硬件配置对性能问题有直接的影响这不用多说。
在硬件配置方面特别需要强调的是实施环节,一定要对客户的未来业务量有一定的预估,给出合理的硬件配置方案。
在硬件配置的建议方面在上述两个问题中也结合数据量和并发数做了一定的说明。
数据库服务器建议一定要刚开始就配置的比较高,且可以通过增加CPU和内存来升级,这样做得理由,第一,数据库是系统的瓶颈所在,第二,由于同一个账套无法分到多台服务器上,同时数据库也没有可以进行负载均衡的集群方案(SQL-SERVER的集群都是为了提高可靠性),也就是说无法通过增加机器的个数来提升性能。
对于数据库服务器的CPU和内存配置建议请看数据量和并发因素中的经验性结论。
对于内存指的是物理内存而非虚拟内存
对于中间层服务器来说,内存的配置不是太重要,有512M内存都可以,对于CPU个数的要求可以参照在数据量和并发数中的经验性结论。
由于中间层的可扩展性,可以通过增加机器的个数来均衡负载,所以如果客户对系统投资预算不足的情况下可以不需要配置太好的中间层服务器。
以后可以逐步扩展,实际上有512M内存的PC都可以做中间层服务器,可以通过增加机器来扩充。
当然如果客户预算充足的情况下还是尽可能采用专业服务器
对于服务器的CPU有一个观点必须要说明那就是“1+1>2“,这个公式的意思是两个1G的CPU表现出来的性能远远大于一个2GCPU的性能,所以CPU的个数对服务器很重要
对于数据库服务器的操作系统最好使用WIN2000ADVANCESERVER,实际上我是说的含蓄,我实际上是想说必须使用,当然如果你使用DATACENTER那肯定更好。
同时SQL-SERVER最好使用2000企业版,记住是企业版。
由于K/3为了界面的美观和易用性等因素,导致对客户端硬件的配置要求相对要高一些,在配置差点的客户端性能表现要差些,我们会在后续版本中持续改进,但是由于客户端硬件配置差引发的性能问题往往很难改进,改进的效果也不是太明显。
这样的问题除非客户对性能要求很高,一般不会提出问题。
当然如果现在采购的机器,肯定不会有太多的问题,但是如果客户使用原来采购的机器,那就不一样了。
在实施中适当注意这个问题,有些情况下可以建议客户把好点的机器用作K/3的常用业务操作。
对客户端的操作系统建议使用WIN2000PROFESSIONAL,不要使用WIN98,WINDOWSME等。
从使用方式方面建议客户不要在使用K/3时打开OFFICE系列软件。
对于硬件配置尽可能在实施时防患于未然,否则如果在使用过程中出现问题时再提议客户升级硬件,可能会受到客户的抵制。
四.二次开发
在这里绝对不是说二次开发做得不好,由于二次开发的周期短,可能难免会有些疏忽,或者是对性能问题没有重视,二次开发功能有时候对系统资源尤其是数据库资源的耗用比较严重,导致系统出现阻塞,系统性能显著下降,在这里提出这个问题,就是希望二次开发人员在做二次开发时注意性能问题。
对于大多数二次开发做的报表或查询建议数据库事务隔离级别使用ReadUnCommitted,具体的原因和技术细节请察看SQL-SERVER的帮助中关于事务隔离级别的说明。
五.数据授权
启用数据授权会使系统的性能显著下降。
在V10.2中会对数据授权做彻底改进。
对于现有客户。
我们的策略是通过调整使用方式来缓和,在数据授权时不要使用上级组权限检查选项,这样可以在很大程度上提高性能,同时建议客户按照单个用户做数据授权,不要在用户组做数据授权,客户如果接受此建议,可以通过补丁方式提高速度。
这些调整方式都可能导致授权工作量很大,可以通过手工修改数据库来提高效率。
第三节.客户性能问题的本质分类:
客户反馈的性能问题和客户现场表现的性能问题,可能是五花八门。
但是从本质上来说,可以分为两大类,K/3软件问题和非K/3软件问题。
这种大的分类也不是绝对的,有时候多种问题混在一起,互相影响,很难区分。
从本质上的分类有利于定位问题,发现问题,发现问题是解决问题的前提.每一大类又可以细分,问题的分类可以帮助你多种角度考虑和分析问题。
一.非K/3软件问题
有些性能问题,不是由于K/3系统软件本身绝对引起的。
这些问题大多是K/3系统的运行环境问题,还有些是应用和实施问题。
当然这不是说绝对的与我们的软件无关,而是说为了让K/3更好的运行,这些问题应该被解决和避免。
这些问题可以分为以下几种。
当你遇到性能问题时,或者在实施中为将来的性能问题作准备时,应该首先尽量避免和解决以下问题。
因为这些问题不是我们软件的改进可以解决的。
这些问题和前面讲的影响性能问题的因素有些是相同的。
一)网络问题
如果出现有些客户端不能操作,并且明显的报错,与网络相关的错误,应该首先检查网络是否畅通,如果出现所有客户端都无法操作,要检查中间层和数据库服务器是否互通,并且两台服务器的IP地址和计算机名是否正确。
这里要说的一个问题是关于网络带宽,从目前的局域网来说,最少也有10M带宽,这样的带宽运行K/3应该没有问题,所以在局域网中的K/3系统,不要过多的怀疑网络带宽的问题。
在局域网中需要关注的是网络的畅通和网络中地址解析的正确性。
关于终端和WEB方面的网络问题,在此不予说明。
这里还需要说明的是关于客户端和中间层不在同一域的问题,最好是配置客户端和中间层在同一域中,如果无法配置在同一域中。
可以修改组件服务中COM+
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- K3 客户 性能 问题