Ответ 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 по умолчанию переключилась с реализации IO блокировки Java (BIO) на неблокирующую реализацию ввода-вывода Java (NIO). Более старый BIO может по-прежнему использоваться, но функции Servlet 3.1 и WebSocket 1.0, которые используют неблокирующий IO, затем возвращаются к блокировке IO, что может вызвать неожиданное поведение приложения.

Ресурсы веб-приложений

Элемент Resources, который является частью конфигурации и представляет все ресурсы, доступные для веб-приложения, был пересмотрен. Теперь он включает в себя классы, файлы JAR, HTML, JSP и любые другие файлы, которые вносят вклад в веб-приложение. Реализации предусматривают использование каталогов, файлов JAR и WAR в качестве источника этих ресурсов, а реализация ресурсов может быть расширена, чтобы обеспечить поддержку файлов, хранящихся в других формах, например, в базе данных или в версиях репозитория.

Удаленная отладка

При запуске Tomcat 8 с опцией jpda для включения удаленной отладки Tomcat 8 по умолчанию прослушивает localhost: 8000. Более ранние версии прослушивались на *: 8000. При необходимости это значение по умолчанию можно переопределить, установив переменную среды JPDA_ADDRESS в, например, setenv. [Bat | sh].

Изменения в API

В то время как внутренний API Tomcat 8 широко совместим с Tomcat 7, на уровне детализации было много изменений, и они не совместимы с двоичными файлами. Разработчики пользовательских компонентов, которые взаимодействуют с внутренними компонентами Tomcat, должны просмотреть JavaDoc для соответствующего API.

Особо следует отметить:

Менеджер, загрузчик и ресурсы переместились из Контейнера в Контекст, поскольку Контекст - это единственное место, где они используются.

Mapper переместился из Коннектора в Сервис, так как Mapper идентичен для всех Разъемов данной Службы.

Существует новая реализация ресурсов, которая, как мы сказали, объединяет в качестве альтернативы отдельные алиасы, 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

Ответ 2

Здесь, как понять самостоятельно, когда нужно обновлять. Вы можете использовать это с любой версией Tomcat, сейчас или в будущем, это не просто обновление с Tomcat 7 до Tomcat 8.

Большинство изменений в Tomcat при изменении основной версии - это обновления к спецификациям сервлета, JSP и JDK, на которых построена определенная версия. Если вам не нужны более новые спецификации для вашего приложения, а используемая вами версия не "архивирована" (Tomcat 7 не архивируется на момент написания этой статьи), вам, вероятно, не нужно обновлять. http://tomcat.apache.org/whichversion.html описывает, как сделать выбор.

В реальных ситуациях на ваш выбор могут влиять и другие факторы, например, зависит ли ваша версия от менеджера пакетов в вашем производственном дистрибутиве. Или, наоборот, если ваш дистрибутив имеет только определенную версию Tomcat, вы можете обновить его, поскольку это экономит значительное время.

Помните, что новые функции также означают потенциал для новых ошибок. Если вы не используете спецификации новой версии Tomcat, вы хотите воспользоваться возможностью взлома? Просто потому, что версия имеет потенциал для повышения производительности, не означает, что она не будет разбиваться в вашей уникальной среде развертывания. Лучший ответ здесь, если вы можете себе это позволить, - развернуть обе версии за балансировщиком нагрузки, если новый не работает.

Тем не менее, всегда есть улучшения в программном обеспечении. Я предлагаю прочитать примечания к выпуску для выпусков различных версий основной версии, которую вы выбираете, чтобы выбрать лучший для своих собственных обстоятельств. https://tomcat.apache.org/tomcat-8.0-doc/RELEASE-NOTES.txt охватывает, например, выпуск 8.0.

Как только вы выберете основную версию, вы обычно хотите использовать последнюю версию, так как ошибки со временем будут исправлены.

Ответ 3

См. ниже новые основные функции tomcat 8. Это поможет решить, следует ли переносить их, если они вам нужны.

Версия Tomcat 8.0 соответствует спецификации Java EE 7. Он поддерживает:

• Он поддерживает Java Servlet 3.1
• Страницы сервера Java (JSP) 2.3
• Java Unified Expression Language (EL) 3.0
• Java WebSocket 1.0

Tomcat 8 может использовать Apache Portable Runtime для обеспечения превосходной масштабируемости, производительности и лучшей интеграции с собственными серверными технологиями.

В терминах соединителей сервера стандартная реализация соединителя по умолчанию для HTTP и AJP переключилась с реализации IO блокировки Java (BIO) на неблокирующую IO-реализацию Java (NIO)

Также обратите внимание, что Tomcat 8 требует Java 7 или более поздней версии для запуска, поэтому только переносите, если вы используете по меньшей мере Java 7 в своем проекте.