SCM与ERP，这两个时髦名词背后，到底有何不同？

从20世纪60年代起，企业就开始了管理信息化的应用，从MRP到ERP，逐步地实现了对采购、库存、生产、销售、财务和人力资源等业务的管理， 使其内部业务流程和处理实现了自动化，为企业内部纵向一体化管理创造了不可磨灭的功绩。但是，在经济全球化蓬勃发展的今天，ERP在供应链的跨企业横向一体化管理方面显得力不从心。因此，全球500强企业在经过若干年的ERP应用后又纷纷引入了SCM（供应链管理）。

那么，ERP与SCM到底有什么区别？

一、在理论模型和方法上：SCM Vs ERP    

多年来，人们一直在坚持不懈地将数学规划等方法用于企业安排计划和管理上，渐渐形成了MRP法和数学规划法这两种主要的计划编制方法，后者由于受到如建模困难、运算量大等客观条件的限制，发展比较迟缓，而MRP法则由于省略了一些实际存在、但又难以求解的因素，变得简单易算，获得了较好的成效和发展。但是，人们逐渐发现那些因素往往是不容忽视的，必须加以重视，加之计算机计算速度的飞速发展使得采用数学规划方法不再困难，人们开始以常驻计算机内存的方式采用数学规划方法编制计划，这种全新的计划方法就是SCM的的开端，人们发现这种方法无论在计划的准确性方面，还是编制速度方面以及优化性方面等都远远优于被ERP沿用至今的MRP法。  

SCM采用了多种数学解析的优化模型和规则，是基于约束理论进行计划的，它考虑了物料、设备、人员、场所、时间和技术等所有的约束因素，对不同的目标可以通过不同的规制进行优化。它具有更坚实的理论基础和更科学的指导方法，作出的计划更具优化性、准确性和可行性。此外，SCM借助于各种模型和算法，能够对企业和供应链进行决策和优化。而ERP的理论模型过于简单和陈旧，它的计划模型和提前期的计算方法等都无法模拟今日复杂多变的业务过程。例如，它作计划的前提假设是企业具有无限的物料和能力，计划模型是无约束的；又如，ERP一般采用简单的线性公式T=A+BX计算产品的提前期，但每种物品每一次的采购提前期都可能存在较大差别，无法用这种简单公式来准确计算；而且由于缺少理论模型的支持，无法实现业务优化和科学决策。

二、在管理范围上：SCM Vs ERP

ERP是面向企业内部的管理，只能对其内部资源进行管理。然而，单靠企业内部的业务改进所获得的收效已变得越来越有限。随着经济全球化和市场竞争加剧，形成了产品定制化生产和交货期不断缩短的趋势，企业面对越来越复杂多变的经营环境，逐渐将管理焦点转移到超越企业之外的供应链管理和上下游的业务协同上，以适应环境的变化。而ERP在管理范围和功能上都不具备协调多个企业间资源的能力，无法实现供应链上信息的共享。然而，SCM则能够满足供应链横向一体化运作的要求，它帮助企业更好地参与新环境的竞争，在考虑了资源约束、优化和决策的技术支持下，有效利用和整合外部资源，与上下游企业建立合作伙伴关系以实现信息共享和业务集成、共同协调制定兼顾各方利益的联合计划，实现协同运作和供应链整体价值的最大化。 

SCM另一个优于ERP之处是它能够模拟和改善财务指标，特别是收入、成本和资产利用率指标。它不仅仅是简单地降低成本，而是利用不同的方式来满足市场和客户的需求，使企业乃至整个供应链实现盈利最大化，它通过改善收益表和资产负债表中关键因素来实现股东权益最大化。因此，ERP仅仅是实现了单个的企业价值最大化，而SCM则实现了整个供应链乃至社会价值最大化。

三、在编制计划上：SCM Vs ERP             

首先，SCM是基于某些规则进行计划的。它是通过不同的规则对不同业务进行计划，并可对单一目标和多目标进行优化的计划，它扩大了计划范围。而ERP则难以实现优化；其次，它的计划是并发的、计划时段是连续的，它综合、完整地考虑了约束问题，生成的提前期是弹性的，计划的能见度可达全球范围。它可以对供应链和企业的各项业务进行计划，一次性地考虑业务流程的纵向和横向的协调，无需一个个地依次制定计划。而ERP编制计划是按顺序进行的、计划时段是离散的，生成的提前期是固定的，仅面向某一功能的计划，计划的能见度只限于局部，几乎不考虑约束；再次，SCM的计划覆盖了所有的业务，计划模型可以做得足够的详细，覆盖了长、中、短周期，可以实现倒排、顺排和中间排，其精细程度可从年、月、周一直到天、小时和分钟。同时，SCM能够随时根据生产和客户需求的变化进行重排计划，量化地反映甚至超前于市场的需求，例如变化的资源和约束，用户的优先权等。它可以实现一个可持续转变的流程，使得重排计划能够对每一次意外变化进行随时处理。而ERP有时按天做计划都很困难，更无法精确到小时和分钟，也很难做到快速地重排计划；最后，在生成计划后，SCM可以根据“评价计划成本”标准评价计划成本，并与企业的财务指标进行对比和衡量，进一步核实其可行性。但ERP无法对做出的计划成本进行评价。

四、在业务管理上：SCM Vs ERP

SCM在业务管理上具有比ERP更好、更多的功能。首先，SCM具有极强的实时承诺性，它的承诺标准能为客户提供准确的交货日期。虽然ERP的可用量检查ATP也具有某种承诺能力，但仅是建立在对现有库存检查的基础上，而SCM在ATP的基础上，还通过对需求承诺能力和对订单承诺能力的检查、扩展的生产可用性检查和对获利能力的检查等功能，对包括供应商和服务商在内的资源进行动态地分析和物理检查，以对客户作出准确的交货承诺，并在商谈订单的第一时间就能确定该订单是否能够获利，是否需要接受订单；第二，SCM能对供应链上的资源进行优化调配，将供应链上的某种稀缺资源预先分派给具有较高优先级别的客户或渠道的需求，以避免其它客户或渠道与它们争夺该资源，实现了资源平衡和优化利用。而ERP不具备这种能力；第三，SCM的计划范围扩展到了企业之外，能生成跨企业的协同计划，实时了解伙伴们的业务变化情况，及时进行重排计划，保持高度的灵活性和预见性，以快速响应市场需求。而ERP则无法满足这种需求；第四，SCM可以动态计算提前期，它的提前期标准提供了一个优于ERP的特性，ERP逻辑使用固定的提前期进行计划，这对整个供应链运行具有若干负面的影响；第五，SCM可以对供应链的需求、供给和约束进行监控，实时地将这三者进行比较，一旦出现不匹配时立刻发出预警信号，并执行智能的逻辑操作使它们重新恢复平衡，重新达到同步，这也是ERP无法实现的；最后，与SCM相比，ERP缺少优化和决策支持、业务伙伴关系管理、上下游业务协同管理和物流管理等功能，无法实现供应链上企业间的协同运作和更有效地利用企业外部的资源。

因此，ERP只能告诉你怎样去执行，而SCM则能帮助你决定怎样去执行才能作出改善，如何通过基于利润考虑的优化的总价值？如何确定优化生产工序序列以最小化工序、设备整合和设置？供应商和客户的位置变化将怎样影响运输成本？增加或取消一个配送中心，或越库作业将如何影响运输成本？如何基于最低的运输成本来决定对多余的维修部件进行最佳的重新配置等，这些都是ERP无法解答、而必须让位给SCM来解决的。

五、在运行速度上：SCM Vs ERP

SCM采用了第4代常驻内存运行的技术，将所有相关的数据脱离主服务器读入内存，避免频繁访问硬盘，这比基于MRP法的ERP运算速度要快几百倍，具有更快的运送与决策速度和响应能力，以尽快捕捉和把握市场商机，先人一筹抢占市场。同时，可视化的GUI技术支持先进的供应链导航功能，为企业提供可视的户图化形界面，将实际的供应链网络结构、供需关系和连接路线等实况尽显眼前，更是优与ERP系统，使管理人员能更容易地作出决策，实现盈利。

六、在事务处理上：SCM Vs ERP

虽然SCM具有众多的计划、优化和决策功能，但它却不具备某些事务处理和数据维护功能，例如，货物的接收、盘点与出库，工单/采购单发放、发票/文挡管理、会计管理，对项目主文件/BOM、列表进行维护等。而ERP则可以完成这些功能。目前，有些SCM系统也扩展了它的功能，增加了供应链执行系统SCE，由该系统来完成上述工作。

综上所述，SCM更能满足新的经济环境和市场竞争需求，能为企业和整个供应链提供比ERP更多、更好地管理功能和手段去应付复杂多变的竞争环境，实现供应链上的共赢。这也正是为什么全球500强企业在经过若干年的ERP应用后又纷纷引入了SCM的原因。(amt)

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

:http://www.evget.com/article/read_1722.aspx

Spring是一个强有力的java程序框架，其被广泛应用于java的程序中。它用POJO提供了企业级服务。Spring利用依赖注入可以获得简单而有效的测试能力。Spring beans，依赖关系，以及服务所需要的bean都将在配置文件中予以描述，配置文件一般采用XML格式。然而XML配置文件冗长而不易使用，在你进行一个使用了大量bean的大项目中它将变得难以阅读和控制。

   在这篇文章中我将给你展示12种的有关Spring XML配置文件的最佳技巧。它们中的一些具有更多的实际意义，而不仅是最好的技巧。请注意另外一些因素，例如域模型的设计，会影响到XML配置，但是这篇文章更关注于XML配置的可读性和可操控性。


1． 避免使用自动装配

Spring可以通过bean类的自省来实现自动装配依赖，这样的话你就不必明确地描述bean的属性或者构造函数的参数。根据属性名称活匹配类型，bean属性可以自动进行装配。而构造函数可以根据匹配类型自动装配。你甚至可以设置自动装配进行自动侦测，这样Spring替你就会选择一个合适的机制。请看下面的例子：

Spring可以通过bean类的自省来实现自动装配依赖，这样的话你就不必明确地描述bean的属性或者构造函数的参数。根据属性名称活匹配类型，bean属性可以自动进行装配。而构造函数可以根据匹配类型自动装配。你甚至可以设置自动装配进行自动侦测，这样Spring替你就会选择一个合适的机制。请看下面的例子：


<bean id="orderService"

class="com.lizjason.spring.OrderService"

autowire="byName"/>


OrderService类的属性名被用来和容器中的一个bean实例进行匹配。自动装配会默默的保存一些类型信息并降低混乱。然而，由于它会牺牲掉这种配置的直观性和可维护性，你在实际的项目中将不会用到它。许多指南和陈述材料都把它吹捧为Spring的一个非常cool的特性，而没有提到它的这个缺点。依我之见，就像Spring的对象池一样，它更多了一些商业味道。它看起来好像可以使XML配置文件更精简一些，但实际上却增加其复杂性，尤其是在你的较大规模的工程中已经定义了很多bean的时候更是如此。Spring允许你混合使用自动和手动装配，但是这种矛盾会使XML配置更加的令人费解。


2． 使用命名规范

和Java编码的理念一样，在项目中始终用清晰的，描述性的，一致的命名规范对开发人员理解XML配置非常有用。拿bean ID举例来说，你可以遵循Java类中属性的命名规范。比如说，OrderServiceDAO的bean ID应该是orderServiceDAO。对于大项目来说，在bean ID前加包名来作为前缀。


3． 使用简化格式

简化格式有利于减少冗余，因为它把属性值和引用作为属性，而不是子元素。看下面的例子：

<bean id="orderService"
class="com.lizjason.spring.OrderService">
<property name="companyName">
<value>lizjason</value>
</property>
<constructor-arg>
<ref bean="orderDAO">
</constructor-arg>
</bean>
以上程序可以重新以简化格式书写为：

<bean id="orderService"
class="com.lizjason.spring.OrderService">
<property name="companyName"
value="lizjason"/>
<constructor-arg ref="orderDAO"/>
</bean>
简化格式在1.2版本时已经可用了，但请注意不存在<ref local="...">这种简化格式不仅可以较少你的代码输入量，而且可以使XML配置更加的清晰。当你的配置文件中存在大量的bean定义时，它可以显著地提高可读性。


4． 尽量使用type而不是index去解决构造函数参数的匹配问题

当构造函数中有多个同类型的参数时，Spring只允许你使用从0开始的index或者value标签来解决这个问题。请看下面的例子：

<bean id="billingService"
class="com.lizjason.spring.BillingService">
<constructor-arg index="0" value="lizjason"/>
<constructor-arg index="1" value="100"/>
</bean>
最好用type属性取代上面的做法：

<bean id="billingService"
class="com.lizjason.spring.BillingService">
<constructor-arg type="java.lang.String"
value="lizjason"/>
<constructor-arg type="int" value="100"/>
</bean>

用index可以稍微减少冗余，但是它更容易出错且不如type属性可读性高。你应该仅在构造函数中有参数冲突时使用index。


5． 如可能，尽量复用bean定义

Spring提供了一种类似于继承的机制来降低配置信息的重复并使XML配置更加的简单。一个子bean可以从它的父bean继承配置信息，本质上这个父bean就像它的子bean的一个模板。这是一个在大型项目中必须使用的特性。所有你要做的就是把父bean的abstract属性置为true，并在子bean中加以引用。例如：

<bean id="abstractService" abstract="true"
class="com.lizjason.spring.AbstractService">
<property name="companyName"
value="lizjason"/>
</bean>

<bean id="shippingService"
parent="abstractService"
class="com.lizjason.spring.ShippingService">
<property name="shippedBy" value="lizjason"/>
</bean>
shippingService bean继承了abstractService bean的属性companyName的值lizjason。注意，如果你为bean声名一个class或工厂方法，这个bean将会默认为abstract


6． 尽量使用ApplicationContext装配bean，而不是用import

像Ant脚本中imports一样，Spring的import 元素对于模块化bean的装配非常有用，例如：

<beans>
<import resource="billingServices.xml"/>
<import resource="shippingServices.xml"/>
<bean id="orderService"
class="com.lizjason.spring.OrderService"/>
<beans>

然而，比起在XML中用imports预装配这些bean，利用ApplicationContext来配置它们将更加灵活，也可以使XML配置更加的易于管理。你可以像下面这样传递一个bean定义数组到ApplicationContext的构造函数中：

String[] serviceResources =

{"orderServices.xml",

"billingServices.xml",

"shippingServices.xml"};

ApplicationContext orderServiceContext = new

ClassPathXmlApplicationContext(serviceResources);


7． 用id来标识bean

你可以用id或名字作为bean的标识。用id可读性较差，但是它可以影响XML分析器使bean的reference有效。如果id由于XML IDREF约束而无法使用，你可以用name作为bean的标识。XML IDREF约束是指id必须以字母开始(或者是在XML声名了的一个标点符号)，后面可以是字母，数字，连字符，下划线，冒号或full stops(不知道怎么翻译好)。在实际应用中很少会遇到XML IDREF约束问题。


8． 在开发阶段使用依赖检查

你可以为bean的dependency-check属性设置一个值来取代默认的none，比如说simple，objects或者all，这样的话容器将替你做依赖有效性的检查。当一个bean的所有属性(或者某些属性目录)都被明确设置，或利用自动装配时将会非常有用。

<bean id="orderService"
class="com.lizjason.spring.OrderService"
dependency-check="objects">
<property name="companyName"
value="lizjason"/>
<constructor-arg ref="orderDAO"/>
</bean>
在这个例子中，容器将确保这些属性不是privitives或者保证collections是为orderService bean设置的。为所有的bean设置默认的依赖检查是可能的，但这个特性由于有些bean的属性不需要设置而很少使用。


9． 为每个配置文件加一个描述注释

在XML配置文件中最好使用有描述性的id和name，而不是成堆的注释。另外，加一个文件描述头将会非常有用，这个描述可以概括文件中定义的bean。另一个选择，你可以在description元素中加入描述信息。例如：

<beans>
<description>
This file defines billing service
related beans and it depends on
baseServices.xml,which provides
service bean templates...
</description>
...
</beans>
用description元素的一个好处就是工具可以很容易的把描述信息从这个元素中提取出来。


10． 和team members沟通变更

当你修改java源码后，要确保更改了配置文件中的相应部分并把这个情况告知你的team members。XML配置文件也是代码，它们是程序的重要组成部分，但它们很难阅读和维护。大多数时间里，你需要同时看XML配置文件和java代码才能知道是怎么回事。


11． setter注入和构造函数注入，优先使用前者

Spring提供了三种注入方式：构造函数注入，setter注入和方法注入。一般我们使用前两种。

<bean id="orderService"
class="com.lizjason.spring.OrderService">
<constructor-arg ref="orderDAO"/>
</bean>

<bean id="billingService"
class="com.lizjason.spring.BillingService">
<property name="billingDAO"
ref="billingDAO">
</bean>

在这个例子中，orderService bean用了构造函数注入，而BillingService bean用了setter注入。构造函数注入可以确保bean正确地构建，但是setter注入更加的灵活和易于控制，特别是当class有多个属性并且它们中的一些是可选的情况是更是如此。


12． 不要滥用注入

就像前面提到的，Spring的ApplicationContext可以替你创建java对象，但不是所有的java对象都应该通过注入创建。例如，域对象就不应该通过ApplicationContext创建。Spring是一个优秀的框架，但是考虑到可读性和可操控性，基于XML配置的配置会在定义很多bean的时候出现麻烦。过渡使用依赖注入将会使XML配置更加的复杂和冗长。切记，当使用高效的IDE时，例如Eclipse and IntelliJ，java代码更加的易于阅读，维护和管理比使XML文件


结论

XML是Spring流行的配置格式。存在大量bean定义时，基于XML的配置会变得冗长而不易使用。Spring提供了丰富的配置选项。适当地使用这些选项可以使XML配置更加的清晰，但其它的一些选项，例如自动装配，可能会降低可读性和可维护性。参考本文中提到的这些技巧可能会帮助你创建干净而易读的XML配置文件

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

一. 引言

性能测试与分析是软件开发过程中介于架构和调整的一个广泛并比较不容易理解的领域，更是一项较为复杂的活动。就像下棋游戏一样，有效的性能测试和分析只能在一个良好的计划策略和具备了对不可预料事件的处理能力的条件下顺利地完成。一个下棋高手赢得比赛靠的不仅仅是对游戏规则的认识，更是靠他的自己的能力和不断地专注于分析自己对手的实力来更加有效地利用和发挥规则的作用。同样一个优秀的性能测试和分析人员将要面对的是来自一个全新的应用程序和环境下带来的整个项目的挑战。本文中作者结合自己的使用经验和参考文档，对Tomcat性能方面的调整做一简要的介绍，并给出Tomcat性能的测试、分析和调整优化的一些方法。

二. 测量Web服务器的性能

测量web服务器的性能是一项让人感到畏缩的任务，但是我们在这里将给出一些需要注意的地方并且指点你了解其中更多的细节性的内容。它不像一些简单的任务，如测量CPU的速率或者是测量程序占用CPU的比例，web服务器的性能优化中包括许调整许多变量来达到目标。许多的测量策略中都包含了一个看似简单的浏览实际上是在向服务器发送大量的请求，我们称之为客户端的程序，来测量响应时间。客户端和服务器端是在同一台机器上吗？服务器在测试的时候还运行着其它的什么程序吗？客户端和服务器端的通讯是通过局域网，100baseT，10baseT还是使用调制解调器？客户端是否一直重复请求相同的页面，还是随机地访问不同的页面？（这些影响到了服务缓存的性能）客户端发送请求的有规律的还是突发的？你是在最终的配置环境下运行服务的还是在调试的配置环境下运行服务的？客户端请求中包含图片还是只有HTML页面？是否有请求是通过servlets和JSP的，CGI程序，服务端包含（Server-Side Includes ，SSI是一个可以让你使用动态HTML文件的技术）？所有这些都将是我们要关心的，并且几乎我们不可能精确地把所有的问题都清楚地列出来。

1.压力测试工具

“工欲善其事，必先利其器”，压力测试只有借助于一些工具才可得以实施。

大多数web压力测试工具的实现原理都是通过重复的大量的页面请求来模拟多用户对被测系统的并发访问，以此达到产生压力的目的。产生压力的手段都是通过录制或者是编写压力脚本，这些脚本以多个进程或者线程的形式在客户端运行，这样通过人为制造各种类型的压力，我们可以观察被测系统在各种压力状况下的表现，从而定位系统瓶颈，作为系统调优的基础。目前已经存在的性能测试工具林林总总，数量不下一百种，从单一的开放源码的免费小工具如 Aapache 自带的 web 性能测试工具 Apache Benchmark、开源的Jmeter 到大而全的商业性能测试软件如 Mercury 的 LoadRunner 等等。任何性能测试工具都有其优缺点，我们可以根据实际情况挑选用最合适的工具。您可以在这里找到一些web压力测试工具http://www.softwareqatest.com/qatweb1.html#LOAD

这里我们所使用的工具要支持web应用服务认证才可以，要支持接收发送cookies，不仅如此Tomcat支持多种认证方式，比如基本认证、基于表单的认证、相互认证和客户端认证，而一些工具仅仅支持HTTP基本认证。真实地模拟用户认证是性能测试工具的一个重要的部分，因为认证机制将对一个web站点的性能特征产生重要的影响。基于你在产品中使用的不同的认证方式，你需要从上面的工具列表中选择使用这种特性的测试工具。

Apache Benchmark和http_load是命令行形式的工具，非常易于使用。Apache Benchmark可以模仿单独的URL请求并且重复地执行，可以使用不同的命令行参数来控制执行迭代的次数，并发用户数等等。它的一个特点是可以周期性地打印出处理过程的信息，而其它工具只能给出一个全局的报告。

2.压力测试工具介绍

三. 外部环境的调整

　　在Tomcat和应用程序进行了压力测试后，如果您对应用程序的性能结果不太满意，就可以采取一些性能调整措施了，当然了前提是应用程序没有问题，我们这里只讲Tomcat的调整。由于Tomcat的运行依赖于JVM，所以在这里我们把Tomcat的调整可以分为两类来详细描述：

　　外部环境调整

　　调整非Tomcat组件，例如Tomcat运行的操作系统和运行Tomcat的java虚拟机。

　　自身调整

　　修改Tomcat自身的参数，调整Tomcat配置文件中的参数。

　　下面我们将详细讲解外部环境调整的有关内容，Tomcat自身调整的内容将在第2部分中阐述。

　　1.JAVA虚拟机性能优化

　　Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。您可以选择自己的需要选择不同的操作系统和对应的JDK的版本（只要是符合Sun发布的Java规范的），但我们推荐您使用Sun公司发布的JDK。确保您所使用的版本是最新的，因为Sun公司和其它一些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。

　　可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。

参数	描述
-Xms	JVM初始化堆的大小
-Xmx	JVM堆的最大值

　　这两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。

　　Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。

　　Windows下，在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：

　　JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'

　　需要把这个两个参数值调大。例如：

　　JAVA_OPTS='-Xms256m -Xmx512m'

　　表示初始化内存为256MB，可以使用的最大内存为512MB。

　　另外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。

　　如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究 垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。

[NextPage]

　2.操作系统性能优化

　　这里说的操作系统是指运行web服务器的系统软件，当然，不同的操作系统是为不同的目的而设计的。比如OpenBSD是面向安全的，因此在它的内核中有许多的限制来防止不同形式的服务攻击（OpenBSD的一句座右铭是“默认是最安全的”）。这些限制或许更多地用来运行活跃的web服务器。

　　而我们常用的Linux操作系统的目标是易用使用，因此它有着更高的限制。使用BSD内核的系统都带有一个名为“Generic”的内核，表明所有的驱动器都静态地与之相连。这样就使系统易于使用，但是如果你要创建一个自定义的内核来加强其中某些限制，那就需要排除不需要的设备。Linux内核中的许多驱动都是动态地加载的。但是换而言之，内存现在变得越来越便宜，所以因为加载额外的设备驱动就显得不是很重要的。重要的是要有更多的内存，并且在服务器上腾出更多的可用内存。

　　小提示：虽然现在内存已经相当的便宜，但还是尽量不要购买便宜的内存。那些有牌子的内存虽然是贵一点，但是从可靠性上来说，性价比会更高一些。

　　如果是在Windows操作系统上使用Tomcat，那么最好选择服务器版本。因为在非服务器版本上，最终用户授权数或者操作系统本身所能承受的用户数、可用的网络连接数或其它方面的一些方面都是有限制的。并且基于安全性的考虑，必须经常给操作系统打上最新的补丁。

　　3.Tomcat与其它web服务器整合使用

　　虽然tomcat也可以作web服务器,但其处理静态html的速度比不上apache,且其作为web服务器的功能远不如apache,因此我们想把apache和tomcat集成起来，将html与jsp的功能部分进行明确分工，让tomcat只处理jsp部分，其它的由apache,IIS等这些web服务器处理，由此大大节省了tomcat有限的工作“线程”。

　　4.负载均衡

　　在负载均衡的思路下，多台服务器为对称方式，每台服务器都具有同等的地位，可以单独对外提供服务而无须其他服务器的辅助。通过负载分担技术，将外部发送来的请求按一定规则分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。

　　提供服务的一组服务器组成了一个应用服务器集群(cluster)，并对外提供一个统一的地址。当一个服务请求被发至该集群时，根据一定规则选择一台服务器，并将服务转定向给该服务器承担，即将负载进行均衡分摊。

　　通过应用负载均衡技术，使应用服务超过了一台服务器只能为有限用户提供服务的限制，可以利用多台服务器同时为大量用户提供服务。当某台服务器出现故障时，负载均衡服务器会自动进行检测并停止将服务请求分发至该服务器，而由其他工作正常的服务器继续提供服务，从而保证了服务的可靠性。

　　负载均衡实现的方式大概有四种：第一是通过DNS，但只能实现简单的轮流分配，不能处理故障，第二如果是基于MS IIS，Windows 2003 server本身就带了负载均衡服务，第三是硬件方式，通过交换机的功能或专门的负载均衡设备可以实现，第四种是软件方式，通过一台负载均衡服务器进行，上面安装软件。使用Apache Httpd Server做负载平衡器，Tomcat集群节点使用Tomcat就可以做到以上第四种方式。这种方式比较灵活，成本相对也较低。另外一个很大的优点就是可以根据应用的情况和服务器的情况采取一些策略。

[NextPage]

四. 自身调整

　　本节将向您详细介绍一些加速可使Tomcat实例加速运行的技巧和方法，无论是在什么操作系统或者何种Java虚拟机上。在有些情况下，您可能没有控制部署环境上的操作系统或者Java虚拟机。在这种情况下，您就需要逐行了解以下的的一些建议，然而你应该在修改后使之生效。我认为以下方法是Tomcat性能自身调整的最佳方式。

　　1.禁用DNS查询

　　当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。为了消除DNS查询对性能的影响我们可以关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值：

Tomcat4
<Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=20000 useURIValidationHack=false disableUploadTimeout=true />

Tomcat5
<Connector port=80 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=20000 disableUploadTimeout=true/>

　　除非你需要连接到站点的每个HTTP客户端的机器名，否则我们建议在生产环境上关闭DNS查询功能。可以通过Tomcat以外的方式来获取机器名。这样不仅节省了网络带宽、查询时间和内存，而且更小的流量会使日志数据也会变得更少，显而易见也节省了硬盘空间。对流量较小的站点来说禁用DNS查询可能没有大流量站点的效果明显，但是此举仍不失为一良策。谁又见到一个低流量的网站一夜之间就流量大增呢？

　　2.调整线程数

　　另外一个可通过应用程序的连接器（Connector）进行性能控制的的参数是创建的处理请求的线程数。Tomcat使用线程池加速响应速度来处理请求。在Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、能够独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。

　　Tomcat4中可以通过修改minProcessors和maxProcessors的值来控制线程数。这些值在安装后就已经设定为默认值并且是足够使用的，但是随着站点的扩容而改大这些值。minProcessors服务器启动时创建的处理请求的线程数应该足够处理一个小量的负载。也就是说，如果一天内每秒仅发生5次单击事件，并且每个请求任务处理需要1秒钟，那么预先设置线程数为5就足够了。但在你的站点访问量较大时就需要设置更大的线程数，指定为参数maxProcessors的值。maxProcessors的值也是有上限的，应防止流量不可控制（或者恶意的服务攻击），从而导致超出了虚拟机使用内存的大小。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。

　　在Tomcat5对这些参数进行了调整，请看下表：

属性名	描述
maxThreads	Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。
acceptCount	指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。
connnectionTimeout	网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。
minSpareThreads	Tomcat初始化时创建的线程数。
maxSpareThreads	一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。

　　最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有人的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。

[NextPage]

3.加速JSP编译速度

　　当第一次访问一个JSP文件时，它会被转换为Java serverlet源码，接着被编译成Java字节码。你可以控制使用哪个编译器，默认情况下，Tomcat使用使用命令行javac进行使用的编译器。也可以使用更快的编译器，但是这里我们将介绍如何优化它们。

　　另外一种方法是不要把所有的实现都使用JSP页面，而是使用一些不同的java模板引擎变量。显然这是一个跨越很大的决定，但是事实证明至少这种方法是只得研究的。如果你想了解更多有关在Tomcat可使用的模板语言，你可以参考Jason Hunter和William Crawford合著的《Java Servlet Programming 》一书（O'Reilly公司出版）。

　　在Tomcat 4.0中可以使用流行而且免费的Jikes编译器。Jikes编译器的速度要由于Sun的Java编译器。首先要安装Jikes（可访问http://oss.software.ibm.com/pub/jikes 获得更多的信息），接着需要在环境变量中设置JIKESPATH包含系统运行时所需的JAR文件。装好Jikes以后还需要设置让JSP编译servlet使用Jikes，需要修改web.xml文件中jspCompilerPlugin的值：

jsp

org.apache.jasper.servlet.JspServlet


logVerbosityLevel
WARNING


jspCompilerPlugin

org.apache.jasper.compiler.JikesJavaCompiler




classpath

/usr/local/jdk1.3.1-linux/jre/lib/rt.jar:
/usr/local/lib/java/servletapi/servlet.ja
r

3

　　在Tomcat 4.1（或更高版本），JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪，但这正是Ant有意为之的一部分，有一个API文档指导开发者在没有启动一个新的JVM的情况下，使用Ant。这是使用Ant进行Java开发的一大优势。另外，这也意味着你现在能够在Ant中使用任何javac支持的编译方式，这里有一个关于Apache Ant使用手册的javac page列表。使用起来是容易的，因为你只需要在 元素中定义一个名字叫“compiler”，并且在value中有一个支持编译的编译器名字，示例如下：

jsp

org.apache.jasper.servlet.JspServlet


logVerbosityLevel
WARNING


compiler
jikes

3

Ant可用的编译器

名称	别名	调用的编译器
classic	javac1.1, javac1.2	Standard JDK 1.1/1.2 compiler
modern	javac1.3, javac1.4	Standard JDK 1.3/1.4 compiler
jikes		The Jikes compiler
JVC	Microsoft	Microsoft command-line compiler from the Microsoft SDK for Java/Visual J++
KJC		The kopi compiler
GCJ		The gcj compiler (included as part of gcc)
SJ	Symantec	Symantec's Java compiler
extJavac		Runs either the modern or classic compiler in a JVM of its own

　　由于JSP页面在第一次使用时已经被编译，那么你可能希望在更新新的jsp页面后马上对它进行编译。实际上，这个过程完全可以自动化，因为可以确认的是新的JSP页面在生产服务器和在测试服务器上的运行效果是一样的。

[NextPage]

在Tomcat4的bin目录下有一个名为jspc的脚本。它仅仅是运行翻译阶段，而不是编译阶段，使用它可以在当前目录生成Java源文件。它是调试JSP页面的一种有力的手段。

　　可以通过浏览器访问再确认一下编译的结果。这样就确保了文件被转换成serverlet，被编译了可直接执行。这样也准确地模仿了真实用户访问JSP页面，可以看到给用户提供的功能。也抓紧这最后一刻修改出现的bug并且修改它J

　　Tomcat提供了一种通过请求来编译JSP页面的功能。例如，你可以在浏览器地址栏中输入http://localhost:8080/examples/jsp/dates/date.jsp?jsp_precompile=true，这样Tomcat就会编译data.jsp而不是执行它。此举唾手可得，不失为一种检验页面正确性的捷径。

　　4. 其它

　　前面我们提到过操作系统通过一些限制手段来防止恶意的服务攻击，同样Tomcat也提供了防止恶意攻击或禁止某些机器访问的设置。

　　Tomcat提供了两个参数供你配置：RemoteHostValve 和RemoteAddrValve。

　　通过配置这两个参数，可以让你过滤来自请求的主机或IP地址，并允许或拒绝哪些主机/IP。与之类似的，在Apache的httpd文件里有对每个目录的允许/拒绝指定。

　　例如你可以把Admin Web application设置成只允许本地访问，设置如下：

allow=127.0.0.1 deny=/>

　　如果没有给出允许主机的指定，那么与拒绝主机匹配的主机就会被拒绝，除此之外的都是允许的。与之类似，如果没有给出拒绝主机的指定，那么与允许主机匹配的主机就会被允许，除此之外的都是拒绝的。


五. 容量计划

　　容量计划是在生产环境中使用Tomcat不得不提的提高性能的另一个重要的话题。如果你没有对预期的网络流量下的硬件和带宽做考虑的话那么无论你如何做配置修改和测试都无济于事。

　　这里先对提及的容量计划作一个简要的定义：容量计划是指评估硬件、操作系统和网络带宽，确定应用服务的服务范围，寻求适合需求和软件特性的软硬件的一项活动。因此这里所说的软件不仅包括Tomcat，也包括与Tomcat结合使用的任何第三方web服务器软件。

　　如果在购买软硬件或部署系统前你对容量计划一无所知，不知道现有的软硬件环境能够支撑多少的访问量，甚至更糟直到你已经交付并且在生产环境上部署产品后才意识到配置有问题时再进行变更可能为时已晚。此时只能增加硬件投入，增加硬盘容量甚至购买更好的服务器。如果事先做了容量计划那么就不会搞的如此焦头烂额了。

　　我们这里只介绍与Tomcat相关的内容。

　　首先为了确定Tomcat使用机器的容量计划，你应该从一下列表项目种着手研究和计划：

　　1. 硬件

　　采用什么样的硬件体系？需要多少台计算机？使用一个大型的，还是使用多台小型机？每个计算机上使用几个CPU？使用多少内存？使用什么样的存储设备，I/O的处理速度有什么要求？怎样维护这些计算机？不同的JVM在这些硬件上运行的效果如何（比如IBM AIX系统只能在其设计的硬件系统上运行）？

　　2. 网络带宽

　　带宽的使用极限是多少？web应用程序如何处理过多的请求？

　　3. 服务端操作系统

　　采用哪种操作系统作为站点服务器最好？在确定的操作系统上使用哪个JVM最好？例如，JVM在这种系统上是否支持本地多线程，对称多处理？哪种系统可使web服务器更快、更稳定，并且更便宜。是否支持多CPU？

[NextPage]

4. Tomcat容量计划

　　以下介绍针对Tomcat做容量计划的步骤：

　　1） 量化负载。如果站点已经建立并运行，可以使用前面介绍的工具模仿用户访问，确定资源的需求量。

　　2） 针对测试结果或测试过程中进行分析。需要知道那些请求造成了负载过重或者使用过多的资源，并与其它请求做比较，这样就确定了系统的瓶颈所在。例如：如果servlet在查询数据库的步骤上耗用较长的时间，那么就需要考虑使用缓冲池来降低响应时间。

　　3） 确定性能最低标准。例如，你不想让用户花20秒来等待结果页面的返回，也就是说甚至在达到访问量的极限时，用户等待的时间也不能超过20秒种（从点击链接到看到返第一条返回数据）。这个时间中包含了数据库查询时间和文件访问时间。同类产品性能在不同的公司可能有不同的标准，一般最好采取同行中的最低标准或对这个标准做出评估。

　　4） 确定如何合理使用底层资源，并逐一进行测试。底层资源包括CPU、内存、存储器、带宽、操作系统、JVM等等。在各种生产环境上都按顺序进行部署和测试，观察是否符合需求。在测试Tomcat时尽量多采用几种JVM，并且调整JVM使用内存和Tomcat线程池的大小进行测试。同时为了达到资源充分合理稳定地使用的效果，还需针对测试过程中出现的硬件系统瓶颈进行处理确定合理的资源配置。这个过程最为复杂，而且一般由于没有可参考的值所以只能靠理论推断和经验总结。

　　5） 如果通过第4步的反复测试如果达到了最优的组合，就可以在相同的生产环境上部署产品了。

　　此外应牢记一定要文档化你的测试过程和结果，因为此后可能还会进行测试，这样就可以拿以前的测试结果做为参考。另外测试过程要反复多次进行，每次的条件可能都不一样，因此只有记录下来才能进行结果比较和最佳条件的选择。

　　这样我们通过测试找到了最好的组合方式，各种资源得到了合理的配置，系统的性能得到了极大的提升。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

对很多初学者来说tomact的配置是非常头疼的事情，但是有了下面的文章你会易如反掌地配置tomcat了，赶快行动吧！

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师