Server Load => Suchmaschine

[peterpan]

Hallo liebes Forum,

wir betreiben eine Suchmaschine, bei der die Zugriffzahlen im Augenblick extrem rasant ansteigen.

Zu Spitzenzeiten haben wir das Problem, daß auf dem Hauptserver so viele Anfragen eingehen, daß er nicht mehr hinterherkommt. Ich habe mich noch nicht wirklich mit Load-Balancing beschäftigt.

Was wäre denn der erste Schritt zu einer Lastverteilung?


Herzliche Grüße!

[$kuLL]

hallo,

also um da tipss zu geben müsste man ein paar mehr infos haben, wie z.b.

- hardware der server
- wieviele server stehen zur verfügung
- banbreiten im internen netz
- welche dienste werden genutzt (nut httpd?)
- welche(s) betriebssystem(e) wird/werden genutzt

gruß, $kuLL

[peterpan]

Hallo, gerne gebe ich weitere Infos.

Im Augenblick haben wir:

Hardware:
- 1x WWW-Server mit Suchindex (2 GHz, 1 GB Ram)
- 4x Crawler (jeweils ded. 2 GHz Rootserver von 1&1)

- banbreiten im internen netz
Der WWW-Server steht bei uns im RZ, Anbindung weiß ich nicht so genau.

- welche dienste werden genutzt (nut httpd?)
httpd und unser eigenes Datenbanksystem für den Suchindex (MySQL war
nach kurzer Zeit zu langsam).

- welche(s) betriebssystem(e) wird/werden genutzt
Suse Linux

[$kuLL]

kannst du ungefähre angaben zu den simultanen zugriffen machen?
hast du die httpd.conf schon bearbeitet hinsichtlich der max connection usw?

ein einzelner webserver kann schnell überfordert sein, darum ist das so ne sache mit dem slb

wenn der flaschenhals die hardware performance ist hilft meist nur ein cluster :D, denn 2ghz und 1gb ram ist ja nicht grade wenig

weiterhin ist das os nicht das beste für diesen zweck!
FreeBSD ist für hochleistungswebserver das A&O!
kein anderes os arbeitet so effizient bei hoher netzwerklast
die performance unterschiede zu linux gehen hoch bis 20%!

naja aber das sagt sich so leicht daher, mal schnell ein neues os aufspielen geht ja meistens auch nicht :>

[peterpan]

Hallo Skull,

> kannst du ungefähre angaben zu den simultanen zugriffen machen?

Zu Spitzenzeiten 100 - 500.

> hast du die httpd.conf schon bearbeitet hinsichtlich der max connection usw?

Ja, das System wird aber irgendwan so busy, daß es extrem langsam wird.
Es geht ja auch nicht nur um WWW-Zugriffe, unsere Database Engie macht
ja auch nochmal etwas Last.

> ein einzelner webserver kann schnell überfordert sein, darum ist das so ne
> sache mit dem slb

Ja, stimmt. Ich bräuchte nur eine Idee, wie ich den Suchindex ohne Probleme
auf mehrere Systeme verteile. Dann könnte ich einen Webserver vorschalten,
der an weitere Webserver weiterverteilt, die alle auf den Indexserver zugreifen.
Aber das geht nicht so ohne Probleme.

> wenn der flaschenhals die hardware performance ist hilft meist nur ein cluster ,
> denn 2ghz und 1gb ram ist ja nicht grade wenig

Urgs, habe ich noch nie aufgesetzt...

> weiterhin ist das os nicht das beste für diesen zweck!
> FreeBSD ist für hochleistungswebserver das A&O!

Naja, da gehen die Meinungen ja auseinander.

> naja aber das sagt sich so leicht daher, mal schnell ein neues os aufspielen
> geht ja meistens auch nicht :>

Das ist das Problem... ;-)

Naja, danke Dir trotzdem...

[Berufspenner]

Ja, das System wird aber irgendwan so busy, daß es extrem langsam wird.
Es geht ja auch nicht nur um WWW-Zugriffe, unsere Database Engie macht
ja auch nochmal etwas Last. Also bei sollchen Projekten sollte man immer schon mal performanten Hardware extra für einen Datenbankserver mit einrechnen.
Naja, da gehen die Meinungen ja auseinander. Wieso? FreeBSD ist ein sehr performantes OS, welches für den Einsatz auf Webservern ideal ist.
Das ist das Problem... ;-) Gut, das muss man dann abwegen. Die Hauptsache ist, dass ihr ein ordentlich durchdachtes Konzept vorzulegen habt und nicht alles übereifrig zusammen fuscht. Dafür wären die Kosten doch ein wenig zu hoch, um da herum zuspielen ;)

Cu
André

PS: Könntest du uns auch mal die URL offenbaren? ;)

[peterpan]

> Gut, das muss man dann abwegen. Die Hauptsache ist, dass ihr ein ordentlich
> durchdachtes Konzept vorzulegen habt und nicht alles übereifrig zusammen
> fuscht. Dafür wären die Kosten doch ein wenig zu hoch, um da herum zuspielen

Ja, das stimmt. Aber wenn man erstmal vor so einer Last steht, gehen einem dann doch schonmal die Ideen aus.

Das größte Problem ist dabei, daß ich den Index nicht wirklich auf verschiedene Rechner verteilen kann. Evtl. ginge es ja, einen Index-Server und drei WWW-Server aufzustellen. Dann könnte ich evtl. die Festplatten des Index-Servers anmounten... unsere DB wird direkt über das Filesystem angesprochen. Grübel...

> PS: Könntest du uns auch mal die URL offenbaren?

Habe ich extra weggelassen. "Versteckte" Werbung in Foren kommt immer ******e, finde ich. ;-)

[Berufspenner]

Habe ich extra weggelassen. "Versteckte" Werbung in Foren kommt immer ******e, finde ich. ;-) Kannst mir ja eine PN schicken ;)

Um die Performance auf dem DB Server zu steigern, zumindest den Zugriff von der Festplatte, würde ich ein Hardware-IDE oder -SCSI Raid 5 System empfehlen. Auch eine Permanentspiegelung der DB auf weitere Server könnte doch möglich sein. Gut wären auch noch ein oder zwei Server mit großen Kapazitäten für ein Gesamtbackup, etc. Aber ich glaube, ich fange wieder an zu träumen *schwärm* :D ;)

Cu
André

[$kuLL]

also liegen webserver und db auf derselben maschine?
na dann wäre der einfachste weg bessere hardware zu installieren 2gb ram , dual cpu
denn wenn ihr eurer eigenes db-system nutzt ist es schwer da zu helfen und wenn du dir selber nicht sicher bist ... naja :D

wichtig ist noch:
ide festplatten oder scsi?
raid im einsatz?

[tomes]

Wenn du das System eins zu eins spiegeln kanns, wuerde ich als erstes ein roud-robbing ueber DNS vorschlagen.

T;o)Mes

[heatwalker]

Hallo,
1. du solltest erstmal überprüfen welche prozesse überhaupt last verursachen.
100 bis 500 simultane Zugriffe sind eigentlich noch nicht sehr performant.
2. Wie sieht Eure Plattenstruktur aus? Ist die für ein Datenbanksystem performant genug ausgelegt? Mit z.B. nur einer Festplatte wäre es etwas dürftig.

Gruss Frank

[tomes]

Original geschrieben von heatwalker
Hallo,
1. du solltest erstmal überprüfen welche prozesse überhaupt last verursachen.
100 bis 500 simultane Zugriffe sind eigentlich noch nicht sehr performant.
2. Wie sieht Eure Plattenstruktur aus? Ist die für ein Datenbanksystem performant genug ausgelegt? Mit z.B. nur einer Festplatte wäre es etwas dürftig.

Gruss Frank
Also wenn da ein 1.3 Apache werkelt, koennen das schnell 500*10 MB werden, wenn dann noch die Datenbankabfragen kommen, sind die 1 G schnell voll und dann swap das System und das ist dann meist toedlich.
Wir haben einen aehnlich besuchten Web-Server. Allerding liegt die Datenbank extra und wird nicht so beantsprucht.

T;o)Mes

P.S.: die ca. 10 MB kommen bei einem Standard-Linux-Paket-Apache vor.
Tip --> Apache entschlacken, also alle Module die man nicht braucht raus. Meiner braucht nur noch 5,3 MB, was fast die Haelft ist und sich bemerkbar macht bei > 250 Prozesse

[heatwalker]

Original geschrieben von tomes
Also wenn da ein 1.3 Apache werkelt, koennen das schnell 500*10 MB werden, wenn dann noch die Datenbankabfragen kommen, sind die 1 G schnell voll und dann swap das System und das ist dann meist toedlich.
Wir haben einen aehnlich besuchten Web-Server. Allerding liegt die Datenbank extra und wird nicht so beantsprucht.

T;o)Mes

P.S.: die ca. 10 MB kommen bei einem Standard-Linux-Paket-Apache vor.
Tip --> Apache entschlacken, also alle Module die man nicht braucht raus. Meiner braucht nur noch 5,3 MB, was fast die Haelft ist und sich bemerkbar macht bei > 250 Prozesse

Nun, das kann ich nicht ganz nachvollziehen. Hab das das ganze mal an unserem eigenen Server ausgetestet. Wenn ich 250 Processe starte, teilt er den vorhandenen Speicher auf.
Das heisst, ich habe vorher 5 gleichzeitige prozesse à 31mB und jetzt 250 proz à 9 MB. Linux geht lediglich hin und teilt den gesamten vorhanden speicher auf und kann somit keinen freien speicher anzeigen.

Also ich etwas skeptisch, das ganze auf den Speicher abzuschieben. Ich vermute es eher im Bereich des hardwarezugriffs. (Festplatten)
Datenbanken haben, gerade bei Suchmaschinen, einen erhöhten lesebedarf. Ich schätze das einfach die Performance im Plattensystem schlapp macht.

gruss Frank

PS: Unser System läuft mit 768 MB, zusätzlich sind im augenblick auch 250 java server mitgestartet. (-:
PS2: Ach ja, Swap wird vom System nicht angefordert.

[tomes]

Ja, ich weiss das es eigendlich eine "Milchmaedchen-Rechnung" ist. Aber 250*9 oder 500 * 6 ist nicht gerade wenig. Und wenn die Prozesse alle benutzt werden und dann persistente Datenbank-Verbindungen zu localhost noch dazu kommen, ist der Speicher schnell weg.
Ist einfach aus der Erfahrung heraus.
Dann faengt das System an zu swappen und die load average ist schnell ueber eins. Dann wird es zum "Selbstlaeufer".

T;o)Mes

[heatwalker]

Du hast natürlich grundsätzlich recht. Irgendwo ist auch mal schluss.
Worauf ich eigentlich hinaus wollte ist,
a) Das System zu analysieren wo Last entsteht und dann
b) Ein Konzept erstellen.
c) Die Lösung implementieren. (-:

Können wir uns darauf einigen (*g*)

mfg Frank

[tomes]

Natuerlich ;-)
pstree, top, free usw. ist ja eigendlich alles da.

T;o)Mes

[peterpan]

Sorry, ich hatte mich irgendwie ausgesperrt... ;-)

Meine Antworten hoffentlich nicht zu durcheinander:

> also liegen webserver und db auf derselben maschine?

Ja.

> na dann wäre der einfachste weg bessere hardware zu installieren 2gb ram
> , dual cpu

Ja, aber dann ist nach 3 Monaten wieder Feierabend...

> denn wenn ihr eurer eigenes db-system nutzt ist es schwer da zu helfen und
> wenn du dir selber nicht sicher bist ... naja

Jaja... ich hab´s nicht programmiert. Ich weiß nur, daß es über das Filesystem
angesprochen wird.

> wichtig ist noch:
> ide festplatten oder scsi?
> raid im einsatz?

Nein, einfache IDE-Platten mit Cache.

> Wenn du das System eins zu eins spiegeln kanns, wuerde ich als erstes ein
> roud-robbing ueber DNS vorschlagen.

Ist ein guter Vorschlag, kann ich aber nicht so einfach spiegeln.

> 1. du solltest erstmal überprüfen welche prozesse überhaupt last verursachen.

70% Apache, 30% Datenbank

> 100 bis 500 simultane Zugriffe sind eigentlich noch nicht sehr performant.

Bitte? ;-)) Was ist das denn dann? 500 concurrent requests ist so ungefähr das
fünffache von der "Standard-Apache-Empfehlung" und entspricht bei uns etwa
180.000 Suchanfragen pro Stunde...

> 2. Wie sieht Eure Plattenstruktur aus? Ist die für ein Datenbanksystem
> performant genug ausgelegt? Mit z.B. nur einer Festplatte wäre es
> etwas dürftig.

Nee, Platte ist etwas dürftig.

> Ich schätze das einfach die Performance im Plattensystem schlapp macht.

Vielleicht baue ich doch mal ein Raid ein... ;-)

[ChengFU]

Hallo,

Jetzt muss ich auch mal meinen Senf dazu geben:
Mein Tipp ist es, den Apache mal per Apache-Toolbox (http://www.apachetoolbox.com) selbst zu kompilieren. Da kann man super-bequem per Menü auswählen was benötigt wird und bekommt so einen sehr sehr schnellen Apache.
Und auf jeden Fall solltet ihr einen Weg finden, die Datenbank getrennt vom Webserver zu fahren. Vermutlich müsste diese dann per Netzwerk erreichbar sein, aber ansich sind beide Dienste auf einem Rechner nie richtig glücklich miteinander.

Gruss, CF

[Berufspenner]

Hi@all

Die nötige Software sollte allein aus Performancegründen kontrolliert und überlegt auf der Maschiene kompiliert werden. Auch wenn Binärpackete leichter abzudaten bzw. einzuspielen sind.

Cu
André

[tomes]

Wieso koennt ihr nicht einfach spiegeln ? So wie es sich liesst, liegt doch auf dem Webserver "nur der" Index und der aendert sich 1. nicht dauernt 2. kann der doch auch immer gepiegelt werden.

Mal ne Frage am Rande, was macht ihr eigendlich wenn der Webserver mal ausfaellt ?
Eine Spiegelung haette auch eine Redundanz zur Folge ;)
Tip: schau dir mal heartbeat an

Ansonsten, ich Test gerade den letzten 2.0er Apache, wegen Thread-Server, und ich muss sagen sieht gut aus. Wie gesagt, wir haben auch im ø 350 simultane Zugriffe.

T;o)Mes

[netzmeister]

Hallo,

ich würde mir für so etwas einen eigenen angepassten Webserver programmieren.
Der Apache ist für eine solche Sachen nicht sehr gut geeignet. Ein anpasste Applikation
wäre wahrscheinlich etwa 100 Mal schneller als ein CGI auf Apache Basis.

Bei Interesse einfach mal melden.

Ich habe jahrelange Erfahrung in diesem Bereich.

Viele Grüße

Eicke

[$kuLL]

Original geschrieben von netzmeister
ich würde mir für so etwas einen eigenen angepassten Webserver programmieren.


meinst du damit "das rad neu erfinden" oder in den apche quellen rumschreiben?
ich mein, mal so schnell nen webserver programmieren dauert ja sicherlich paar minuten *fg* :D

[peterpan]

Nabend,

ich antworte nochmal so frech durch die Bank:

> Wieso koennt ihr nicht einfach spiegeln ? So wie es sich liesst, liegt doch auf dem
> Webserver "nur der" Index und der aendert sich 1. nicht dauernt

Doch tut er- wir gewichten die Suchergebnisse u.a. nach ihrer Relevanz bei den
Usern. Das heißt die Clicks auf die Ergebnisseiten werden pro Seite wird mitgetrackt
und ausgewertet (aaahhhh... besser als Pagerank... ;-)). Daher ändert sich der Index
recht häufig, d.h. nicht der Index, sondern die Gewichtung.

> 2. kann der doch auch immer gepiegelt werden.

Live?

> Mal ne Frage am Rande, was macht ihr eigendlich wenn der Webserver mal
> ausfaellt ?

Nix. Wir halten diese ganze Redundanznummer für überbewertet. Was soll schon
groß passieren? Wir verkaufen ja keine Ferrari über einen Online-Shop. :-)

> Eine Spiegelung haette auch eine Redundanz zur Folge
> Tip: schau dir mal heartbeat an

Mache ich, danke Dir.

> Ansonsten, ich Test gerade den letzten 2.0er Apache, wegen Thread-Server,
> und ich muss sagen sieht gut aus. Wie gesagt, wir haben auch im ø 350
> simultane Zugriffe.

Das ist ja schon eine ganze Menge. Macht Ihr das mit einem einzigen Server?
Dann kann da ja nicht viel dynamisches auf der Seite sein, oder? ;-)

> ich würde mir für so etwas einen eigenen angepassten Webserver
> programmieren.

Vergiß es! ;-)

> Der Apache ist für eine solche Sachen nicht sehr gut geeignet.

Na, jetzt hör aber auf.

> Ein anpasste Applikation wäre wahrscheinlich etwa 100 Mal schneller als ein
> CGI auf Apache Basis.

Ist C++ und wird über PHP aufgerufen. .-)

> Bei Interesse einfach mal melden.

Ist eine tolle Idee, aber zu verwegen. ;-)

> Ich habe jahrelange Erfahrung in diesem Bereich.

Wie? Hast Du einen eigenen Webserver geschrieben? Vielleicht sollten wir den
mit unserer Datenbank kombinieren und Apache und MySQL den Rang ablaufen... ;-)


Herzliche Grüße!

[netzmeister]

Hallo peterpan,

Ich möchte das dann auch nicht vertiefen hier. Seit über 5 Jahren
beschäftige ich mich hauptberuflich mit Webservern. Ich kann das ziemlich
gut beurteilen. ;

Du glaubst mir nicht? Dann kann ich Dir auch nicht helfen.

Viele Grüße

Eicke

P.S. Apache ist viel zu mächtig für Deine Anforderungen.

[ChengFU]

Hallo,

Was Netzmeister sagt stimmt schon, der Apache ist fürchterlich komplex und oft auch überladen. Wenn mn schon nicht einen eigenen Webserver stricken will, hilft es zumindestens mal zu prüfen ob der Kernel-Webserver (hiess früher mal "Tux", keine Ahnung ob der Name geblieben ist) die Anforderungen erfüllt oder zumindestens einen angepassten Apache mit Minimalausstattung kompilieren. Mit letzterem lassen sich allein schon grosse Mengen Speicher sparen, was sich sehr direkt auf die Performance auswirkt.

Gruss, CF

[netzmeister]

Hallo,

na gut, dann eben mal ein konkretes Beispiel:

Auf diesem Rechner hier: linuxforen.de und noch ein paar kleine Sites,
ca. 500.000-600.000 Hits pro Tag läuft noch zusätzlich ein eigener,
selbst programmierter Server.

Zufälligerweise macht der der zu allem Übel :D auch noch Suchabfragen:

Seht selbst: Tokensearch.de (http://www.tokensearch.de)

peterpan: Sieh es Dir einfach mal an, ...

Viele Grüße

Eicke

[peterpan]

Sorry, ich wollte sicher niemandem auf den Schlips treten.

Das Problem, welches ich sehe, ist auch anderer Natur: Woher weiß ich, daß der "selbstgebaute" Webserver wirklich gut und sicher ist? Wer außer netzmeister kann ihn bedienen? Woher bekomme ich ihn? Wer kann ihn aufsetzen? usw. usw.

Ihr habt sicher recht, daß der Apache überladen ist. Aber er funktioniert nachweislich (sogar recht stabil) und wird ständig weiterentwickelt.

[Mattburger]

Hallo Meine Herren,

ich bin derjenigewelcher schon mehrere Web-Server geschrieben hat.
Immer wieder höre ich die gleichen Argumente.

Das Rad zweimal erfinden:
- Apache ist ein extrem mächtiger Webserver mit einem sehr breiten Anwendungsbereich (mod xx und diversen Scriptsprachen). Das ist schon vom Ansatz mit einem separaten Webserver für einen sehr speziellen Anwendungsfall nicht zu vergleichen. Es wird einfach sehr viel weniger dafür sehr speziell entwickelt.
Das eine schliest das andere auch nicht aus.

- Performance: Zum einen sind die Scriptsprachen Performance-Fresser zum anderen die Übergänge zu den entsprechenden Libs. Die Art der Datenbankzugriffe tut dann noch sein übriges dazu. Das Hauptproblem besteht jedoch in den implementierten Algorithmen und den wechselnden Prozessgrenzen.
Stellt euch einfach mal die Anzahl der Schichten und Technologien für eine einzelne Anfrage vor und vergleicht das mit einer Structur im Hauptspeicher die durch ein kompiliertes Programm optimiert rausgeschickt wird. Das kann mit Hardware nur begrenzt ( eigentlich gar nicht) ausgeglichen werden.

- Suchmaschine: Lernen von den Meistern: (Google)
http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm

- Realisierung: Wenn Geld da und Zeitdruck - Entwickeln lassen !
Oder einfach den zahlreichen Beispielen folgen. Ich wuerde hier Kylix mit den Indy-Komponenten empfehlen. Entsprechende Literatur verhilft hier zu schnellen Ergebnissen.

Hoffe ein bischen geholfen zu haben.

Grüsse Mike

[Mattburger]

Hallo peterpan


Woher weiß ich, daß der "selbstgebaute" Webserver wirklich gut und sicher ist?
Testen, testen und wieder testen. :-)
Im ernst bei eine Suchmaschine läst sich sehr schnell feststellen ob Sie problemlos läuft.


Wer außer netzmeister kann ihn bedienen? Woher bekomme ich ihn? Wer kann ihn aufsetzen? usw. usw.
Quellcode mit ausliefern lassen. Sollte nicht so schwer sein.

Grüsse
Mike

[peterpan]

Tja... klingt alles top.

Aber wir sind 100% werbefrei und haben daher leider keine Mittel für Softwareentwicklung _dieser_ Art. Schade...