- 
IBM HTTP server: plugin, proxy, cache
Category None
Bookmark :
In september schreef ik een artikel over het gebruik van alternatieve HTTP frontend-servers voor Domino. In de situatie waar ik toen over schreef, maakten we gebruik van de WebSphere plugin-cfg.xml ('WAS-plugin") om het binnenkomende http-verkeer te routeren naar de juiste Domino- of WebSphere Portal-servers. Sindsdien hebben we ook nog wat andere ervaringen opgedaan; die wil ik hier met u delen.
Recent hebben we gewerkt met IBM HTTP Server (IHS), de door IBM bewerkte variant van Apache, als frontend voor Domino en QuickPlace. Vanwege enkele versie-gevoeligheden en -afhankelijkheden tussen QuickPlace, Domino en de WAS-plugin hebben we besloten voor dit traject geen gebruik te maken van de WAS-plugin: we gebruiken IHS als reverse proxy. En dat blijkt soms een heel positief effect op de performance van Domino te hebben!
Bookmark :
In september schreef ik een artikel over het gebruik van alternatieve HTTP frontend-servers voor Domino. In de situatie waar ik toen over schreef, maakten we gebruik van de WebSphere plugin-cfg.xml ('WAS-plugin") om het binnenkomende http-verkeer te routeren naar de juiste Domino- of WebSphere Portal-servers. Sindsdien hebben we ook nog wat andere ervaringen opgedaan; die wil ik hier met u delen.
Recent hebben we gewerkt met IBM HTTP Server (IHS), de door IBM bewerkte variant van Apache, als frontend voor Domino en QuickPlace. Vanwege enkele versie-gevoeligheden en -afhankelijkheden tussen QuickPlace, Domino en de WAS-plugin hebben we besloten voor dit traject geen gebruik te maken van de WAS-plugin: we gebruiken IHS als reverse proxy. En dat blijkt soms een heel positief effect op de performance van Domino te hebben!
"IHS als reverse proxy", dat wil zeggen, we maken gebruik van de IHS mod_proxy-functionaliteit die je in de httpd.conf kunt inschakelen. Het voordeel van deze methode is, dat je helemaal geen WAS-plugin nodig hebt: je kunt gebruik maken van bestaande, ingebouwde functionaliteit in IHS. Bovendien lijkt deze oplossing iets beter te performen dan de constructie met de WAS-plugin, al heb ik daar geen harde bewijzen voor.
Soms wil je echt de WAS-plugin gebruiken. De plugin geeft een stuk flexibiliteit wat je met reverse-proxy niet hebt. Via de plugin kun je load balancing doen en failover regelen; dat kan bijvoorbeeld met de reverse proxy-functionaliteit niet. Of je uiteindelijk de proxy of de plugin gebruikt, hangt dus af van je specifieke omstandigheden.
Caching gunstig effect op CPU-verbruik Domino
IHS kan ook gebruikt worden om bepaalde content te cachen. Het is natuurlijk erg handig als IHS een vaker gebruikt plaatje kan serveren vanuit zijn geheugen, in plaats van hem iedere keer op te moeten gaan halen bij Domino. Om te testen hoeveel winst hier nu te behalen valt, heeft een collega van me een loadtest gedaan op een Domino-webapplicatie. Er werden twee situaties getest: native Domino HTTP, en IHS als caching reverse proxy vóór Domino HTTP. De loadtest hield in, dat er gedurende een korte periode een toenemend aantal gesimuleerde users op de applicatie losgelaten werd. Iedere actieve gebruiker (en dat worden er dus steeds meer) vroeg om de anderhalve seconde een pagina op. Ondertussen werd het CPU-verbruik op de Domino-server gemeten.
In situatie 1, een pure Domino HTTP-omgeving, geeft dat dit resultaat:
In deze test zit de Domino-server na ongeveer een minuut tegen 100% CPU-verbruik. Vanaf dat moment gaan de response-tijden oplopen; de site begint 'traag' aan te voelen.
In de tweede situatie heeft de Domino-server het een stuk makkelijker:
Nu was dit een eenvoudige test op low-end hardware; maar de resultaten geven wel aan, dat IHS als caching reverse proxy een positief effect kan hebben op de CPU-load van een Domino-server.
150.000
Voor een klant hebben we recent een hosting-omgeving op moeten zetten, die in staat zou zijn om tot 250.000 website-bezoekers per dag af te handelen. De data komt grotendeels uit Domino, met een enkel onderdeel uit WebSphere.
Uiteindelijk is gekozen voor een getrapte opzet met drie servers. De eerste server die de browser tegenkomt, is een caching reverse proxy IHS-server. De tweede server daarachter is een IHS-server die gebruik maakt van de WAS-plugin. Die IHS-server haalt zijn data weer op bij de derde trap, de achterliggende Domino applicatie-server. Sommige onderdelen van deze constructie zijn dubbel of driedubbel uitgevoerd om de grote hoeveelheden bezoekers aan te kunnen.
Bij een stress-test op deze omgeving werd de belasting opgevoerd tot 150.000 gesimuleerde bezoekers per dag; deze 'bezoekers' gedroegen zich zoals de echte bezoekers normaal ook doen. De architectuur doorstond de streestest met glans. De performance bleef op peil; CPU- en bandbreedte-verbruik bleven laag, respectievelijk 15 en 30%.
Soms wil je echt de WAS-plugin gebruiken. De plugin geeft een stuk flexibiliteit wat je met reverse-proxy niet hebt. Via de plugin kun je load balancing doen en failover regelen; dat kan bijvoorbeeld met de reverse proxy-functionaliteit niet. Of je uiteindelijk de proxy of de plugin gebruikt, hangt dus af van je specifieke omstandigheden.
Caching gunstig effect op CPU-verbruik Domino
IHS kan ook gebruikt worden om bepaalde content te cachen. Het is natuurlijk erg handig als IHS een vaker gebruikt plaatje kan serveren vanuit zijn geheugen, in plaats van hem iedere keer op te moeten gaan halen bij Domino. Om te testen hoeveel winst hier nu te behalen valt, heeft een collega van me een loadtest gedaan op een Domino-webapplicatie. Er werden twee situaties getest: native Domino HTTP, en IHS als caching reverse proxy vóór Domino HTTP. De loadtest hield in, dat er gedurende een korte periode een toenemend aantal gesimuleerde users op de applicatie losgelaten werd. Iedere actieve gebruiker (en dat worden er dus steeds meer) vroeg om de anderhalve seconde een pagina op. Ondertussen werd het CPU-verbruik op de Domino-server gemeten.
In situatie 1, een pure Domino HTTP-omgeving, geeft dat dit resultaat:
 |
In deze test zit de Domino-server na ongeveer een minuut tegen 100% CPU-verbruik. Vanaf dat moment gaan de response-tijden oplopen; de site begint 'traag' aan te voelen.
In de tweede situatie heeft de Domino-server het een stuk makkelijker:
 |
Nu was dit een eenvoudige test op low-end hardware; maar de resultaten geven wel aan, dat IHS als caching reverse proxy een positief effect kan hebben op de CPU-load van een Domino-server.
150.000
Voor een klant hebben we recent een hosting-omgeving op moeten zetten, die in staat zou zijn om tot 250.000 website-bezoekers per dag af te handelen. De data komt grotendeels uit Domino, met een enkel onderdeel uit WebSphere.
Uiteindelijk is gekozen voor een getrapte opzet met drie servers. De eerste server die de browser tegenkomt, is een caching reverse proxy IHS-server. De tweede server daarachter is een IHS-server die gebruik maakt van de WAS-plugin. Die IHS-server haalt zijn data weer op bij de derde trap, de achterliggende Domino applicatie-server. Sommige onderdelen van deze constructie zijn dubbel of driedubbel uitgevoerd om de grote hoeveelheden bezoekers aan te kunnen.
Bij een stress-test op deze omgeving werd de belasting opgevoerd tot 150.000 gesimuleerde bezoekers per dag; deze 'bezoekers' gedroegen zich zoals de echte bezoekers normaal ook doen. De architectuur doorstond de streestest met glans. De performance bleef op peil; CPU- en bandbreedte-verbruik bleven laag, respectievelijk 15 en 30%.