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

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

Элемент 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 переместился из Connector в Service, так как 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

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

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

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

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

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

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

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

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

• Он поддерживает Java Servlet 3.1.
• Страницы Java-сервера (JSP) 2.3
• Унифицированный язык выражений Java (EL) 3.0
• Java-веб-сокет 1.0

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

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

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