Thomas Halinka:
> Am Mittwoch, den 03.09.2008, 11:54 +0200 schrieb Jochen Schulz:
>>
>> Wachstum? Meinst Du mehr Traffic? Macht der Server noch was anderes
>> (also auch Webanwendungen)? -Mit dem Ausliefern statischer Daten
>> bekommt man doch keinen Server mehr ausgelastet....
>
> 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.
Ich behaupte aber weiterhin, dass der Apache von diesen 70% nur einen
Bruchteil ausmacht. Da kommst Du nicht viel weiter.
Möglichkeiten beim Apache:
- Statischen Content von einem komplett anderen System ausliefern
lassen. Das bringt dem User auch mehr "gefühlte" Geschwindigkeit, weil
die Clients von beiden Servern parallel ziehen.
- KeepAlive einschalten, falls nich nicht geschehen. Das kann Dir viele
Forks / Threaderzeugungen pro Sekunde einsparen.
- mod_gzip u.ä. abschalten. Kostet Bandbreite und Slots auf dem Apache,
entlastet aber die CPU ein wenig.
- SSL sparsam benutzen.
Bei dem Shopsystem selbst:
- DB auf andere Maschine auslagern (falls nicht sowieso geschehen).
- Caching-Möglichkeiten. (SCheinst Du ja mit dem Reverse-Proxy schon zu
probieren, aber kann Deine Anwendung das nicht?)
- Anzahl der Hits auf den Application Server reduzieren (AJAX-Spielzeug,
serverseitige Includes, Checkout-Prozess...)
- Wie schon von Dir selbst vorgeschlagen: mehr Server für den Shop, mit
Loadbalancer davor (falls Deine Anwendung sowas nicht mitbringt, ist
hier der Fall). Der Loadbalancer muss wahrscheinlich schlau genug
sein, die selben Clients immer auf die selben Server zu schicken. Das
können die aber Regelfall.
- Mit Profiling die lange dauernden Sachen ermitteln und die optimieren.
Das ist natürlich auf einem Produktivsystem schwer (und auf einem
Testsystem hat man keine reale Last), ich kenne das.
Versuche auf jeden Fall auch genau zu ermitteln, welche Komponente das
Bottleneck ist. Ist das wirklich die CPU, oder vielleicht doch
Platten-I/O?
> Auf 64Bit lag der Speicherverbraucht (bei glicher Besucherzahl bei >7GB
> RAM)
Autsch. Was für eine Plattoform? Java?
> Und mit Wachstum ist das nahende Weihnachsgeschäft gemeint, dass aus
> Erfahrung ca 60 % mehr Besucher bringt, welche der Server bedienen muss.
Same here. :) Wobei wir aus, äh, vertrieblichen Gründen vier solche
Peaks pro Jahr haben. Der an Weihnachten ist aber immer der dickste.
>> Wenn Du auf dem Server auch eine Webanwendung hinter dem Apache hast,
>> ist mit allerhöchster Wahrscheinlichkeit nicht der Apache der
>> Flaschenhals. Kümmere Dich um die Anwendung, nicht (so sehr) um den
>> Apache.
>
> Hmm, das ist wohl war, handelt es sich bei dieser Anwendung noch um ein
> Verbrechen aus der Vergangenheit....
Same here. Aber je länger man selbst dabei ist, desto weniger kann man
seine Hände in Unschuld waschen. :)
>> Um was für Server soll es überhaupt gehen? Professionelle Serverhardware
>> gibt es doch kaum noch in 32 Bit, oder irre ich da?
>
> Ja klar, aber ich werde XEN nutzen. Und da stellte sich mir aktuell die
> Frage, ob ich nun 3 Apache domU mit je 4GB als i386 laufen lasse oder
> lieber eine fette domU mit amd64 und 12GB RAM.
Du könntest alternativ auch eine i386 mit 12GB RAM verwenden, sofern
Deine einzelnen Prozesse nicht mehr als 4GB brauchen. Ich denk auf jeden
Fall nicht, dass Du durch das Aufteilen der Hardware in mehrere VMs
etwas gewinnst.
> unter i386 ca 5GB RAM-Verbrauch
> unter amd 64 > 7GB Ram-Verbrauch
In einem einzigen Prozess!?
J.
--
When I am at nightclubs I enjoy looking at other people and assessing
their imagined problems.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature