sterretje-cluster:appcluster-hosting_aanleveren-van-java-applicatie

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

sterretje-cluster:appcluster-hosting_aanleveren-van-java-applicatie [2020/05/20 05:30] (current)
Line 1: Line 1:
 +====== 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 Hosting en Streaming 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 Hosting en Streaming ​
 +gedaan. Idem voor frontproxy en databases.
 +
 +Het configureren van de applicatie zal meestal in samenspraak tussen
 +NPO Hosting en Streaming en de sitebouwer gebeuren. Zaken waar NPO Hosting en Streamign zich mee
 +bemoeit zijn:
 +
 +  * Database parameters (''​WEB_INF/​config/​modules/​jdbc.xml'';​
 +de database wordt door NPO Hosting en Streaming 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
 +[[http://​www.opensymphony.com/​oscache/​|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: 2020/05/20 05:30
  • (external edit)