Suchen
Inside Forum
Nützliche Links
phpforum.de Tipp
 
phpforum.de bei Facebook
 
phpforum.de bei Twitter
 

Zurück   PHP Forum: phpforum.de > PHP > PHP

PHP Alles rund um PHP

Antwort
 
Themen-Optionen Ansicht
  #11  
Alt 07.01.2016, 14:06
spinne1000 spinne1000 ist offline
Engagierter Besucher
 
Registriert seit: 22.08.2012
Beiträge: 162
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

Zitat:
Zitat von quantor Beitrag anzeigen
Tatsächlich?
Da bin ich auch verwundert. Bisher habe ich hier noch keinen Hinweis gesehen, dass in einer PHP Anwendungen das ein Thema ist. Ich dachte bisher mySQL kümmert sich darum?
MySQL kümmert sich MySQL-intern darum, das ist schon klar. Aber wenn ich z. b. einen Wert aus der Datenbank auslese, diesen be/verarbeite und danach wieder speichere, kann es ja sein dass dieser Wert in der zwischenzeit geändert worden ist und mein Wert den ich gerade speichern will nicht mehr stimmt weil der ursprungswert geändert wurde.

Beispiel:
Ich lese Wert counter aus: counter = 1
Ich verarbeite diesen (was Zeit braucht:-) ) zu counter = 2
Und speichere diesen dann wieder. Erwartungsgemäss sollte der Wert von counter in der Datenbank 2 sein.
Allerdings könnte es sein, das 100 andere User das selbe gemacht haben und der Wert counter in der Datenbank nicht bei 2 steht, sondern bei 57.. oder 96... oder oder :-)
Die Datenbank hat dafür gesort dass im Moment des Schreibens nur einer schreiben kann. Dann ist es für sie aber getan. Damit obiges nicht passiert musst du dich selbst drum kümmern.
Bei Wikipedia steht ein ausführlicheres Beispiel hierzu was genau das Problem beschreibt.
Ich hatte noch nie eine Anwendung bei der so ein Anwendungsfall relevant wäre und deshalb musste ich mich bisher nie selbst darum kümmern. Wenn man aber einen Wert ändern will auf den mehrere User Zugriff haben (z.B. globale Spielstände könnte ich mir vorstellen) dann wird sowas relevant.
Mit Zitat antworten
  #12  
Alt 07.01.2016, 14:13
masi*:-) masi*:-) ist offline
Engagierter Besucher
 
Registriert seit: 04.09.2008
Ort: FFM
Beiträge: 1.326
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

Nun ja... das ACID-Prinzip ist in der Informatik (nicht nur bei Datenbanksystemen) eine fundamentale Grundlage. Ob es Aufgabe eines Tutorials ist, dies näher zu erläutern, sei dahingestellt. Einen Hinweis auf Transaktionen würde ich in einem DBMS-Tutorial /-Manual aber schon irgendwo erwarten.
Mit Zitat antworten
  #13  
Alt 07.01.2016, 14:54
quantor quantor ist offline
Engagierter Besucher
 
Registriert seit: 25.10.2012
Beiträge: 2.807
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

Zitat:
Zitat von spinne1000 Beitrag anzeigen
MySQL kümmert sich MySQL-intern darum, das ist schon klar. Aber wenn ich z. b. einen Wert aus der Datenbank auslese, diesen be/verarbeite und danach wieder speichere, kann es ja sein dass dieser Wert in der zwischenzeit geändert worden ist und mein Wert den ich gerade speichern will nicht mehr stimmt weil der ursprungswert geändert wurde.
Ach logisch. Was natürlich eine andere aber durchaus komplizierte Problematik ist.

Ist halt die Frage, ob ThomaY tatsächlich von solchen race conditions ausgeht, da er von "dauernd" spricht, es aber in der Praxis selten vorkommt, müßte man Wissen was das konkrete Problem ist.
Mit Zitat antworten
  #14  
Alt 07.01.2016, 22:02
Jens Clasen Jens Clasen ist offline
Vorbildlicher Helfer
 
Registriert seit: 12.02.2005
Beiträge: 14.692
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

OFFTOPIC:

Zitat:
Zitat von ThomaY Beitrag anzeigen
Das gibt mir den Eindruck, dass die meisten das Problem völlig ignorieren oder gar nicht erst kennen.
Diesen Eindruck hast Du nicht allein. Ich hab genau die Predigt mit den Race-Conditions schon in mehreren, durchaus nicht ganz unprofessionellen Firmen gehalten und trotzdem erwischt man genau dieses Problem insbesondere im Web-Umfeld immer wieder. Selbst in recht bekannter Software übrigens.

Man kann (z.B. unter Verwendungen von Transaktionen, geeigneten Locks und/oder durch geeignete Programmierung) das Risiko von Race Conditions minimieren oder sogar ausschließen. Problem dabei ist, dass gerade in verteilten Umgebungen damit eben auch häufig Performance Probleme entstehen, die so nicht erwünscht sind.

Diese Performance-Probleme sind zwar auch vermeidbar, aber die Realität ist meiner Erfahrung nach häufig eine andere:

Häufig werden Race Conditions erst bemerkt, nachdem das Kind 5x in den Brunnen gefallen ist und es fünf unerklärliche Phänomene gab, die lt. Programmierer "gar nicht sein können". Unterm Strich sind sie doch da und dann findet sich auf einem eine Transaktion mit Isolationslevel Serializable rund um einen Satz in Schleifen ausgeführter Selects und Inserts. Am Ende wundern sich dann alle, warum die Performance im Keller ist, denken nach, ob die Software neu geschrieben werden muss und entscheiden sich dafür, doch lieber mit dem Minimal-Risiko der Race-Condition zu leben.

Das ist ja letztendlich genau das Ding: Das Risiko von Race-Conditions ist relativ klein, solang es sich um eine überschaubare Anzahl Aufrufe handelt. Und dann muss die Race Condition ja auch noch einen Impact haben können, der wirklich kritisch ist. Und seien wir mal ehrlich: Im Web-Kontext ist die Anzahl der Anwendungen, die solche Fälle haben, durchaus überschaubar.

Meiner Erfahrung nach sind viele von den diversen Tutorials im Netz nicht von wirklich erfahrenen Entwicklern geschrieben. Der Vor- und der Nachteil der frei verfügbaren Tutorials im Netz ist ja nun mal eben doch, dass jeder eines schreiben kann. Und, wie gesagt, auch in durchaus professionellen Firmen wird häufig auch nur mit Wasser gekocht. Wer weiß also, ob das wirklich anders wäre, wenn es anders wäre.

Außerdem stell ich mir auch ein Stück weit die Frage, ob bei den Handelsüblichen Tutorials im Netz der Leser nicht mit dem Stichwort Race Condition allein auch überfordert wäre.


@Quantor: Das Risiko besteht dauernd - das Problem nur nicht.

Gruß Jens
__________________
Schleichwerbung I - Schleichwerbung II
Mit Zitat antworten
  #15  
Alt 07.01.2016, 22:24
masi*:-) masi*:-) ist offline
Engagierter Besucher
 
Registriert seit: 04.09.2008
Ort: FFM
Beiträge: 1.326
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

OFFTOPIC:
Zitat:
Zitat von Jens Clasen Beitrag anzeigen
Diesen Eindruck hast Du nicht allein. Ich hab genau die Predigt mit den Race-Conditions schon in mehreren, durchaus nicht ganz unprofessionellen Firmen gehalten
Kann man so unterzeichnen. Bin direkt nach meine Studium damals Zeuge geworden, wie in einer systemrelevanten deutschen Bank bestimme Buchungsprozesse wegen Anomalien datenbankseitig auf die Nase gefallen sind und falsche Werte herauskamen.

Antwort: kann man nicht ändern, sonst wäre es langsamer oder kostet mehr Geld. Wenn ein Fehler auffällt, drückt man halt nochmal auf berechnen, dann wirds schon stimmen.
Mit Zitat antworten
  #16  
Alt 08.01.2016, 11:07
Marc Ermshaus Marc Ermshaus ist offline
Forum-Mitarbeiter
 
Registriert seit: 06.09.2004
Beiträge: 5.164
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

OFFTOPIC:
Race conditions sind allerdings in der Tat kein einfaches Thema. Wir behandeln und kommunzieren potenzielle Issues damit hier im Forum zum Beispiel auch selten bis gar nicht (etwa auch TOCTOU-Sachen). Das ist so ein Meta-Thema, das sehr komplex werden kann, aber das meist nur indirekt zum konkreten Problem gehört.

Geändert von Marc Ermshaus (08.01.2016 um 11:12 Uhr)
Mit Zitat antworten
  #17  
Alt 08.01.2016, 15:57
fireweasel fireweasel ist offline
Besucher
 
Registriert seit: 23.02.2011
Ort: Dahoam
Beiträge: 86
Standard EAFP

Zitat:
Zitat von ThomaY Beitrag anzeigen
Ich plane, Webspace zu mieten und dort einen einfachen Spieleserver einzurichten, mit PHP und MySQL.

Werden die Anfragen von verschiedenen Nutzern in der Regel streng nacheinander bearbeitet oder können sie auch parallel bearbeitet werden?
Mit PHP in der "08/15-Installation" und MySQL immer schön nacheinander. Wenn die Schreibvorgänge nicht lange dauern und weit weniger auftreten als die Lesevorgänge, stellt das auch kein Problem dar.

Zitat:
Im zweiten Fall könnte das zu Problemen führen, wenn mehrere Datenbankzugriffe im selben Skript vorkommen. (Stichwort: Transaktionen)
Hüh? Transaktionen sind die sql-datenbanktypische "Lösung" für dieses Problem, nicht die Ursache. Im Kern nichts anderes als File-Locking nur mit ein paar Zusatzfunktionen (quasi "Undo" und "Redo").

Zitat:
Damit verbundene Frage: wie realisiert man am besten eine Wartezeit ... In der Doku zu sleep() schreibt jemand ("ash b"), dass sleep() für diesen Zweck ungeeignet sei, denn es begrenzt nicht die Zahl der Requests, die pro Sekunde bearbeitet werden. Woraus man schließen kann, dass während der "Schlafenszeit" eines Skripts eine andere Anfrage bearbeitet werden kann.
PHP-Scripte (in der typischen Anwendung) laufen nur Bruchteile von Sekunden. Wenn du jetzt sleep() als "Bremse" benutzt, steigt die Anzahl der noch abzuarbeitenden Scripte und damit die der dahinter stehenden Threads, die sich im Hauptspeicher des Servers breitmachen, weil sie noch nicht beendet werden können. Das kann man prima für DoS-Attacken missbrauchen.

Dein Ziel sollte also sein, das Script so schnell wie möglich zu beenden.
* Hat deine Anwendung einen unerwünschten Zugriff erkannt, teilt sie dies dem Client mit und speichert anschließend den Zeitpunkt, zu dem die Sperre abgelaufen sein wird permanent (also bspw. in einer Datenbanktabelle). Dann darf sich das Script beenden.
* Erfolgen weitere Aufrufe (dieser Art) vor Ablauf der Sperrfrist, wird lediglich eine entsprechende Meldung angezeigt und beendet.

Zitat:
Habe irgendwo gelesen, dass es nichts bringt, einen Nutzer anhand der IP zu erkennen und Anfragen von dieser IP eine Wartezeit aufzubrummen. Ein Hacker könne seinen Anfragen viele verschiedene IPs geben.
Definiere: "Hacker".
Das Problem ist weniger der "eine Hacker", es sind mehr die vielen anständigen Otto-Normal-Kunden, die du bei IP-Sperren quasi in Sippenhaft nimmst, weil sie sich eine IP-Adresse mit anderen Usern teilen, bspw. Mobilfunk-Nutzer oder in Betrieben wie http://phpforum.de/forum/showpost.ph...34&postcount=6

Bevor du hier aber weiter über abstrakte Gefahren herumtheoretisierst, solltest du dir erstmal Gedanken machen, welche Dienstleistung du anbieten möchtest. Welche Daten sollen die Nutzer einstellen können, und was sollen sie auslesen dürfen? Ist das geklärt, kannst du dir Gedanken über etwaige Race Conditions und "KiPo" machen.

Geändert von fireweasel (08.01.2016 um 16:01 Uhr) Grund: dämliche-Quote-Tags
Mit Zitat antworten
  #18  
Alt 08.01.2016, 17:47
Marc Ermshaus Marc Ermshaus ist offline
Forum-Mitarbeiter
 
Registriert seit: 06.09.2004
Beiträge: 5.164
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

OFFTOPIC:
Lazy post:

Zitat:
PHP-Scripte (in der typischen Anwendung) laufen nur Bruchteile von Sekunden. Wenn du jetzt sleep() als "Bremse" benutzt, steigt die Anzahl der noch abzuarbeitenden Scripte und damit die der dahinter stehenden Threads, die sich im Hauptspeicher des Servers breitmachen, weil sie noch nicht beendet werden können. Das kann man prima für DoS-Attacken missbrauchen.

Dein Ziel sollte also sein, das Script so schnell wie möglich zu beenden.
* Hat deine Anwendung einen unerwünschten Zugriff erkannt, teilt sie dies dem Client mit und speichert anschließend den Zeitpunkt, zu dem die Sperre abgelaufen sein wird permanent (also bspw. in einer Datenbanktabelle). Dann darf sich das Script beenden.
* Erfolgen weitere Aufrufe (dieser Art) vor Ablauf der Sperrfrist, wird lediglich eine entsprechende Meldung angezeigt und beendet.
Ist die DB-Geschichte im Vergleich zu sleep wirklich so viel sinnvoller? Hast du/jemand dazu zufällig was Weiterführendes?

Ich hätte jetzt spontan gesagt: Ist doch egal (mit „egal“ so im Sinne eines Unterschieds von bis zu einer Größenordnung/bis zu Faktor 10 oder so), ob man als Angreifer wenige „langsame Threads“ auslöst oder viele „schnelle“.
Mit Zitat antworten
  #19  
Alt 08.01.2016, 17:50
Oliver Albers Oliver Albers ist offline
Forum-Mitarbeiter
 
Registriert seit: 03.12.2002
Beiträge: 27.282
Oliver Albers eine Nachricht über ICQ schicken
Standard AW: Parallele Bearbeitung von Benutzeranfragen?

Zitat:
Mit PHP in der "08/15-Installation" und MySQL immer schön nacheinander.
Nein, auch in 08/15-Konfiguration hat man mehrere Worker und damit mehrere parallele Requests. Die Requests einer Session werden natürlich über das Session locking serialisiert. Meinst du das?
__________________
Olli
Mit Zitat antworten


Antwort

Lesezeichen

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu
Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Parallele Prozesse + PHP-Skript sunshine2022 Administration 26 08.07.2012 22:48
Kalender: Parallele Termine qwertzuiop PHP 8 09.02.2011 14:49
php und parallele Programmierung omega PHP 0 10.01.2009 15:40
2 parallele Datenbankverbindungen für 2 verschiedene DB's MarcFdlr Datenbanken 9 19.07.2006 21:41
parallele Mysql Server?! bexxta Datenbanken 2 12.11.2003 07:08


Alle Zeitangaben in WEZ +2. Es ist jetzt 10:35 Uhr.


Powered by vBulletin® Version 3.8.8 (Deutsch)
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
Powered by NuWiki v1.3 RC1 Copyright ©2006-2007, NuHit, LLC