Reversed Proxy Servers

[Verwijderd]

Op dit moment verwerken we ongeveer 70 miljoen hits per dag op onze severs die de statische content verwerken. We lopen nu tegen het probleem aan dat onze fileserver dit niet direct meer kan verwerken.
De oplossing hiervoor lijken reverse proxies te zijn ipv standaard webservers (omdat die een cache bijhouden en de NAS ontlasten).

We zijn nu bezig met het testen van Squid onder een flinke load en het lijkt erop dat Squid een beetje ophoud bij 20mbit. Nadeel van Squid is dat het single-process is en dus geen gebruik maakt van onze multi-CPU systemen.

Zelf ben ik nu aan het kijken naar mod_proxy in Apache2, maar ik zou graag wat ervaringen horen van mensen die een niet (!) commercieel product gebruiken als reversed proxy (ook wel web accelerator genoemd).
Een NetCache van NetApp zou onze problemen in 1 keer oplossen, alleen hebben wij geen twee keer $30.000 over/liggen voor een tweetal NetCaches.

[Maarten @klet.st]

Verwijderd schreef op donderdag 17 maart 2005 @ 17:07:
We zijn nu bezig met het testen van Squid onder een flinke load en het lijkt erop dat Squid een beetje ophoud bij 20mbit. Nadeel van Squid is dat het single-process is en dus geen gebruik maakt van onze multi-CPU systemen.

knip

Een NetCache van NetApp zou onze problemen in 1 keer oplossen, alleen hebben wij geen twee keer $30.000 over/liggen voor een tweetal NetCaches.

Wat betreft de eerste opmerking: niet reverse haal ik iig snelheden tussen de 100 en 200mbit/s, single thread, single client. De beperking daarbij is de website of ftp-site aan de andere kant. In geval van caching is dit volgens mij gewoon de performance van het lokale FS. In ieder geval geen 20 Mbit/s.

Wat betref netcache: kijk eens op Ebay, daar staan best wat NetCache dozen de wellicht doen wat je wilt, voor een stuk minder dank 30K.

[ Voor 7% gewijzigd door Maarten @klet.st op 17-03-2005 22:15 ]

[Koffie]

Probleem is dat je in een zakelijke omgeving gewoon geen 2e hands spul wilt hebben, hoe geil of goedkoop die meuk ook is.
Zeker een site met 70 miljoen hits zou ik niet laten bedienen door een ebay 2ehandsje.

Overigens vraag ik me af waarom je met zoveel hits niet naar een commercieel product wil kijken ?

[Verwijderd]

Maarten.O schreef op donderdag 17 maart 2005 @ 22:14:
[...]


Wat betreft de eerste opmerking: niet reverse haal ik iig snelheden tussen de 100 en 200mbit/s, single thread, single client. De beperking daarbij is de website of ftp-site aan de andere kant. In geval van caching is dit volgens mij gewoon de performance van het lokale FS. In ieder geval geen 20 Mbit/s.
.

"Single Thread, Single Client"

Bedoel je hiermee Squid en 1 client workstation?
Met een standaard Apache2 installatie halen we makkelijk 50 tot 60 mbit vanaf het lokale FS en iets minder vanaf NFS. Misschien heb ik Squid niet genoeg getweaked om de gewenste performance te halen, dat kan natuurlijk ook.

Koffie schreef op vrijdag 18 maart 2005 @ 00:04:
Overigens vraag ik me af waarom je met zoveel hits niet naar een commercieel product wil kijken ?

We zouden het ons kunnen veroorloven, als het niet anders kan (maar dat zou een fikse aanslag op ons budget zijn)..
70 miljoen hits zijn trouwens puur statische files.Niet de pageviews. (oke, nog een hele hoop)

Tot nu toe hebben we het echter altijd gered met behulp van open-source en daar zijn we eigenlijk heel tevreden mee.
Met onze LVS loadbalancers trekken we met gemak meer dan 180mbit, iets wat een F5 of een Cisco niet beter had gekunt.

Als uiteindelijk echt blijkt dat een Netcache (of 2 voor de redundancy) de enige oplossing is dan zal het aangeschaft moeten worden. Ik ben er echter van overtuigd dat een Dell 1850 met Squid een veel hogere performance/prijs verhouding heeft dan een NetCache (ondanks de custom hard- en software, het eigen ontwikkelde WAFL FS met Raid 4 etc etc ).

Vandaar dit topic...

[JackBol]

Verwijderd schreef op vrijdag 18 maart 2005 @ 00:32:
Met onze LVS loadbalancers trekken we met gemak meer dan 180mbit, iets wat een F5 of een Cisco niet beter had gekunt.

kuche, kuche... uhm... dit betwijfel ik ten zeerste... sterker nog, ik durf te zeggen dat het klets is. Maar dat is niet het punt hier.

Wat wel een punt is is dat je een website hebt met 70 miljoen hits, en waarbij het je eigenlijk helemaal niet uitmaakt hoe available het is, als het maar cheap is...

Ik weet niet precies wat voor content er op de server draait, maar schijnbaar is het niet al te belangrijk...

[Arfman]

Dirk-Jan schreef op vrijdag 18 maart 2005 @ 08:52:
[...]Wat wel een punt is is dat je een website hebt met 70 miljoen hits, en waarbij het je eigenlijk helemaal niet uitmaakt hoe available het is, als het maar cheap is...

Lezen. Er worden 70 miljoen files geserveerd op een dag.

70 miljoen hits zijn trouwens puur statische files.Niet de pageviews. (oke, nog een hele hoop)

Ik weet niet precies wat voor content er op de server draait, maar schijnbaar is het niet al te belangrijk...

Dat is het waarschijnlijk dus wel.

[igmar]

Verwijderd schreef op donderdag 17 maart 2005 @ 17:07:
We zijn nu bezig met het testen van Squid onder een flinke load en het lijkt erop dat Squid een beetje ophoud bij 20mbit. Nadeel van Squid is dat het single-process is en dus geen gebruik maakt van onze multi-CPU systemen.

Squid kan, mits goed opgezet, een veelvoud ervan aan. Vertel squid dat ie epoll() moet gebruiken, en pak vooral een machine met een hele dikke sloot geheugen erin, en vertel squid dat ie dat moet gaan gebruiken.

Tuning is denk ik de oplossing hier

[Verwijderd]

Dirk-Jan schreef op vrijdag 18 maart 2005 @ 08:52:
[...]

kuche, kuche... uhm... dit betwijfel ik ten zeerste... sterker nog, ik durf te zeggen dat het klets is. Maar dat is niet het punt hier.

Dat is idd niet het punt hier en zie ook geen reden om dit verder te moeten 'bewijzen' ofzo..

Dirk-Jan schreef op vrijdag 18 maart 2005 @ 08:52:

Wat wel een punt is is dat je een website hebt met 70 miljoen hits, en waarbij het je eigenlijk helemaal niet uitmaakt hoe available het is, als het maar cheap is...

Ik weet niet precies wat voor content er op de server draait, maar schijnbaar is het niet al te belangrijk...

Wat heeft het gebruik van open-source te maken met het niet belangrijk vinden van je content?
Betekend dat dat SourceForge ook alles zo 'cheap' mogelijk wil, dat hun content niet belangrijk is?
Wij zien nou eenmaal meer in open-source.....

igmar schreef op vrijdag 18 maart 2005 @ 10:37:
[...]


Squid kan, mits goed opgezet, een veelvoud ervan aan. Vertel squid dat ie epoll() moet gebruiken, en pak vooral een machine met een hele dikke sloot geheugen erin, en vertel squid dat ie dat moet gaan gebruiken.

Tuning is denk ik de oplossing hier

Ik vond 20 mbit ook al zo weinig.
Ik ga kijken naar epoll() en wat extra geheugen in de 1850's stoppen...

[Maarten @klet.st]

Verwijderd schreef op vrijdag 18 maart 2005 @ 00:32:
[...]
"Single Thread, Single Client"
Bedoel je hiermee Squid en 1 client workstation?
Met een standaard Apache2 installatie halen we makkelijk 50 tot 60 mbit vanaf het lokale FS en iets minder vanaf NFS. Misschien heb ik Squid niet genoeg getweaked om de gewenste performance te halen, dat kan natuurlijk ook.

Ja, dat was 1 (windows) client naar 1 URL door de squid server heen.
Met 4 clients met elk 6 threads:

code:

[maarten@cinderella] ~# ifstat 10
       eth0
 KB/s in  KB/s out
 2625.75   2578.29
ifstat: warning: rollover for interface eth0, reinitialising.
    0.00      0.00
19096.00  19231.68
26229.56  26322.32
27151.02  27224.65
26843.54  26858.77

Dat is dus ruim 200mbit/s, waarbij nog niet gecached wordt.

Dezelfde test (4 clients, elk 6 threads) met caching:

code:

[maarten@cinderella] ~# ifstat 10
       eth0
 KB/s in  KB/s out
   12.88     13.02
  368.85  16574.89
  435.04  26192.81
  793.15  40280.06
  713.01  41784.57
 1168.78  52208.70
 1368.05  56147.70

Als squid 'reverse' hetzelfde werkt als 'normaal', dan zou je dus redelijke winst moeten kunnen behalen, er van uitgaande dat de performance niet instort als het aantal threads enorm toeneemt (zoals in jouw geval zal zijn, vermoedelijk veel concurrent website bezoekers).

En dat het goede nieuws: dit is (qua squid) een standaard Redhat 8.0 installatie op
een Dell PE1750 met squid-2.4.STABLE7-4 als rpm. De configfile is wel redelijk (niet enorm) getweaked. Tot mijn schrik zie ik dat squid hierbij maar 180MB geheugen gebruikt, waar er 1 GB beruikbaar is. Het OS lijkt de rest van het geheugen wel als buffer te gebruiken. De cache partitie bestaat uit 2 36GB 15K rpm scsi disks in RAID 0.

[...]
We zouden het ons kunnen veroorloven, als het niet anders kan (maar dat zou een fikse aanslag op ons budget zijn)..
70 miljoen hits zijn trouwens puur statische files.Niet de pageviews. (oke, nog een hele hoop)
Tot nu toe hebben we het echter altijd gered met behulp van open-source en daar zijn we eigenlijk heel tevreden mee.
Met onze LVS loadbalancers trekken we met gemak meer dan 180mbit, iets wat een F5 of een Cisco niet beter had gekunt.
Als uiteindelijk echt blijkt dat een Netcache (of 2 voor de redundancy) de enige oplossing is dan zal het aangeschaft moeten worden. Ik ben er echter van overtuigd dat een Dell 1850 met Squid een veel hogere performance/prijs verhouding heeft dan een NetCache (ondanks de custom hard- en software, het eigen ontwikkelde WAFL FS met Raid 4 etc etc ).
Vandaar dit topic...

Mijn vingers jeuken om op sommige posters te reaggeren die beweren dat OSS oplossingen (altijd..) minder goed functioneren dan professionele A merk oplosingen.

Ik heb niets tegen A merk oplossingen (al helemaal niet van Network Appliance), maar vind persoonlijk dat je ZELF per situatie moet inschatten of het een OSS project wordt (waar je zelf wellicht meer ontwikkeltijd in stopt) of een A-merk oplossing die meestal meer investering in geld kost. Hetzelfde voor 2e hands spul van ebay, de een doet het wel (desnoods met tweede apparaat als cold spare), de ander heeft liever gloednieuw spul met support. Ieder zijn keuze, lijkt me..

[Verwijderd]

igmar schreef op vrijdag 18 maart 2005 @ 10:37:

Vertel squid dat ie epoll() moet gebruiken.

Ik heb er zojuist naar gekeken en als ik het goed begrepen heb werkt epoll() alleen met Squid 3.0?
In hoeverre is dit stabiel en inzetbaar in een productie omgeving?

[Verwijderd]

Verwijderd schreef op maandag 21 maart 2005 @ 11:24:
[...]


Ik heb er zojuist naar gekeken en als ik het goed begrepen heb werkt epoll() alleen met Squid 3.0?
In hoeverre is dit stabiel en inzetbaar in een productie omgeving?

Laat ik het zo zeggen. Er is op dit moment zelfs geen PRE release van Squid 3.0 die niet obsolete is. Zegt volgens mij genoeg.

[Hans]

Wij maken voor een aantal React based fora en sites met succes gebruik van mod_proxy (sinds kort icm mod_cache).

Setup is een Foundry Serveriron loadbalancer met daarachter een aantal web frontends welke allen 2 instances van apache draaien. voor de buitenwereld een apache2 welke de relatief high-latency client verbindingen afhandelt, statische content serveert en sinds kort tevens cached dmv mod_cache/mod_disk_cache. requests voor dynamische content worden gereverse-proxied naar de 2e apache instance welke gebind is op localhost. Dit is apache 1.3.x met php-4.3.x. en eaccelerator.

Database server is een dual opteron 246 machine met 6 GB geheugen en SCSI RAID level 10 dmv de LSI MegaRAID 320-2

Document root bevind zich op een grote centrale fileserver en is mounted mbv NFS. de NFS server kan het allemaal met gemak verstouwen, mede omdat alle web frontends het gros van de data gecached hebben op local disk (php files compiled in eaccelerator cache, veel gerequeste pages en images in mod_cache). Moet wel zeggen dat wij geen 140 Mbit verstoken

[Verwijderd]

Onze opzet is nu alsvolgt:

2x LVS loadbalancers die de load verdelen over 2 pools. Een pool voor de dynamische content en 1 voor de statische.
De dynamische pool bestaat uit 16 webservers met apache 1.3 en php4 (en php_accelerator)
De statische pool zijn nu 3 webservers met apache2.
De databaseserver is een dual 3.0 Ghz Xeon met 6Gb geheugen en een raid 10 data array.(Op het moment dat wij het Mysql cluster draaiende hebben van emic worden dit er 4. Replication is te onbetrouwbaar op dit moment)

De fileserver wordt ook bij ons via NFS gemount en trekt het op dit moment niet meer om alle statische content live te serveren. (LSI Megaraid2, 1 raid 10 array voor de php files en 1 raid 10 array voor de statische content + 2 system disks natuurlijk)

Ik heb nu een 4e webserver in de statische content pool geplaatst met een lagere weight, zodat deze langzaam aan zijn cache kan vullen.
Het punt is dat zowel Squid als Apache2 met mod_proxy en/of mod_cache (zowel mem_cache voor de kleine bestanden als disk_cache voor de grotere) bij lange na niet de performance haalt van een Apache2 webserver die zijn data direct op de NFS ophaalt. Misschien dat ik de mem_cache pool te groot heb zitten en zal deze eens wat verkleinen om te kijken of dit effect heeft. (is nu 1.6Gb van de 2.0Gb in de bak, er blijft dan idd weinig over voor Apache, Squid lijkt minder nodig te hebben)

'Metered' verstoken wij nu 100mbit en pieken naar een flink hoger getal..

Mochten er mensen tips hebben dan zijn ze zeker welkom.
Als ik vooruitgang boek zal ik dit hier ook melden (al was het maar voor de search)

[Verwijderd]

wij zijn nu ook bezig met squid als reversed proxy.
vandaar dat ik ook op dit forum ben gekomen.

momenteel kunnen ze zo'n 350 hits per seconde aan.
wat voor ons neer komt op 5 tot 10Mbit troughput.
dit is niet erg veel, maar we hebben ook een pool van +/- 3 miljoen files van niet groter dan 50k voor de potentiele cache (give or take a million).

maar ik heb ook het idee dat er nog veel te halen valt.
misschien dat we er een keer over kunnen praten?

Ik ben ook erg benieuwd wat voor tweaks jullie hebben gemaakt op je mysql servers, aangezien dit ons volgende probleem gebied is.

[Verwijderd]

offtopic:
critpizza, ik heb je even toegevoegd op msn

Ik ben er op dit moment van overtuigd dat we te maken hebben met teveel files, waardoor het caching mechanisme niet goed werkt.

Een Squid bak doet op dit moment 50% van de bandbreedte naar zowel het internet als de fileserver, wat er op neerkomt dat het dus eigenlijk gewoon helemaal niet werkt/cached. (terwijl de disk-cache wel wordt gevuld).

[Verwijderd]

Een cache werkt alleen als de files die erin staan ook daadwerkelijk regelmatig worden opgevraagd.
Het aantal en grote van de files maakt op zich niet zoveel uit, mits je maar een scheiding ziet tussen files die regelmatig worden opgevraagd en files die vrijwel nooit worden opgevraagd.

Als je 3.000.000 X 50 kb aan files hebt (150 GB) en daarvan wordt 10% regelmatig opgevraagd, zou je met een cache van 20GB een heel eind moeten komen. Een cache van 1.6GB heeft in zo'n situatie dan ook waarschijnlijk weinig nut. In het overgrote gedeelte van de gevallen zal de file die wordt opgevraagd dan namelijk niet in de cache zitten.

[Verwijderd]

Dat snap ik, maar met een hit-ratio van > 80% snap ik niet WAAROM squid nog zoveel opvraagt aan de fileserver

squid nu 8mbit naar internet, 3 mbit naar fileserver,
apache2 nu 25mbit naar inet, 6 mbit naar fileserver

squid gebruikt eenzelfde apache2 installatie als back-end, met mod_expires ed.

code:

Cache information for squid:
    Request Hit Ratios: 5min: 81.8%, 60min: 80.8%
    Byte Hit Ratios:    5min: 55.3%, 60min: 54.5%
    Request Memory Hit Ratios:  5min: 21.9%, 60min: 21.0%
    Request Disk Hit Ratios:    5min: 28.6%, 60min: 30.7%
    Storage Swap size:  1512760 KB
    Storage Mem size:   131128 KB
    Mean Object Size:   28.43 KB
    Requests given to unlinkd:  50

[nielsj]

kan het zijn dat sommige delen van je content te groot is, en dat de squids ze niet cachen?

verder hebben bij dual cpu machines wel een idee om 2 squid processes te draaien, dat verdubbelt bijna de het aantal cacheing requests, mits je content niet te verschild (en in je geheugen past).

succes

[Verwijderd]

Iets van 45% van de bytes die opgevraagd worden zit niet in de cache en moet bij de fileserver opgehaald worden. 8*.45 = 3.6 Dat komt redelijk in de buurt van wat jij aangeeft

[ Voor 21% gewijzigd door Verwijderd op 10-04-2005 14:20 ]