Mój projekt jest obecnie uruchomiony na Tomcat 7. Czy powinienem przejść na aktualizację do Tomcat 8? Jakie są plusy i minusy robienia tego? czy tomcat 8 jest lepszy pod względem wydajności, wykorzystania pamięci?Czy powinienem dokonać aktualizacji do Tomcat8 z Tomcat 7
Ponieważ twój projekt już działa na tomcat 7, poleciłbym zachować status quo przez jakiś czas. Niewiele danych jest dostępnych w odniesieniu do poprawy wydajności tomcat 8. Niektóre problemy są zgłaszane w Internecie, które są wspólne dla każdej nowej wersji produktu.
Tomcat 8 ma lepszą wydajność w środowiskach współbieżnych.
Z mojego doświadczenia z produktami tomcat najprawdopodobniej uaktualnienie nie przyniosłoby znaczącej wydajności, chyba że aplikacja jest bardzo zasobochłonna. Proszę przeczytać poniższy link przed upgradation
Java 1.7 ==> Pierwszą istotną zmianą jest to, że Tomcat 8 wymaga teraz Java 7 lub później w celu uruchomienia, więc jeśli jesteś migracji z wcześniejszej wersji Tomcat, należy uaktualnić do 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()
Server Złącza
W zakresie konektorów serwera domyślna implementacja konektora HTTP i AJP została zmieniona z implementacji IO blokowania Java (BIO) na implementację non-blocking IO Java (NIO). Można nadal używać starszej wersji BIO, ale funkcje Servlet 3.1 i WebSocket 1.0, które wykorzystują nieblokującą IO, będą zastępować blokowanie IO, co może spowodować nieoczekiwane zachowanie aplikacji.
aplikacji Web zasoby
elementu Resources, która jest częścią konfiguracji i reprezentuje wszystkie zasoby dostępne do aplikacji internetowej została zmieniona. Teraz zawiera klasy, pliki JAR, HTML, JSP i wszelkie inne pliki, które składają się na aplikację internetową. Wdrożono implementacje do używania katalogów, plików JAR i WAR jako źródła tych zasobów, a implementacja zasobów może zostać rozszerzona w celu zapewnienia obsługi plików przechowywanych w innych formach, takich jak baza danych lub wersjonowane repozytorium.
zdalne debugowanie
Podczas uruchamiania Tomcat 8 z opcją jpda aby umożliwić zdalne debugowanie, Tomcat 8 nasłuchuje na localhost: 8000 domyślnie. Wcześniejsze wersje były słuchane *: 8000. Jeśli jest to wymagane, to ustawienie domyślne można przesłonić, ustawiając zmienną środowiskową JPDA_ADDRESS w, na przykład, setenv. [Bat | sh].
Zmiany w API
natomiast Tomcat 8 wewnętrznego API jest zasadniczo zgodny z Tomcat 7 doszło do wielu zmian na poziomie szczegółów i nie są binarnie kompatybilny. Programiści niestandardowych komponentów wchodzących w interakcje z wewnętrznymi serwerami Tomcat powinni przejrzeć JavaDoc dla odpowiedniego interfejsu API.
Na szczególną uwagę zasługują:
Manager, ładowarki i zasoby zostały przeniesione z pojemnika na kontekst, ponieważ kontekst jest jedynym miejscem, są one wykorzystywane.
Mapper został przeniesiony z Łącznika do Usługi, ponieważ Mapper jest taki sam dla wszystkich Łączników danej Usługi.
Istnieje nowa implementacja Zasobów, jak powiedzieliśmy, która łączy alieses, VirtualLoader, VirtualDirContext, zasoby JAR i zewnętrzne repozytoria w pojedynczą strukturę, a nie osobną dla każdej funkcji.
Niektóre linki, które dostarczają więcej informacji o zmianach w Tomcat 8 podano poniżej
http://people.apache.org/~markt/presentations/2013-09-Apache-Tomcat8.pdf
Oto jak samemu zrozumieć, kiedy należy dokonać aktualizacji. Można to wykorzystać w dowolnej wersji Tomcat, teraz lub w przyszłości, nie tylko obejmować modernizację od 7 do Tomcat Tomcat 8.
Większość zmiany Tomcat gdy głównym wersja jest zmieniane są aktualizacje do specyfikacje serwletów, JSP i JDK, na których opiera się konkretna wersja. Jeśli nie potrzebujesz nowszych specyfikacji dla aplikacji, a wersja, której używasz, nie jest "archiwizowana" (Tomcat 7 nie jest archiwizowany od tego czasu), prawdopodobnie nie musisz aktualizować. http://tomcat.apache.org/whichversion.html opisuje, jak dokonać wyboru.
W rzeczywistych sytuacjach wybór może również mieć wpływ na inne czynniki, takie jak to, czy żądana wersja jest obsługiwana przez menedżera pakietów w dystrybucji produkcyjnej. Lub na odwrót:, jeśli Twoja dystrybucja ma tylko określoną wersję Tomcat, możesz dokonać aktualizacji, ponieważ oszczędza to dużo czasu.
Pamiętaj, że nowe funkcje oznaczają również możliwość powstawania nowych błędów. Jeśli nie korzystasz ze specyfikacji nowej wersji Tomcat, czy chcesz skorzystać z szansy na coś przełamującego? To, że dana wersja może zwiększyć wydajność, nie oznacza, że nie zawiedzie się w Twoim unikalnym środowisku wdrażania. Najlepszą odpowiedzią tutaj, jeśli możesz sobie na to pozwolić, jest wdrożenie obu wersji za równoważeniem obciążenia, na wypadek gdyby nowy nie działał.
To powiedziawszy, zawsze są ulepszenia oprogramowania. Sugeruję przeczytanie informacji o wydaniu dla wersji różnych wersji głównej wersji, którą wybierzesz, aby wybrać najlepszą dla twoich okoliczności. https://tomcat.apache.org/tomcat-8.0-doc/RELEASE-NOTES.txt obejmuje na przykład wydanie 8.0.
Po wybraniu wersji głównej, zazwyczaj chcesz używać najnowszej wersji, ponieważ błędy zostaną naprawione w czasie.
Zobacz poniżej nowe główne funkcje tomcat 8. Pomoże to w podjęciu decyzji, czy przeprowadzić migrację, jeśli jej potrzebujesz.
Tomcat 8.0 dostosowuje się do specyfikacji Java EE 7. Obsługuje:
Tomcat 8 może użyj Apache Portable Runtime, aby zapewnić doskonałą skalowalność, wydajność i lepszą integrację z natywnymi technologiami serwera.
Pod względem złączy serwera, domyślna implementacja protokołu HTTP i złącze AJP został przełączony z blokowania realizacji Java IO (BIO) na blokowaniu braku implementacji Java IO (NIO)
Również należy pamiętać, Tomcat 8 do uruchomienia wymagana jest Java 7 lub nowsza, więc migruj tylko, jeśli używasz przynajmniej Java 7 w swoim projekcie.
nie tylko bardziej błędu w samej Tomcat, ale również w rozwoju narzędzi, na przykład „służyć moduły bez publikowania "funkcja w Eclipse nie działa dobrze z Tomcat 8. – rustyx