Aanleveren van Java applicaties

Applicaties kunt u zelf plaatsen door ze op de uload-server in de juiste web-app directory neer te zetten. Het is ook mogelijk dit door NPO ICT te laten doen. Wij gaan er dan vanuit dat er 1 complete war file aangeleverd wordt (bv dmv een url waarvan wij de war file kunnen downloaden). Vervolgens zullen wij de war file plaatsen. Wij verwachten dat naast de war file installatie instructies aangeleverd worden.

Het configureren van de applicatieserver wordt altijd door NPO ICT gedaan. Idem voor frontproxy en databases.

Het configureren van de applicatie zal meestal in samenspraak tussen NPO ICT en de sitebouwer gebeuren. Zaken waar NPO ICT zich mee bemoeit zijn:

  • Database parameters (WEB_INF/config/modules/jdbc.xml;

de database wordt door NPO ICT aangemaakt. login namen en database passwords zijn daar eventueel op te vragen)

  • Applicatie logfiles (WEB_INF/config/log/log4j.xml;

wij wensen dat de applicatie X logt onder /e/ap/X/log en we wensen dat de logfiles dagelijks geroteerd worden (DailyRollingFileAppender))

  • Kiezen van poortnummers waar eventueel aan gebonden wordt. Bv rmmci

bindt standaard aan *:1111 Dat werkt niet als er meerdere instances op dezelfde server moeten draaien.

Gouden Frontproxy Regels mbt Java hosting

Standaard zit een Java webapp achter een caching frontproxy. Voor een goede werking van uw website is het van belang om hier in een vroeg stadium terdege rekening mee te houden. (php sites ziten niet achter een caching proxy en deze sectie is dus niet van toepassing op php sites) Deze caching frontproxy (apache-2.2 met mod_cache houdt zich netjes aan <url url=β€œhttp://www.faqs.org/rfcs/rfc2616.html” name=β€œde HTTP/1.1 specificatie (RFC2616)”>. Developers wordt aangeraden om secties 13 en 14.9 uit onderstaande RFC te bestuderen, maar het blijkt dat het voor veel developers toch als een schok komt dat data gecached zou kunnen worden. Vandaar de volgende Gouden Frontproxy Regels waarmee in een vroeg stadium veel ellende voorkomen kan worden:

  • HTTP caching is noodzaak! Tomcat haalt +/- 50 hits per seconde, apache

haalt er +/- 5000 per seconde. Da's een factor 100 verschil, ofwel het verschil tussen elke dag water uit de kraan of nog geen 4 dagen per jaar water uit de kraan. Onze ervaring is dat websites die aan een TV programma verbonden zijn beslist zoveel mogelijk cachable moeten zijn!

  • Sessies en HTTP caching gaan niet samen! Bedenk dat als een deel v/d

site gecached wordt, niet alle hits bij tomcat uitkomen (dat was nu net de bedoeling) en je sessie informatie (waar in mijn site is deze gebruiker geweest) dus op z'n minst incompleet, maar in het algemeen waardeloos sis geworden. Bovendien worden sessies op http niveau geimplementeerd middels Cookies. Als op pagina's sessies worden gebruikt (wat default is voor alle jsp pagina's in tomcat!) krijgen die een Set-Cookie http header mee. Stel dat deze Set-Cookie header gecached wordt dan betekent dat dat verschillende gebruikers dezelfde cookie krijgen en later dus mogelijk dezelfde sessie! Gebruik dus zo min mogelijk sessies. Als je geen sessies gebruikt, zet ze dan uit. Dat maakt de site veel beter cachable.

  • Zorg ervoor dat op alle pagina's waarvan je wilt dat deze cachable is

een Expires en indien mogelijk een Last-Modified http header gezet wordt. Een paar minuten in de toekomst is een goede waarde voor de Expires header. De Last-Modified header moet bij voorkeur de tijd krijgen dat de pagina voor het laastst gewijzigd is. De huidige tijd gewoon invullen is niet acceptabel. Indien het wel mogelijk is om Expires headers te genereren, maar niet mogelijk om Last-Modified te genereren, kunnen wij een switch in de frontproxy aanzetten die dit ignored. Hiermee worden dit type pagina's ook cachable.

  • URLs met een vraagteken (?) erin, moeten een Expires header

hebben om ze cachable te maken (RFC2616/13.9)

  • Indien sessies gebruikt worden of als het anderszins ongewenst is dat

content gecached wordt, dan dient dit expliciet aangegeven te worden. Dit kan met Cache-Control: private (RFC2616/14.9.1)

Stel nu dat een pagina toch niet door de frontproxy gecached mag worden, bijvoorbeeld omdat er sessies nodig zijn, hou dan de volgende richtlijnen aan:

  • Gebruik jsp caching binnen tomcat. Wij raden

OSCache aan.

  • Probeer database access te vermijden. Afhankelijk van het type access

kan dit een factor 10 schelen.

  • Als er toch database access nodig is, dan is het beter 1 ingewikkelde

query naar de database server te sturen dan 10 gewone queries om hetzelfde te bereiken.

  • sterretje-cluster/appcluster-hosting_aanleveren-van-java-applicatie.txt
  • Last modified: 2019/04/26 10:34
  • (external edit)