Re: [OT] Apache 32bit vs 64bit
N'Abend Markus,
Am Mittwoch, den 03.09.2008, 23:42 +0200 schrieb Markus Schulz:
> Am Mittwoch, 3. September 2008 schrieb Thomas Halinka:
> > Hallo Hagen,
> >
> > Am Mittwoch, den 03.09.2008, 15:04 +0200 schrieb Hagen Montag:
> > > Ich will mal meinen Senf dazu geben und mit einem Mythos
> > > aufraeumen:
> > >
> > > On Wed, Sep 03, 2008 at 02:39:35PM +0200, Jochen Schulz wrote:
> > > > > Hmm okay, es handelt sich hierbei allerdings um eine
> > > > > Shopanwendung, die aktuell ca 900 conncurrents bedient. diese
> > > > > 900 concurrents kosten mich aktuell ca 5GB und ca 70%-CPU.
> > > >
> > > > Möglichkeiten beim Apache:
> > > >
> > > > - KeepAlive einschalten, falls nich nicht geschehen. Das kann Dir
> > > > viele Forks / Threaderzeugungen pro Sekunde einsparen.
> > >
> > > KeepAlive ausschalten, so ein Thread ist schnell erzeugt und du
> > > sparst Dir die 900 konkurrierenden, die meist schlafen und das
> > > System zumllen. Schafft unheimlich Erleichterung auf Serverseite.
> >
> > Cool, anstatt vorher ~300 MB für den Apachen brauch er nun nur noch:
> >
> > ps -eo rss,args --sort rss | grep apache | awk '{ SUM += $1} END {
> > print SUM/1024 }'
> > 62.6523
> >
> >
> > thanx für den hint ;)
>
> na ja ich finde den Tipp Quark, die Client Performance sinkt dadurch
> nämlich. Pro Element der HTML Seite macht der Browser ne neue
> Connection auf und die Latenz auf Client Seite steigt dadurch auf jeden
> Fall. Wenn dann maximal das KeepAlive verkürzen (heutige DSL Clients
> brauchen nur wenige Sekunden für die Elemente einer Webseite).
> Desweiteren einfach mal den Server-Status von Apache im Auge behalten
> und schauen wieviele Instanzen maximal parallel benutzt werden.
>
> Deine Speichermessung ist auf jeden Fall ungünstig, wie soll solch eine
> einzelne Messung denn vergleichbar sein zu verschiedenen Zeitpunkten?
Der Speicherverbrauch von ca 300 MB (560 User), bei den 62MB (521 User)
--> daher vergleichbar, da diese 40 User nicht soooviel ausmachen
können. subjektiv wurde das surfen hier nicht langsamer?!
>
> Man muss einfach testen was man pro Apache (durch die jeweilige
> Web-Anwendung)
Wie ich mittlerweile rausgefunden ist der Apache an sich NICHT das
Problem, das dieser nur ein CGI ausliefert, was den User wiederum an den
eigentlichen Shop (C-Binary) leitet. Pro User und Session habe ich dann
eben 2 Prozesse im System hängen, die pro User ca 10 MB ausmachen.
Quasi:
Client --> Apache --> CGI --> C-Binary
und eben dieses Binary hab ich eben als 32bit oder 64bit - bei 32bit
10MB/User/Session und bei 64bit 14Mb/User/Session
# file /home/shop/bin/shop
/home/eos/bin/ead32: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), for
GNU/Linux 2.4.1, not stripped
> an Speicher braucht und überschlagen wieviele Nutzer
> gleichzeitig handle-bar sein sollen
Aktuell 900 Concurrents zu Peakzeiten und zum Weihnachtsgeschäft wird
aufgrund der Erfahrungen der letzten mit ca/mind 30% Mehr
Besuchern/Shop-Usern gerechnet
> und entsprechend viel Speicher
> parat haben.
10 MB x 1200 User = 12GB als 32bit-Applikation
14 MB X 1200 User ~ 17GB als 64 bit
> Ich habe übrigens bisher nur schlechte Erfahrung (mehr
> Speicherverbrauch ohne spürbaren Performance Gewinn) mit Apache auf
> 64Bit gemacht und würde bei einem LoadBalancer Setup (pound, apache,
> squid) immer auf 32Bit Backends zurückgreifen.
Das war ja meine ursprüngliche Frage, da ja der Speicherverbrauch
eklatant groß ist und mittels Load-Balancer kann ich ja an beliebig
viele "Lamp-knoten" verteilen.
Daher nochmal die Frage:
Aufgrund obiger Zahlen treibt es mich eher in Richtung 6 x 32bit-LAMP a
4GB RAM (auf 2 Hosts) und Load-Balancer vornedran
oder
2 64Bit-LAMP a 12 GB und Load-Balancer
Wo ist denn mehr "Bums" zu erwarten? :)
>
> --
> Markus Schulz
Grüße
Thomas
Reply to: