Onderwerp: Reverse Rroxy

Hoi,

Ik ga waarschijnlijk een traject in waar we dit gaan implementeren,
natuurlijk gaan we een mooi selectie process doen met eerst kijken wat
we nou eigenlijk willen, vervolgens dat matchen met wat mogelijk is bij
diverse pakketen.

Doch behalve dergelijke kille feiten, zijn ervaringen/meningen van
anderen altijd ook zeer welkom, oftewel als je in een K*T project hebt
gezeten met brakke software of met diep droevende support van een
leverancier dan wil ik dat graag weten :-)

Wat valt er momenteel eingelijk te beleven op dit gebied? Voorlopig kom
ik tot onderstaande lijst.

Apache (mod_proxy)
Websphere (Edge server)
Squid (Accelerator mode)
sunONE (web proxy server)

Groeten, Herbert

"Herbert Groot Jebbink" <hgj@xs4all.nl> wrote in message
news:3ee2e34f$0$49103$e4fe514c@news.xs4all.nl...
> Hoi,
>
> Ik ga waarschijnlijk een traject in waar we dit gaan implementeren,
> natuurlijk gaan we een mooi selectie process doen met eerst kijken wat
> we nou eigenlijk willen, vervolgens dat matchen met wat mogelijk is bij
> diverse pakketen.
>
> Doch behalve dergelijke kille feiten, zijn ervaringen/meningen van
> anderen altijd ook zeer welkom, oftewel als je in een K*T project hebt
> gezeten met brakke software of met diep droevende support van een
> leverancier dan wil ik dat graag weten :-)
>
> Wat valt er momenteel eingelijk te beleven op dit gebied? Voorlopig kom
> ik tot onderstaande lijst.
>
> Apache (mod_proxy)
> Websphere (Edge server)
> Squid (Accelerator mode)
> sunONE (web proxy server)
>
> Groeten, Herbert
>

Er zijn redelijk wat aanbieders van proxy software alhoewel je kennelijk op
zoekt ben naar een reverse proxy (gezien de titel van je posting) en dat is
een wat ander beestje. Kun je aangeven wat je me de proxy server wilt
bereiken? Is het om een achterliggende applicatieserver te ontsluiten,
single sign authenticatie, proxy cache voor een achterliggende web server
etc...? Het hangt namelijk behoorlijk af van de doelstelling welke proxy het
handigst is.

Groetjes,

MEint

Herbert Groot Jebbink <hgj@xs4all.nl> wrote:

>Hoi,
>
>Ik ga waarschijnlijk een traject in waar we dit gaan implementeren,
>natuurlijk gaan we een mooi selectie process doen met eerst kijken wat
>we nou eigenlijk willen, vervolgens dat matchen met wat mogelijk is bij
>diverse pakketen.
>
>Doch behalve dergelijke kille feiten, zijn ervaringen/meningen van
>anderen altijd ook zeer welkom, oftewel als je in een K*T project hebt
>gezeten met brakke software of met diep droevende support van een
>leverancier dan wil ik dat graag weten :-)
>
>Wat valt er momenteel eingelijk te beleven op dit gebied? Voorlopig kom
>ik tot onderstaande lijst.
>
>Apache (mod_proxy)
>Websphere (Edge server)
>Squid (Accelerator mode)
>sunONE (web proxy server)

Als het is om je webserver te ontlasten, dan is Squid een goede optie.
Ik gebruik Squid al 2 jaar op die manier naar volle tevredenheid. Let
wel dat je allerlei bij-effecten krijgt van andere proxy servers. Je
moet bijvoorbeeld niet gek staan te kijken als sommige hosts duizenden
opvragingen per dag gaan sturen om te controleren of de content van je
cache nog vers is.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

M.E. Post wrote:

>> Doch behalve dergelijke kille feiten, zijn ervaringen/meningen van
>> anderen altijd ook zeer welkom, oftewel als je in een K*T project hebt
>> gezeten met brakke software of met diep droevende support van een
>> leverancier dan wil ik dat graag weten :-)

> Kun je aangeven wat je me de proxy server wilt
> bereiken? Is het om een achterliggende applicatieserver te ontsluiten,
> single sign authenticatie, proxy cache voor een achterliggende web server
> etc...? Het hangt namelijk behoorlijk af van de doelstelling welke proxy het
> handigst is.

Het doel is inderdaad om een achterliggende applicatie server te
ontlasten en pieken te kunnen opvangen, dit is een java applicatie, een
niet performende java applicatie :-) Men heeft nu wat caching in de java
applicatie zitten inbouwen om dat performance aspect aan te pakken doch
ik wil dit soort logic niet in de applicatie verstopt hebben zitten maar
met een reverse proxy aan gaan pakken.

Groeten, Herbert

Herbert Groot Jebbink:
>M.E. Post wrote:
>> Kun je aangeven wat je me de proxy server wilt bereiken?
>
>Het doel is inderdaad om een achterliggende applicatie server te
>ontlasten en pieken te kunnen opvangen, dit is een java applicatie, een
>niet performende java applicatie :-) Men heeft nu wat caching in de java
>applicatie zitten inbouwen om dat performance aspect aan te pakken doch
>ik wil dit soort logic niet in de applicatie verstopt hebben zitten maar
>met een reverse proxy aan gaan pakken.

En kan dat dan wel bij deze applicatie? Hoe zit het bijvoorbeeld
met afhankelijkheid van session identifiers (cookies en/of
session-id in URL), gepersonaliseerde of tijdafhankelijke
pagina's, dynamische parameters in URLs en dat soort zaken?

Caching in een (Java-/OO-)applicatie is vaak een ander soort
caching dan simpelweg copieën van gegenereerde pagina's
bijhouden. Denk aan caching van database-data in het geheugen,
caching van (samengestelde) objecten in het geheugen, caching
van herbruikbare gerenderde delen van overigens dynamische
pagina's etc.

Ik zou dit "advanced features" noemen, niet "in de applicatie
verstopt" :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:

>>> Kun je aangeven wat je me de proxy server wilt bereiken?

>> Het doel is inderdaad om een achterliggende applicatie server te
>> ontlasten en pieken te kunnen opvangen, dit is een java applicatie, een
>> niet performende java applicatie :-) Men heeft nu wat caching in de java
>> applicatie zitten inbouwen om dat performance aspect aan te pakken doch
>> ik wil dit soort logic niet in de applicatie verstopt hebben zitten maar
>> met een reverse proxy aan gaan pakken.

> En kan dat dan wel bij deze applicatie?

hopelijk wel, kan spannend worden, er moet (een deel van) dynamische
content gecached gaan worden, gemaakt met JSP en servlets. De Websphere
Edge server zegt dat die dat kan.

> Hoe zit het bijvoorbeeld met afhankelijkheid van session
> identifiers (cookies en/of session-id in URL),

goed punt, is eigenlijk momenteel een probleemje, de applicatie
genereerd altijd voor iedereen een sessie (in een cookie, niet in de
URL), terwijl maar een klein gedeelte van de website persoonlijk is
(voor dat gedeelte moet men ook inloggen).

Het grootste gedeelte van de site veranderd maar eens per week, dit
gedeelte krijgt ook de meeste bezoekers in 2 pieken per week.(die
pagina's zijn dus gelijk voor alle bezoekers, ik wil dus dat de
applicatie geen sessies aanmaakt in dit gedeelte, en ik wil dit gedeelte
gaan cachen om die 2 pieken op te vangen).

> gepersonaliseerde of tijdafhankelijke
> pagina's, dynamische parameters in URLs en dat soort zaken?

> Caching in een (Java-/OO-)applicatie is vaak een ander soort
> caching dan simpelweg copieën van gegenereerde pagina's
> bijhouden. Denk aan caching van database-data in het geheugen,
> caching van (samengestelde) objecten in het geheugen, caching
> van herbruikbare gerenderde delen van overigens dynamische
> pagina's etc.

> Ik zou dit "advanced features" noemen, niet "in de applicatie
> verstopt" :-)

hmmm, het kan zijn dat ik last heb van vooroordelen, maar als ik zie wat
die Java programmeurs allemaal uitvreten, wil ik ze eigenlijk helemaal
niet "advanced features" laten bouwen. Kijk vroeger, toen we nog
applicaties in Cobol bouwden maakten we eerst een TO, toen wisten we
precies hoeveel I/O een programma per transaktie deed of hoeveel
geheugen we gebruikten. Nu gaat een applicatie live en na 3 kwartier
gebruikt het 22 GB geheugen terwijl er maar 4 GB inzat, hoewel het
platform heel goed kan pagen, was dat iets te veel van het goede.

hgj

Herbert Groot Jebbink <hgj@xs4all.nl> wrote:
[reverse proxy]
>> En kan dat dan wel bij deze applicatie?
>
> hopelijk wel, kan spannend worden, er moet (een deel van) dynamische
> content gecached gaan worden, gemaakt met JSP en servlets. De Websphere
> Edge server zegt dat die dat kan.

Die JSPs en Servlets maken ook netjes gebruik van de nodige httpheaders
welke caching kunnen sturen?

>> Hoe zit het bijvoorbeeld met afhankelijkheid van session
> > identifiers (cookies en/of session-id in URL),
[sessions in cookies]
> Het grootste gedeelte van de site veranderd maar eens per week, dit
> gedeelte krijgt ook de meeste bezoekers in 2 pieken per week.(die
> pagina's zijn dus gelijk voor alle bezoekers, ik wil dus dat de
> applicatie geen sessies aanmaakt in dit gedeelte, en ik wil dit gedeelte
> gaan cachen om die 2 pieken op te vangen).

Dat kan volgens mij zonder probleem, indien de "statische" paginas niet
met sessies doen, maakt het IMHO niets uit of er nu wel of niet reeds
een sessie bestaat voor de user. Zet dan ook nog eens wat zinnige
headers (oa last-modified, expires) en elke proxy zou niet veel meer
moeten vragen aan de servlet engine dan ofdat de pagina veranderd is
sinds.....

--

Daniel Tryba

Herbert Groot Jebbink:
>Het grootste gedeelte van de site veranderd maar eens per week, dit
>gedeelte krijgt ook de meeste bezoekers in 2 pieken per week.(die
>pagina's zijn dus gelijk voor alle bezoekers

Dat zou cacheable moeten zijn, zou je denken.

>Kijk vroeger, toen we nog applicaties in Cobol bouwden maakten we eerst
>een TO,

Waarvoor hulde!

>toen wisten we precies hoeveel I/O een programma per transaktie
>deed of hoeveel geheugen we gebruikten.

Hmm ja, dat waren nog eens tijden :-)

Wat verhindert je eigenlijk om met de degelijkheid van toen de
toepassingen van nu te bouwen?

>Nu gaat een applicatie live en na 3 kwartier gebruikt het 22 GB
>geheugen

Dat lijkt me niet goed. Ik zou de applicatie eerst eens kritisch
onder de loep nemen, alvorens er een reverse proxy voor te
hangen.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:

> Wat verhindert je eigenlijk om met de degelijkheid van toen de
> toepassingen van nu te bouwen?

poen, toen kregen we het wel voor elkaar om de planning/budget met met
een factor 2/3 te verhogen (ik ben een oud Volmac'er), de snelheid van
opleveren is wel enorm verhoogd, wat bij implementatie volgens mij meer
'verrassingen' oplevert dan vroeger, dan moet er ad-hoc oplossingen
gezocht worden. "Ok, dan gooien we er toch nog 4 GB ram in die bak" de
eerste reaktie van beheerders zoals mij op zulke momenten is "Complete
onzin om die 4 GB erbij te prikken, ze moeten beter programmeren", doch
als je naar een hogere kosteplaatje kijkt is het wel te doen.

>> Nu gaat een applicatie live en na 3 kwartier gebruikt het 22 GB
>> geheugen

> Dat lijkt me niet goed. Ik zou de applicatie eerst eens kritisch
> onder de loep nemen, alvorens er een reverse proxy voor te
> hangen.

is gebeurd, een audit door een derde partij (doch daar hebben links en
rechts mensen zo hun mening over, misschien moet er wel een audit van de
audit komen).

hgj

In-Reply-To: <bc2vf0$nr1$1@news.tue.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 51
Message-ID: <3ee5788a$0$49110$e4fe514c@news.xs4all.nl>
NNTP-Posting-Date: 10 Jun 2003 08:19:54 CEST
NNTP-Posting-Host: 213.84.248.72
X-Trace: 1055225994 news.xs4all.nl 49110 213.84.248.72:34525
X-Complaints-To: abuse@xs4all.nl
Xref: nl-news.euro.net nl.internet.www.server-side:29938

Daniel Tryba wrote:

>> hopelijk wel, kan spannend worden, er moet (een deel van) dynamische
>> content gecached gaan worden, gemaakt met JSP en servlets. De Websphere
>> Edge server zegt dat die dat kan.

> Die JSPs en Servlets maken ook netjes gebruik van de nodige httpheaders
> welke caching kunnen sturen?

zoniet dan moet dat zo gaan worden, men zat eerst zelf fanatiek allerlei
no-cache headers mee te sturen, zodat zelfs de locale browser niet meer
zat de cachen. Dit is op ons verzoek al veranderd, en als uit dit
verhaal blijkt dat dit weer veranderen moet dan vraag ik dat wel aan de
ontwikkelaars.

>>Het grootste gedeelte van de site veranderd maar eens per week, dit
>>gedeelte krijgt ook de meeste bezoekers in 2 pieken per week.(die
>>pagina's zijn dus gelijk voor alle bezoekers, ik wil dus dat de
>>applicatie geen sessies aanmaakt in dit gedeelte, en ik wil dit gedeelte
>>gaan cachen om die 2 pieken op te vangen).

> Dat kan volgens mij zonder probleem, indien de "statische" paginas niet
> met sessies doen.

:-(, sommige pagina's geven een stacktrace als er geen sessie cookie
binnenkomt, dat moet nog aangepast worden. Ons (beheer) inziens complete
onzin, er is logisch geen sprake van sessies (het is niet persoonlijk
ofzo), en technisch ook niet want alle variabelen gaan in dit gedeelte
via de URL.

> en elke proxy zou niet veel meer moeten vragen aan de servlet engine
> dan ofdat de pagina veranderd is sinds.....

Kan dat? Bij een statische pagina kijkt de webserver naar de timestamp
van die statische file, doch bij een servlet/jsp/php/perl/... pagina kan
de webserver deze check toch niet doen en vraagt toch elke keer aan de
servlet/... om die pagina opnieuw op te bouwen?

(nu ik erover na denk, die servlet/... kan natuurlijk kijken of de
"If-Modified-Since" header door de browser bij het verzoek is
meegestuurd, en als die datum minder dan xx minuten geleden is doodleuk
een 304 header retour geven ipv de pagina weer opbouwen, gossie als dit
werkt ga ik zometeen een paar PHP scripts aanpassen).

ik moet me nog in de echte diepe techniek van een reverse proxy
verdiepen, het lijkt me dat de afhandeling van de "If-Modified-Since"
header door de reverse proxy afgehandeld gaat worden en eigenlijk nooit
doorgestuurd naar de achterliggende server.

hgj

Herbert Groot Jebbink <hgj@xs4all.nl> wrote:
>> en elke proxy zou niet veel meer moeten vragen aan de servlet engine
> > dan ofdat de pagina veranderd is sinds.....
>
> Kan dat? Bij een statische pagina kijkt de webserver naar de timestamp
> van die statische file, doch bij een servlet/jsp/php/perl/... pagina kan
> de webserver deze check toch niet doen en vraagt toch elke keer aan de
> servlet/... om die pagina opnieuw op te bouwen?

Tuurlijk kan dat.

> (nu ik erover na denk, die servlet/... kan natuurlijk kijken of de
> "If-Modified-Since" header door de browser bij het verzoek is
> meegestuurd, en als die datum minder dan xx minuten geleden is doodleuk
> een 304 header retour geven ipv de pagina weer opbouwen, gossie als dit
> werkt ga ik zometeen een paar PHP scripts aanpassen).

Zelf genereer ik de output van intesieve scripts buiten een gebruiker
om, zeker indien je weet op welke momenten de content wordt geupdate.

> ik moet me nog in de echte diepe techniek van een reverse proxy
> verdiepen, het lijkt me dat de afhandeling van de "If-Modified-Since"
> header door de reverse proxy afgehandeld gaat worden en eigenlijk nooit
> doorgestuurd naar de achterliggende server.

De proxy dient IMHO altijd te controleren of de pagina inderdaad niet
gewijzigt is since.... het is dus van belang dat het SS script heel
eenvoudig kan achterhalen of de data (bv in de database _inclusief_
timestamp) gewijzigt is indien iemand een request doet inclusief
if-modified-since header, dus *heel makkelijk* is het waarschijnlijk
niet (ik heb me er ook nog nooit echt mee beziggehouden), maar ik
vermoed dat een expires header alweer een extra hint geeft (maar er zijn
vast nog vele andere headers om proxies een goede caching hint te
geven).

--

Daniel Tryba

Daniel Tryba wrote:

>>> en elke proxy zou niet veel meer moeten vragen aan de servlet engine
>>> dan ofdat de pagina veranderd is sinds.....
>>
>> Kan dat? Bij een statische pagina kijkt de webserver naar de timestamp
>> van die statische file, doch bij een servlet/jsp/php/perl/... pagina kan
>> de webserver deze check toch niet doen en vraagt toch elke keer aan de
>> servlet/... om die pagina opnieuw op te bouwen?
>
> Tuurlijk kan dat.

ok de webserver kan dus aan de de servlet/... vragen "Goh ik kan de
datum last modified niet bepalen doe jij dat eens?". Maar als de content
bv gebasseerd is op een database dan kan de servlet/... dit pas bepalen
nadat ie de hele meuk opgebouwd heeft, en dan heeft het weinig zin meer.
Of zoals je al zegt, er moet meta data bijgehouden worden betreffende de
update van de data in die database. Dat die servlet/... eerst die datum
vergelijkt met de "If-Modified-Since" header van de browser en dan een
304 header verstuurd indien de database sindsdien niet is bijgewerkt.

> Zelf genereer ik de output van intesieve scripts buiten een gebruiker
> om, zeker indien je weet op welke momenten de content wordt geupdate.

:-) kijk met jou kan ik praten, behalve een eventuele inzet van een
reverse proxy heb ik ook al een ander alternatief beschreven. De
WebServer en de AppServer zijn namelijk 2 verschillende machines. Dit
alternatief betreft het publiceren van .html files van de AppServer naar
de WebServer. En wel getriggerd door een 'publish' button in de admin
module, want hoewel de data maar eens per week wijzigt, is men bang dat
eventuele fouten een week lang online staan.

> De proxy dient IMHO altijd te controleren of de pagina inderdaad niet
> gewijzigt is since....

zoals je al voor een deel zegt, geld dit IMHO niet als de
oorspronkelijke pagina een expired header heeft meegestuurd die nog niet
vervallen is.

hgj