NPO Hosting en Streaming

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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.