我应该从Tomcat 7升级到Tomcat8吗？

Question

我的项目目前正在Tomcat 7上运行.我应该升级到Tomcat 8吗？这样做的优点和缺点是什么？tomcat 8在性能,内存利用率方面更好吗？

Answer 1

由于您的项目已经在tomcat 7上运行,我建议保持现状一段时间.关于tomcat 8性能改进的数据不多.在互联网上报告了一些问题,这对于任何新版本的产品都是常见的.

Tomcat 8在并发环境中具有更好的性能.

根据我对tomcat产品的经验,除非您拥有资源非常密集的应用程序,否则升级不会产生任何重大性能.升级前请阅读以下链接

http://events.linuxfoundation.org/sites/events/files/slides/2014-04-09-Migrating-to-Apache-Tomcat-8.pdf

重要的变化

Java 1.7 ==>第一个重要的变化是,Tomcat 8现在需要Java 7或更高版本才能运行,因此如果要从早期的Tomcat版本迁移,则应该升级到Java 7

Specification Changes

Servlet 3.1 (JSR 340)
JSP 2.3 (JSR 245 maintenance release)
EL 3.0 (JSR 341)
WebSocket 1.0 (JSR 356)

Specification Changes: EL 3.0

Coercion of nulls to Number, Character or Boolean
- EL 2.2 and earlier (0, 0, false)
- EL 3.0 and later (null, null, null)
System property
– org.apache.el.parser.COERCE_TO_ZERO
– Set to true for EL 2.2 behaviour

Specification Changes: JSP 2.3

Minor changes to reflect the changes in EL 3.0
JSP 2.3
– Supported: GET, POST and HEAD
– Undefined: Everything else
 JSP 2.2 and earlier
– Undefined: Most implementations assumed all
 Tomcat only permits GET, POST and HEAD
– Protection against verb tampering

Specification Changes: WebSocket 1.0

Tomcat 7 initially shipped with a proprietary WebSocket API
- Tomcat 8 ships with a JSR 356 WebSocket implementation
– Also back-ported to Tomcat 7
- The proprietary WebSocket API is deprecated in Tomcat 7
- Applications using the proprietary API need to migrate
– Relatively simple
– https://svn.apache.org/r1424733

Specification Changes: Servlet 3.1

- Session ID changes by default on authentication
– Prevents session fixation

Tomcat Changes:

Connectors

Default connector has changed from BIO to NIO
– BIO is likely to be dropped for Tomcat 9
- Only BIO option not supported by NIO is irrelevant for NIO
– disableKeepAlivePercentage
- May notice different network / CPU loads
– More established, idle connections
– Marginally higher CPU load

Static Resources

Tomcat 7
– Aliases
– VirtualLoader
– VirtualDirContext
– JAR resources
– External repositories
- All variations on a theme
- Each implemented differently


Tomcat 8
– New WebResources implementation
? JAR resources
– External resources for class loader
- Completely new configuration
- Caching attributes removed from Context

Resources now defined by as:
– Pre-resources
– Main resources
– JAR resources
– Post-resources

Resources attributes:
– base
– internalPath
– webappMount
– readOnly

 Internal APIs

- Lots of changes
– Manager, Loader and Resources are now Context only
– Mapper moved from Connector to Service
– WebResources
- If you extend a Tomcat class, review the API docs

Database Connection Pools

- Tomcat 7 and earlier based on DBCP 1
- Tomcat 8 based on DBCP 2
- Better performance in concurrent environments
– Comparable to Tomcat’s JDBC pool
- There are some changes to configuration attributes
– Reflect consistency changes made in Commons Pool 2
- maxActive -> maxTotal
- maxWait -> maxWaitMillis
- Validation no longer requires a validation query
– Uses Connection.isValid()

服务连接器

就服务器连接器而言,默认的HTTP和AJP连接器实现已从Java阻塞IO实现(BIO)切换到Java非阻塞IO实现(NIO).可能仍然使用较旧的BIO,但使用非阻塞IO的Servlet 3.1和WebSocket 1.0功能将回退到阻塞IO,这可能会导致意外的应用程序行为.

Web应用程序资源

作为配置一部分并表示Web应用程序可用的所有资源的Resources元素已经过修订.现在它包括类,JAR文件,HTML,JSP以及有助于Web应用程序的任何其他文件.提供实现以使用目录,JAR文件和WAR作为这些资源的源,并且可以扩展资源实现以提供对以其他形式存储的文件的支持,例如在数据库或版本化存储库中.

远程调试

使用jpda选项启动Tomcat 8以启用远程调试时,Tomcat 8默认侦听localhost:8000.早期版本听取了*:8000.如果需要,可以通过在例如setenv.[bat | sh]中设置JPDA_ADDRESS环境变量来覆盖此默认值.

API的变化

虽然Tomcat 8内部API与Tomcat 7广泛兼容,但在细节级别上有许多变化,并且它们不是二进制兼容的.与Tomcat内部交互的自定义​​组件的开发人员应该查看相关API的JavaDoc.

特别值得注意的是:

Manager,Loader和Resources已经从Container转移到Context,因为Context是他们使用的唯一地方.

由于Mapper对于给定服务的所有连接器都是相同的,因此Mapper已从连接器移至服务.

正如我们所说,有一个新的Resources实现将Aliases,VirtualLoader,VirtualDirContext,JAR资源和外部存储库合并到一个框架中,而不是为每个特性单独构建一个框架.

下面给出了一些提供有关tomcat 8变化的更多信息的链接

http://people.apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf

https://tomcat.apache.org/tomcat-8.0-doc/changelog.html

Answer 2

以下是如何了解自己何时升级.您可以将它与任何版本的Tomcat一起使用,现在或将来,它不仅涵盖从Tomcat 7升级到Tomcat 8.

更改主要版本时对Tomcat的大多数更改都是对特定版本构建的servlet,JSP和JDK规范的升级.如果您不需要应用程序的较新规范,并且您使用的版本未"存档"(Tomcat 7在撰写本文时未归档),则可能不需要升级.http://tomcat.apache.org/whichversion.html介绍了如何进行选择.

在实际情况中,您的选择也可能受其他因素的影响,例如您的生产发行版中的包管理器是否支持您想要的版本.或者相反,如果您的发行版只有特定版本的Tomcat,您可能会升级,因为它可以节省大量时间.

请记住,新功能也意味着新bug的潜在可能性.如果您没有使用新Tomcat版本的规范,您是否希望有机会破解？仅仅因为版本具有更高性能的潜力并不意味着它不会在您的独特部署环境中崩溃.如果您能负担得起,这里的最佳答案是在负载均衡器后面部署两个版本,以防新的版本无效.

也就是说,软件总是有所改进.我建议您阅读发行说明,了解您选择的各种版本的主要版本,以便根据您自己的情况选择最佳版本.例如,https://tomcat.apache.org/tomcat-8.0-doc/RELEASE-NOTES.txt涵盖了8.0版本.

一旦选择了主要版本,通常需要使用它的最新版本,因为错误会随着时间的推移而得到修复.