Was ist sinnvoller? 1x1000 oder 5x200?
lars
- cgi
0 Cheatah0 Frank F aus Ulm0 lars0 Michael Schröpl0 lars
Hallo,
ich hab eine grundsätzliche frage zu cgi bzw eigentlich den servern.
mein cgi script muß mehrere prozesse gleichzeitig ausführen.
ich könnte aber mehere cgis gleichzeitig laufen lassen, damit sie die prozesse abarbeiten.
was würdet ihr als sinnvoler(ressourcenschonender) ansehen?
1 script, welches 1000 prozesse gleichzeitig abarbeitet oder 5 gleichzeitig laufende scripts , die je 200 prozesse gleichzeitig abarbeiten.
oder macht es letzlich gar kein unterschied?
danke im voraus:)
lars
Hi,
was würdet ihr als sinnvoler(ressourcenschonender) ansehen?
1 script, welches 1000 prozesse gleichzeitig abarbeitet oder 5 gleichzeitig laufende scripts , die je 200 prozesse gleichzeitig abarbeiten.
die Antwort auf diese Frage lautet ganz eindeutig: ja.
In dieser pauschalen Form lässt sich die Frage nicht beantworten. Wobei CGI _hoffentlich_ das falsche Themengebiet ist, denn CGI-Prozesse werden immer genau dann aufgerufen, wenn ein entsprechender Request beim Server ankommt.
Cheatah
Hallo miteinander,
hinzu kommt, dass bei 1x1000 nicht 1000 Prozesse gleichzeitig ausgeführt werden, sondern sukzessive...
bei 5 x 200 dann nicht etwa 200 gleichzeitig, sondern 5!!! gleichzeitig.
wenn du 200 Prozesse parallel ausführen willst, brauchst du dann auch 200 CGI-Scripts, die zur selben Zeit durch einen Request angestoßen werden müssten, bzw. ein CGI, was dann gleichzeitig 200x dasselbe anstößt (ohne auf die Beendigung eines einzelnen zu warten)
Viele Grüße aus dem Süden, Frank
hinzu kommt, dass bei 1x1000 nicht 1000 Prozesse gleichzeitig ausgeführt werden, sondern sukzessive...
bei 5 x 200 dann nicht etwa 200 gleichzeitig, sondern 5!!! gleichzeitig.
hallo frank,
dank dir Dir und Cheatah für die Antworten:)
bedeutet das, daß ein script, welches mehrere prozesse abarbeitet, ressourcenschonender sei, als die arbeit auf mehrere cgis zu verteilen, da es "sukzessive" ausgeführt wird?
sorry für die frage, ich habe leider es immer noch nicht ganz verstanden :rolleyes:
gruß lars
Hi lars,
bedeutet das, daß ein script, welches mehrere prozesse abarbeitet,
Ein Prozeß arbeitet ein Skript ab - nicht umgekehrt.
ressourcenschonender sei, als die arbeit auf mehrere cgis zu verteilen, da es "sukzessive" ausgeführt wird?
Zunächst einmal sind CGI-Skripte wahrscheinlich überhaupt der falsche Weg, um eine solche Aufgabe zu bearbeiten - denn ein Zusammenhang mit einem HTTP-Request ist ja (hoffentlich) gar nicht gegeben: Als Antwort auf den HTTP-Request muß _eine_ Ressource zurück geliefert werden. Falls Du dann erreichen willst, daß diese Ressource das Ergebnis von 1000 Verarbeitungsschritten (welcher Art auch immer) darstellen, solltest Du damit rechnen, den CGI-Timeout des Servers zu überschreiten - will sagen: Die Chance, daß Dein Problem auf diese Weise unlösbar ist, halte ich für ziemlich hoch.
Also vergessen wir CGI erst mal wieder und sehen uns den Server an. Ist das Dein eigener Server? Mußt Du die Ressourcen mit anderen Anwendern teilen? Damit würde ich schon mal anfangen. Wenn Du auf einer Maschine, wo Du nur "Gast" bist, 1000 parallele Prozesse zu starten versuchst, dann machst Du Dich dort nicht sonderlich beliebt, während das bei Deinem eigenen Server ggf. kein Problem darstellen wird.
Um die quasi-parallele Verarbeitung vieler Prozesse zu ermöglichen, verwaltet das Betriebssystem eine Warteschlange und weist den jeweiligen Prozessen üblicherweise (nach einem mehr oder weniger flexiblen Verfahren) sogenannte Zeitscheiben zu. Die Prozesse rechnen also nicht gleichzeitig, sondern abwechselnd ... wobei es natürlich auch Server mit mehreren CPUs gibt, wo dann tatsächlich echt gleichzeitig gearbeitet werden kann ... aber alles in allem ist Prozeßwechsel nicht völlig kostenlos. Wenn Du durch Parallelisierung nichts gewinnen kannst, dann laß es bleiben.
Wie verhalten sich diese Prozesse zueinander? Greifen sie auf gemeinsame Ressourcen zu, so daß eine parallele Verarbeitung einen zusätzlichen Synchronisationsaufwand erfordern würde? Dann wäre eine parallele Verarbeitung ggf. wesentlich aufwändiger als eine sequentielle.
Umgekehrt könnte es sein, daß diese Prozesse von ihrem Ablaufcharakter her sehr gut parallelisierbar sind, weil sie wenige Ressourcen benötigen und keine Abhängigkeiten untereinander aufweisen.
Es kann sogar sein, daß diese Prozesse gemeinsam laufen _wollen_, weil dabei beispielsweise bestimmte Ressourcen, die von allen diesen Prozessen nur gelesen werden müssen, nur ein einziges Mal im Arbeitsspeicher liegen müssen. Wenn diese Prozesse nacheinander und konkurrierend mit weiteren Prozessen laufen, kann es passieren, daß diese Ressource immer mal wieder aus dem Arbeitsspeicher ausgelagert wird (weil die konkurrierenden Prozesse diesen Platz anders belegen wollen und er vorübergehend unbenutz aussah) und dann erst wieder eingelagert werden muß ... laufen jedoch viele dieser Prozesse gleichzeitig, dann wird die Zugriffsrate aller Prozesse auf diese Ressource so hoch sein, daß letztere wahrscheinlich dauerhaft im Arbeitsspeicher vorrätig sein wird und kein zusätzlicher Verwaltungsaufwand anfällt.
Dies alles ist nicht wirklich eine exakte Antwort auf Deine Frage - es ist lediglich eine Beschreibung, wieso Deine Frage ohne _sehr_ detaillierte weitere Angaben unmöglich zu beantworten ist. Performance-Aspekte gehören zu den komplexeren Aufgaben der IT ...
Viele Grüße
Michael
lieben dank an dich michael, hat mir sehr geholfen nachzuvollziehen, was eigentlich auf einem server passiert.
entschuldige für meine undetaillierten aussagen, ich dachte es wäre einfacher so zu verstehen , was ich eigentlich meine.
ich habe einen eigenständigen server, der bereits stark ausgelastet ist, daher habe ich diese grundsätzliche frage gestellt.
ich beherrsche perl und php, bin aber an einem punkt angelangt, wo ich nicht mehr weiterkomme.
ich habe bereits mein ursprüngliches script von php ins perl gecodet, da ich annahm, daß es schneller sei.
nun überlegte ich dieses script zu vervieltätigen um eventuell ein paar prozente der ressourcen einzusparen.
das script stellt on-th-fly (mit jedem http request) eine eigenständige webseite für den user her, die er selbst sich zusammenstellt und die stets variert,da ich eine breite pallette anbiete, kann man davon ausgehen, daß in seltensten fällen, mehrere requests über das script die selbe ressorce anfordern(z.B. der eine generiert sich sein wetter, und der andere sein neues tv-programm.)
es funktioniert alles einwandfrei, leider ist aufgrund des traffic aufkommens der server langsam am limit angekommen.
soweit ich dich versatnden habe, gibt es keine gleichzeitigkeit(zumindest bei einer einzigen CPU), so daß es wohl unter umständen kein vorteil bringen würde, mehrere gleiche scripte die requests abarbeiten zu lasssen.
ursprünglich habe ich mir das folgendermaßen vorgestellt, mit jedem request wird ein anderes script aufgerufen.
zur zeit geht jeder request über script A.
mit einem simplen zufallsgenarator könnte ich jedem neuen request ein anderes script zuweisen.(A1, A2, A3, A4 u.s.w.[wobei A1-A(x) identische scripte sind]).
du sprichst im letzten absatz an, daß es eventuell vorteile geben könnte, wenn diese nicht auf die gleiche ressource zugreifen würden.
nun, dies ist wohl zu 90% der fall bei mir.
vielleicht anders gefragt, kann es sich unter diesen umständen überhaupt negativ auswirken mehrere gleiche scripts zur verfügung zu stellen, um den requests nachzukommen?
gruß lars
Moin!
ich habe bereits mein ursprüngliches script von php ins perl gecodet, da ich annahm, daß es schneller sei.
Vermutlich wird dies nicht der Fall gewesen sein - ich kann mir sogar vorstellen, dass es schlechter geworden ist. Perl wird üblicherweise als CGI eingesetzt, die CGI-Schnittstelle ist aber für sich recht langsam. PHP hingegen _kann_ als Apache-Modul laufen und hätte deswegen leichte Vorteile. Allerdings gibt es auch mod_perl, damit Perl als Apache-Modul laufen kann. Dazu sind aber wieder gewisse Programmiertechniken notwendig, damit es funktioniert. Denn das Script wird bei mod_perl nur noch einmal kompiliert und dann immer wieder verwendet - Änderungen am Skript sind nur durch einen Serverneustart wirksam zu machen, für die Entwicklung von Skripten ist das eher hinderlich.
Ich denke aber, dein Problem liegt nicht an den Skripten.
nun überlegte ich dieses script zu vervieltätigen um eventuell ein paar prozente der ressourcen einzusparen.
Wozu? Wenn ein Browser einen Request an ein Skript schickt, wird eine Kopie des Skriptcodes von Festplatte gelesen (bzw. auch aus dem Speicher genommen), kompiliert/interpretiert und ausgeführt. Wenn zwei Anfragen von zwei Benutzern gleichzeitig eintreffen, sind _zwei_ Skripte parallel aktiv. Es läuft bereits das ab, was du meinst einbauen zu müssen.
Es ist nicht sinnvoll, dieses Skript irgendwie aufzuteilen. Es muß ein Skript bleiben, denn die Ausgabe an den Browser muß ja eine komplette Seite sein, und nicht nur ein Bruchstück.
das script stellt on-th-fly (mit jedem http request) eine eigenständige webseite für den user her, die er selbst sich zusammenstellt und die stets variert,da ich eine breite pallette anbiete, kann man davon ausgehen, daß in seltensten fällen, mehrere requests über das script die selbe ressorce anfordern(z.B. der eine generiert sich sein wetter, und der andere sein neues tv-programm.)
Dann greift das Skript doch sicherlich auf irgendwelche Datenbestände zu. Wie sind die gespeichert? Wie greift das Skript zu? Üblicherweise läßt sich hier durch Implementation von geeigneten Mechanismen (Caching, Indizierung) die Zugriffsgeschwindigkeit erhöhen, was natürlich die Bearbeitungszeit des Skripts senkt.
es funktioniert alles einwandfrei, leider ist aufgrund des traffic aufkommens der server langsam am limit angekommen.
Du solltest sehr genau analysieren, wo der Flaschenhals steckt, damit du an dieser Stelle die Performance verbesserst.
Dieses Forum hier hatte vor einiger Zeit mit der alten Forumssoftware ebenfalls erhebliche Performanceprobleme. Der Grund lag wohl unter anderem darin, dass beim Speichern eines Postings viele Dateien auf Festplatte für weitere Zugriffe gesperrt werden mußten, und diese Sperre relativ lange andauerte. Außerdem war das Forum komplett in Perl geschrieben und mußte XML-Dateien parsen, was offensichtlich nur bis zu einem gewissen Grade performant war. Das jetzige Forum ist in den performancekritischen Teilen in C geschrieben, besitzt jetzt einen eigenen Forums-Daemon (Serverprogramm, der im Hintergrund läuft) und hält alle häufig nachgefragten Daten im RAM bereit. Speicherung auf Festplatte passiert in regelmäßigen, aber nicht so häufigen Abständen. Außerdem sind die Sperrzeiten beim Abschicken eines Postings wesentlich verkürzt worden. Alle diese Verbesserungen konnten nur erfolgen, nachdem die Problempunkte des alten Forums analysiert waren.
soweit ich dich versatnden habe, gibt es keine gleichzeitigkeit(zumindest bei einer einzigen CPU), so daß es wohl unter umständen kein vorteil bringen würde, mehrere gleiche scripte die requests abarbeiten zu lasssen.
Es macht beispielsweise Sinn, mehrere Aufgaben gleichzeitig zu starten, wenn bei diesen Aufgaben in irgendeiner Art und Weise auf etwas gewartet werden muss und die Wartezeit nicht anderweitig sinnvoll genutzt werden kann. Wenn du von fremden Servern irgendwelche Seiten abrufst, dann ist es vorteilhaft, von mehreren Servern parallel Seiten abzurufen, weil der Empfangsvorgang in der Regel eine Weile dauert - während die eine Aufgabe auf Daten wartet, kann die andere Aufgabe schon den nächsten Request losschicken, und die dritte Aufgabe die gerade empfangenen Daten speichern.
Wenn die Aufgabe allerdings darin besteht, eine lokale Datenbank zu befragen, dann sind viele parallele Anfragen an die Datenbank für die Performance vielleicht eher hinderlich, weil ja nicht nur die Aufgabe von deinem Server bearbeitet werden muss, sondern auch noch die Datenbankabfrage Prozessorpower kostet - ganz zu schweigen von den möglicherweise notwendigen Festplattenzugriffen, um überhaupt an die Daten der Datenbank ranzukommen.
ursprünglich habe ich mir das folgendermaßen vorgestellt, mit jedem request wird ein anderes script aufgerufen.
zur zeit geht jeder request über script A.
mit einem simplen zufallsgenarator könnte ich jedem neuen request ein anderes script zuweisen.(A1, A2, A3, A4 u.s.w.[wobei A1-A(x) identische scripte sind]).
Wenn A1, A2, A3 exakt das gleiche tun sollen - wozu sie dann kopieren? Das erledigt, wie oben erwähnt, der Server bereits für dich: Die Skripte laufen parallel.
Allerdings laufen natürlich nur soviele Skripte parallel, wie Serverinstanzen parallel laufen dürfen. Das bedeutet: Es gibt eine Obergrenze an parallel verarbeitbaren Browser-Requests. Wenn diese Obergrenze zu niedrig gewählt ist, hast du viel freien Speicher, viel übriggebliebene CPU-Zeit, und eine wahnsinnige Warteschlange an Browsern, die was von deinem Server wollen.
Wenn hingegen diese Zahl zu hoch gewählt ist, hast du kaum noch RAM-Speicher frei, die CPU ist dauernd zu 100% ausgelastet, und dein Server pfeift aus diesem Grunde auf dem letzten Loch. Dann sollte man vielleicht über mehr RAM, effizientere Programmierung, eine schnellere Festplatte, oder sogar eine schnellere CPU nachdenken (in dieser Reihenfolge). Ohne Analyse, wo dein Problem liegt, geht das aber nicht.
- Sven Rautenberg
Moin!
moin moin:)
nehme mir dein rat zu herzen und installiere mod_perl, mal schauen was es bringt:)
gruß lars
Moin!
nehme mir dein rat zu herzen und installiere mod_perl, mal schauen was es bringt:)
Wahrscheinlich einen Serverabsturz und/oder wahnsinniges Chaos bei dir, denn deine Skripte sind mit Sicherheit nicht mod_perl-fähig. Außerdem war mein Rat nun gerade _nicht_, einfach mod_perl zu installieren, sondern, zu analysieren, wo dein Problem genau liegt - und das hast du immer noch nicht gemacht bzw. verraten.
Naja, du wurdest gewarnt - mehr kann man hier im Forum nicht für dich tun.
- Sven Rautenberg