[BC3] httpd acceleratie

[Kees]

HTTPD acceleratie, oftewel, laat de statische files afhandelen door een zeer kleine/snelle webserver en de dynamische (php) paginaas door bijv. apache.

Dit is wat ik wil, en er zijn zeker een aantal alternatieven, deze hebben allemaal hun nadelen, dus mji vraag, wie weet er nog meer programma''s / methodes.

bekeken progs:
khttpd:
- snel
- makkelijke config
- zit standaard in 2.3.hoog en 2.4.x kernels.

- niet stabiel
- alleen virutele servers met een patch

phhttpd:
- snel
- redelijk stabiel
- virtuele servers

- vereist aanpasssingen aan de andere webserver
- geen actieve development

squid (transparante proxy):
- het werkt redelijk

- lastig configgen
- performance laag (iig zeker niet de performance van khttpd bijv)

mod_rewrite
- performance hit?

dhttpd/dhttpc/thttpd:
- geen actieve development


Dus wat ik zoek:
- een programma dat de http-requests afhandeld
- statische requests zelf doet (en niet in de user-space, maar mbv de kernel)
- dynamische files doorstuurt naar zijn grote broer (in dit geval meestal apache)
- stabiel is en een actieve development heeft, of iig werkt met de laatste apachewebservers.

weet iemand anders nog een trick of een goed programma?

[Dennis]

Komt dit dan voor gebruik op GoT?

[Kees]

als het stabiel en goed werkt, jah.

[Dennis]

Op vrijdag 18 mei 2001 21:16 schreef Kees het volgende:
als het stabiel en goed werkt, jah.

Maar vrijwel alle pagina''s zijn toch dynamisch op GoT?
Of wil je een optie dat je in de requests kunt lezen of bijv. data is gesubmit?

[Ikarus]

Dit is primair bedoelt om images te serven, zou veel schelen volgens kees (wat ook logisch is aangezien iedere apache child een
persistent connection naar MySQL heeft)

[ACM]

Heb je nog naar Tux van redhat gekeken?
Das (volgens C''T) wel redelijk stabiel, kweet alleen niet of het echt lekker in een niet-redhat omgeving draait.

[Ikarus]

Support tux proxying dus dynamische requests door stuuren (die luie kees zit tv te kijken )

[Ikarus]

Hmmm, zo te zien wel, ff kees wakker meppen via IRC, mag ie weer wat gaan uit proberen

[Kees]

ja hallo, als the Nutty Professor op tv is ben ik ff tv kijken hoor

Maar ik zal tux inderdaad eens gaan bekijken, deze is er inderdaad een beetje tussendoor geschoten, had er wel over gehoord maar nog niet naar gekeken

[Femme]

Hoe zit dat met het doorsturen van dynamische pagina''s? Snapt zo''n khttpd of TUX dat http://www.tweakers.net/nieuws/16967 dynamisch is maar http://tweakers.net/ext/i/990139601.gif niet? (wat hij in feite moet doen is alles dat niet de extentie .jpg, .png, .gif, .css of .js heeft doorsturen naar Apache).

[ACM]

Op vrijdag 18 mei 2001 22:45 schreef Femme het volgende:
Hoe zit dat met het doorsturen van dynamische pagina''s? Snapt zo''n khttpd of TUX dat http://www.tweakers.net/nieuws/16967 dynamisch is maar http://tweakers.net/ext/i/990139601.gif niet? (wat hij in feite moet doen is alles dat niet de extentie .jpg, .png, .gif, .css of .js heeft doorsturen naar Apache).

Ja dat kan je instellen, sterker nog.
Alle requests die ie niet kan vinden gaan linea-recta naar [vul hier je backup-httpd in]

En je kan bij khttpd bijv (en vast bij tux ook) instellen dat ie alles waar een ? inzit direct door moet sturen.

Ik heb zoiets als daarboven server/bla/bla/var1/waarde1/var2/waarde2 etc inderdaad es getest en dat werkte nog gewoon.
(werd dus door apache naar behoren opgevangen)

[Kees]

jah, je kunt strings opgeven waaraan hij ziet of het dynamic is of niet.

.php .dsp .fok .cgi etc, ook controleert hij of ? erin zit. if so -> apache

tux blijkt toch wel erg redhat-only te zijn en eig. te uitgebreid (uitgebreider = onstabieler over het algemeen, ''t is een relatief nieuwe ontwikkeling, dus ik wil niet al te veel opties die onstabiel kunnen zijn )

[ACM]

Op vrijdag 18 mei 2001 22:56 schreef Kees het volgende:
tux blijkt toch wel erg redhat-only te zijn en eig. te uitgebreid (uitgebreider = onstabieler over het algemeen, ''t is een relatief nieuwe ontwikkeling, dus ik wil niet al te veel opties die onstabiel kunnen zijn )

''t Was maar een idee

Maar is het niet gewoon handiger om een "snelle" static webserver (dus niet apache) te bouwen, die als images.tweakers.net oid draait?
Enige wat ie dan moet kunnen is virtualhosting en verder niks?

[Kees]

das ook een optie, maar dan moet je best veel scripts ombouwen.

ik zie het alleen als een oplossing als bovenstaande niet werkt

[Verwijderd]

En gewoon veel childs openzetten std. in apache wil ook erg helpen

[ACM]

Op vrijdag 18 mei 2001 23:09 schreef Kees het volgende:
das ook een optie, maar dan moet je best veel scripts ombouwen.

ik zie het alleen als een oplossing als bovenstaande niet werkt

Das ook weer zo, maar op den duur is het misschien wel beter om die scheiding aan te brengen...

Succes iig verder, ik ben te lui geweest om khttpd goed in te stellen (is gecompiled etc, maar staat nog uit ) anders had ik het al een weekje kunnen testen.

[Kees]

ik kan je wel zeggen: probeer het eens (met de virutal-server patch) en herstart het een keer of 5, dan ligt je hele linux-box op zijn gat

[ACM]

Laat maar dan
Ik heb die bak liever niet onderuit...
(Moet ik tot maandag wachten tot ie gereset kan worden)

Maar er staat niet voor niet "EXPERIMENTAL" in de kernel-docs bij khttpd

[ACM]

Op vrijdag 18 mei 2001 23:23 schreef sproggle het volgende:
En gewoon veel childs openzetten std. in apache wil ook erg helpen

Volgens mij wil je juist zoveel mogelijk gebruik maken van veel en snelle caching, gebeurt dat dan ook?

[Verwijderd]

17Mbit continu uit 1 server waar op voor totaal aan nog geen 20Mb aan filmpjes staat. Zegt dat genoeg?

[ACM]

Op vrijdag 18 mei 2001 23:30 schreef sproggle het volgende:
17Mbit continu uit 1 server waar op voor totaal aan nog geen 20Mb aan filmpjes staat. Zegt dat genoeg?

Is dat alles wat je er uit kan persen?

Dat kan wel beter toch?
Mijn bakje kan met index.php''tjes al meer outputten. (mja ik ben nog steeds een beetje enthousiast erover, is ook nog steeds een 2x-p3-800 en die staat er net een week)

[Ikarus]

Op vrijdag 18 mei 2001 23:23 schreef sproggle het volgende:
En gewoon veel childs openzetten std. in apache wil ook erg helpen

Leuk idee ware het niet dat iedere child een persistent connectie naar de DB open trekt, en dat is juist wat er vermeden moet worden, de webservers kunnen het aan de DB ook, maar de connecties er tussen :`(

[Verwijderd]

Op vrijdag 18 mei 2001 23:33 schreef ACM het volgende:
Is dat alles wat je er uit kan persen?

Dunno, maar het zal moeten. Diezelfde machine moet naar de 40Mbit toe binnen nu en een maand.

[ACM]

Op vrijdag 18 mei 2001 23:36 schreef Ikarus het volgende:
Leuk idee ware het niet dat iedere child een persistent connectie naar de DB open trekt, en dat is juist wat er vermeden moet worden, de webservers kunnen het aan de DB ook, maar de connecties er tussen :`(

''t Ging toch juist om images en andere static zooi?
Of willen jullie de acceleratie proberen op te zetten voor _alle_ servers?

[Macros]

Jaja ACM, we weten nu wel van die dual P3 800 met 512 meg aan ram etc etc en zijn dedicated database server bla bla

Maar met alleen filmpjes moet hij wel de netwerkkaart (als het geen gigabit kaart is tenminste) vol kunnen trekken.

[Verwijderd]

Op vrijdag 18 mei 2001 23:36 schreef Ikarus het volgende:

[..]

Leuk idee ware het niet dat iedere child een persistent connectie naar de DB open trekt, en dat is juist wat er vermeden moet worden, de webservers kunnen het aan de DB ook, maar de connecties er tussen :`(

We hebben het hier toch over statische content en caching ensow? Dus die database connecties blijven helemaal achterwege

[ACM]

Op vrijdag 18 mei 2001 23:37 schreef Macros het volgende:
Maar met alleen filmpjes moet hij wel de netwerkkaart (als het geen gigabit kaart is tenminste) vol kunnen trekken.

Hehe
Ik denk dat ie zelfs richting de gigabit wel aardig meekan (lang leve serverworks )

[Verwijderd]

TUX is dan wel RH maar het is toch wel errug snel.
(Zie de laatste benchmark resultaten op http://www.spec.org/osg/web99/results/res2001q2/)

Ik heb TUX 1.0 hier wel eens draaiend gehad om mee te spelen en ik moet zeggen... dat gaat best goed samen met Apache. Het ziet er naar uit dat met 2.0 het configureren nog steeds een eitje is. (Zie http://www.redhat.com/support/manuals/TUX-2.0-Manual/index.html)

Heeft iemand trouwens de Apache 2.0 beta al eens geprobeerd?

[Verwijderd]

Op vrijdag 18 mei 2001 23:44 schreef Macros het volgende:

[..]

Alleen de HD''s niet echt

Geheugen?

[Macros]

Op vrijdag 18 mei 2001 23:38 schreef ACM het volgende:

[..]

Hehe
Ik denk dat ie zelfs richting de gigabit wel aardig meekan (lang leve serverworks )

Alleen de HD''s niet echt

Ik heb niet alles gelezen, maar deze 2 eisen sluiten elkaar een beetje onwijs uit:

- een programma dat de http-requests afhandeld
- statische requests zelf doet (en niet in de user-space, maar mbv de kernel)

Als het een programma moet zijn, hoe kan het dan in kernel space draaien? Dan is het een kernel module.

[ACM]

Op vrijdag 18 mei 2001 23:46 schreef sproggle het volgende:
Geheugen?

Mwoh, 133Mhz gehuegen kan wel meer dan 100MB/seconde trekken toch??

[The Source]

Aardig artikel over tux...

Strijd der giganten
C''T oktober 2000
p38 - 41


Ook nog linkje:
http://www.specbench.org/osg/web99/

[Kees]

Op vrijdag 18 mei 2001 23:44 schreef Macros het volgende:
[..]

Als het een programma moet zijn, hoe kan het dan in kernel space draaien? Dan is het een kernel module.

I stand corrected
anders formuleren dan:
- Een stuk code dat de http requests afhandeld, zelf de statische files serveert en de dynamiek doorgeeft aan apache
- het liefst een stuk code dat in de kernel zelf draait (idd mbv modules/built-in)

[ACM]

Imho is het vaak veel makkelijker om macros te negeren
En gewoon doorgaan met de topic (ok, dan ken ik hem ook persoonlijk, dus weet ik iets beter met hem overweg te gaan)

Maar meer opties dan de bovengenoemde zijn er denk ik niet.
Voor khttpd stabiel is zitten we wel bij 2.4.15 ofzo?
En tux zal wel nog meer "redhat-only" worden.

[Verwijderd]

Als het uiteindelijke doel is om het aantal
MySQL connecties te reduceren is LingerD
misschien wel wat:

http://www.iagora.com/about/software/lingerd/

of natuurlijk ''images.tweakers.net''

Gebruikt Tweakers overgens iets als
Alternative PHP Cache (http://apc.communityconnect.com)
of BWARE Afterburner ? (http://bcache.bware.it - I think )

Niet dat die helpt met connecties oid,
maar just curious

-- KePZ

[ACM]

Zowel met apc als met bware crashte mijn php, dus beide opties zijn niet echt stabiel
Het gaat denk ik vooral om static content.
En dan is het stabielst een losse images server (slashdot en freshmeat hebben dat ook)bijkomend voordeel is wel, dat je daar evt ook je GoT usericons allemaal op kan planten

[Ikarus]

Okay, wie hier heeft er zin om zonder betaling en zonder rechten er aan te kunnen verlenen door de t.net source te struinen en alle image urls te vervangen en ook ff iets maken dat 100% zeker alle image vermeldingen in de DB wijzigt (oftewel losse image server is een rot klus...)

[ACM]

Op zaterdag 19 mei 2001 18:03 schreef Ikarus het volgende:
Okay, wie hier heeft er zin om zonder betaling en zonder rechten er aan te kunnen verlenen door de t.net source te struinen en alle image urls te vervangen en ook ff iets maken dat 100% zeker alle image vermeldingen in de DB wijzigt (oftewel losse image server is een rot klus...)

Meen je dat nou?
Ik bedoelde dan ook "odd" gewoon topix verplichten alle image-urls met een $parameter_prefix uit te rusten.
En in t.net/fokzine etc ook.

Maar het leuke is, je maakt die image server.
Je zet alle plaatjes (usericons lijkt me niet zo moeilijk?) daarop.
En bij _alle_ nieuwe aanpassingen laat je ook de images op de images server. Voor alle huidige afbeeldinkjes blijf je gewoon de huidige setup gebruiken.

Nadeel is dat je een tijdlang dubbelop bezig bent, voordeel is dat je uiteindelijk wel de scheiding aan kan brengen, maar gewoon lekker rustig aan doet.
Ik neem bijvoorbeeld aan, dat alle "standaard" got plaatjes op niet meer dan 5 plekken in de code hardcoded zullen staan?
odd = op den duur

[Kees]

http://mathop.diva.nl/

kent iemand deze server?

[ACM]

Wel een hoop uitleg op hun site...
Ik zou me er niet zomaar aan wagen met zo weinig uitleg.

[Verwijderd]

Je kunt altijd nog ff de source doorspitten of lid worden van de mailing list

[Kees]

ik doe beide al

[ACM]

Succes dan, hopelijk is het wat.
Maar dit is toch geen accelerator?
Wil je toch iets als mijn uitleg voor een images server doen?

[Kees]

ik denk dat ik dan iets met mod_rewrite ga doen
ziet er wel ingewikkeld uit, maar het moet toch mogelijk zijn om http://*.*.*/*.gif naar http://localhost:8080/*.gif door te sturen.
maar we zien het wel
ik heb het iig binnen een uur draaiende, en het loopt nog steeds
ik ga morgen nog meer testen (met apachebench oid) en dan zien we wel hoe stabiel of dat hij nu werkelijk is.

[Wirf]

Op zaterdag 19 mei 2001 18:03 schreef Ikarus het volgende:
Okay, wie hier heeft er zin om zonder betaling en zonder rechten er aan te kunnen verlenen door de t.net source te struinen en alle image urls te vervangen en ook ff iets maken dat 100% zeker alle image vermeldingen in de DB wijzigt (oftewel losse image server is een rot klus...)

Je kunt vast een of andere regex of C++ progsel maken dat dat auutomatisch doet..

iets van s/http://GoT/.*[.jpg|.gif]/http://images.GoT/$PATTERN/g maar dan nog net iets anders...

als je echt zoiets wilt doen, wil ik eventueel wel helpen

[Femme]

Met search&replace in homesite kun je ook al een heel eind komen .

[ACM]

Vergis je nou niet kees, als je eerst apache met mod_rewrite eraan laat morren heb je alle performance winst wel verloren denk ik.

[Kees]

Op maandag 21 mei 2001 09:28 schreef ACM het volgende:
Vergis je nou niet kees, als je eerst apache met mod_rewrite eraan laat morren heb je alle performance winst wel verloren denk ik.

daar gaat het primair niet eens om, bovendien, op deze manier (met mod_rewrite) kun je het op den duur in de scripts ook omzetten (er is dan geen "deadline", er is een ongemerkte overgang).

meer belangrijk is dat er minder requests door apache worden gedaan (en apache dus minder threads open hoeft te hebben). In de top 35 meest aanrequested files in de logs zitten 33 statische files, get my point?

van de 540.795 requests zijn er 342.844 voor de top35, hiervan is ~10k niet statisch.
dus ongeveer 60% is statisch.

[Verwijderd]

Is het niet handiger om een manier te verzinnen (voor GoT bijvoorbeeld) om forum threads te cachen...Dan kan steeds de gecachte draad opgestuurd worden naar de bezoeker die geupdate wordt als er iets veranderd in een thread...Voor mensen die alleen lurken hoeft er dan geen database connectie gemaakt te worden...

[ACM]

kees: ok, dan snap ik het
Is dus een vergelijkbare oplossing met wat ik aan droeg voor de overgang, alleen dan transparanter.

Ga alleen liever niet met andere dan poort 80 stoeien als het even kan.

En dat er veel static requests inzaten verwachte ik al

[Wirf]

Op maandag 21 mei 2001 13:19 schreef fkooman het volgende:
Is het niet handiger om een manier te verzinnen (voor GoT bijvoorbeeld) om forum threads te cachen...Dan kan steeds de gecachte draad opgestuurd worden naar de bezoeker die geupdate wordt als er iets veranderd in een thread...Voor mensen die alleen lurken hoeft er dan geen database connectie gemaakt te worden...

ja, zoiets van:

-Als er geupdate word, maak je de statische pagina opnieuw
-Als er een pagina gerequest word, pak je de statische pagina

dan nog khttpd of tux erbij en je hebt een kick-aars snel forumpje....

paar problemen alleen:

-users prefs (wat ga je doen als iemand 50 reacties op een pagina wil, ipv 25?)
-zoeken (kan evt. nog op de normale "oude" manier)
-Vrij lastig te maken

[ACM]

Simpelweg een dedicated image server is een _stuk_ makkelijker en verlicht de apache-servers ook al een hoop

[ACM]

Ik zal hem hier ook nog even posten
Misschien is boa iets?

[Theodoor]

Je kunt ook gewoon Michiel Boland mailen over Mathopd. Hij is de systeembeheerder bij DiVa BV. Zijn e-mailadres is [e-mail]