nicht angemeldet
Website über-benutzung verhindern
Hi!
neulich hat bei mir jemand mit einer unkontrollierten Spider (o.ä.) 2 Stunden mehr Traffic verursacht als ich sonst in einer Woche habe. Jetzt suche ich einen Weg solche Leute auszuschließen, z.B. nach 100 Pageviews in 100 Sekunden. Eine fertige Lösung (PHP-Modul o.ä.) habe ich bisher nicht gefunden.
Um es selber zu machen müsste ich Daten zur IP-Adresse speichern. Und das bei *jedem* Pageview. Quasi ein "Server-Side Sessionhandling". MySql und Dateisystem scheiden damit aus Performancegründen aus. Cookies auch, denn die Spider kann sie ignorieren. Am liebsten würde ich was auf dem Server im Ram speichern. "Memcache" kann das wohl, ist aber bei meinem Hoster nicht installiert.
Kennt jemand noch andere Methoden?
Thomas
--
Outlook Duplikate löschen
-
Um es selber zu machen müsste ich Daten zur IP-Adresse speichern. Und das bei *jedem* Pageview. Quasi ein "Server-Side Sessionhandling". MySql und Dateisystem scheiden damit aus Performancegründen aus.
Ich würde an deiner Stelle Sessions nehmen und es darin speichern, auch wenn diese im dateisystem gespeichert werden. Linux/Windows bzw das Dateisystem haben effiziente Caching Algorithmen.
Allerdings kansnt du damit auch nur die Aufrufe auf dein Script verhindern, die Aufrufe von Bildern o.ä. verhinderst du so nicht.
--
ie:{ br: fl:( va:) ls:& fo:| rl:( n4:( de:] ss:) ch:| js:| mo:| sh:( zu:)-
Hi!
Ich würde an deiner Stelle Sessions nehmen und es darin speichern, auch wenn diese im dateisystem gespeichert werden. Linux/Windows bzw das Dateisystem haben effiziente Caching Algorithmen.
Wenn der Client aber keinen Session-Cookie annimmt oder auch ansonsten den Parameter mit der Session-ID nicht mitgibt, bleibt der Traffic der gleiche, nur jetzt kommt zusätzlich noch hinzu, dass Session-Dateien angelegt werden.
Lo!
-
Wenn der Client aber keinen Session-Cookie annimmt oder auch ansonsten den Parameter mit der Session-ID nicht mitgibt, bleibt der Traffic der gleiche, nur jetzt kommt zusätzlich noch hinzu, dass Session-Dateien angelegt werden.
Gut, dann keine Sessions, aber du bringst hier was durcheinander: Was hat der Traffic mit Festplattennutzung gemeinsam?
--
ie:{ br: fl:( va:) ls:& fo:| rl:( n4:( de:] ss:) ch:| js:| mo:| sh:( zu:)-
Hi!
Wenn der Client aber keinen Session-Cookie annimmt oder auch ansonsten den Parameter mit der Session-ID nicht mitgibt, bleibt der Traffic der gleiche, nur jetzt kommt zusätzlich noch hinzu, dass Session-Dateien angelegt werden.
Gut, dann keine Sessions, aber du bringst hier was durcheinander: Was hat der Traffic mit Festplattennutzung gemeinsam?Wenn jeder Request eine Session eröffnet, dann wird dafür jeweils eine Datei für die Session-Daten gespeichert - zumindest wenn man nicht den Default-Session-Mechanismus PHPs ändert.
Lo!
-
Wenn jeder Request eine Session eröffnet, dann wird dafür jeweils eine Datei für die Session-Daten gespeichert - zumindest wenn man nicht den Default-Session-Mechanismus PHPs ändert.
Ja, ist die Festplattenaktivität dir zu hoch oder _wo_ ist dabei dein Problem? Mir kam es so vor, als ob du das mit Traffic verwechselst ;)
--
ie:{ br: fl:( va:) ls:& fo:| rl:( n4:( de:] ss:) ch:| js:| mo:| sh:( zu:)-
Hi!
Wenn jeder Request eine Session eröffnet, dann wird dafür jeweils eine Datei für die Session-Daten gespeichert - zumindest wenn man nicht den Default-Session-Mechanismus PHPs ändert.
Ja, ist die Festplattenaktivität dir zu hoch oder _wo_ ist dabei dein Problem? Mir kam es so vor, als ob du das mit Traffic verwechselst ;)Die Festplattenbelegung und -aktivität erhöht sich mit deiner Lösung unter Umständen zusätzlich zum Traffic noch, weil dabei Sessions angelegt werden, ohne dass sie zum Reduzieren des Traffics etwas beitragen können. Wie gesagt, das passiert, wenn der Client ein Session-ID-Verweigerer ist.
Lo!
-
Die Festplattenbelegung und -aktivität erhöht sich mit deiner Lösung unter Umständen zusätzlich zum Traffic noch, weil dabei Sessions angelegt werden, ohne dass sie zum Reduzieren des Traffics etwas beitragen können. Wie gesagt, das passiert, wenn der Client ein Session-ID-Verweigerer ist.
Willst du deine Festplatte schonen oder den Traffic gering halten? Eins von beiden musst du machen.
Ansonsten noch eine Idee, falls du gerne programmierst & dich mit Sockets auskennst:
du programmierst einen Server (z.B. in C++) der sich die IPs merkt. Dieser lauscht auf der Loopback Schnittstelle. Per PHP öffnest du eine persistene Verbindung und übergibst diesem Server die IP zum Überprüfen. Der kann es im Ram ohne hdd-Aktivität speichern ;)
--
ie:{ br: fl:( va:) ls:& fo:| rl:( n4:( de:] ss:) ch:| js:| mo:| sh:( zu:)-
Hi!
Willst du deine Festplatte schonen oder den Traffic gering halten? Eins von beiden musst du machen.
Eben darum geht es ja. Du solltest aber keine "Lösung" implementieren wollen, die einfach nur das eine lässt wie es ist und dazu was anderes erhöht.
Lo!
-
-
-
-
-
-
-
-
neulich hat bei mir jemand mit einer unkontrollierten Spider (o.ä.) 2 Stunden mehr Traffic verursacht als ich sonst in einer Woche habe. Jetzt suche ich einen Weg solche Leute auszuschließen, z.B. nach 100 Pageviews in 100 Sekunden. Eine fertige Lösung (PHP-Modul o.ä.) habe ich bisher nicht gefunden.
Ich sehe nur eine Methode:
Einem Script eine log routine mitzugeben, welche im Zweifelsfall eine betroffene .htaccess Datei umschreibt und die IP sperrt.Damit das kein genereller Performanceeinbruch bringt, kannst du die Ausführung der Routine durch Kriterien beschränken.
Entscheidend ist, ob das ein Einzelfall ist, oder ob dies periodisch unter einem bestimmten gemeinsamen Merkmal, oder dem Fehlen desselben, auftritt.Fehlfunktionierende Software ist manchmal nicht in der Lage, gültige HTTP Requests abzusetzen. Dies lässt sich ausnutzen. So ist ein Accept Header zum Beispiel Pflicht.
Ziel ist nicht, die Requests zu stoppen (wirkunslos ausser bei massiven Massnahmen), sondern unnötige CPU Leistung durch billige 403er zu beantworten.
PS: Wenn Bots über reguläre Proxies agieren, wirkt ein 410er Wunder.mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
» Einem Script eine log routine mitzugeben, welche im Zweifelsfall
» eine betroffene .htaccess Datei umschreibt und die IP sperrt.
Genau das habe ich vor.Das Problem ist: Wann mache ich das?
Um einen übermäßigen Aufruf effizient zu erkennen und die Serverlast zu VERRINGERN (siehe Diskussion unten) bräuchte ich einen Mechanismus um Variablen so im Ram (und nicht auf Festplatte, DB, Cookies) zu speichern, dass ich diese beim nächsten PHP-Skript wieder auslesen kann.
Und in dieser Beziehung scheint PHP noch sehr schwach aufgestellt zu sein. Oder gibt's da einen Trick (außer Memcache) den ich noch nicht kenne?
Thomas
--
Mein Devblob-
Hi,
Um einen übermäßigen Aufruf effizient zu erkennen und die Serverlast zu VERRINGERN (siehe Diskussion unten) bräuchte ich einen Mechanismus um Variablen so im Ram (und nicht auf Festplatte, DB, Cookies) zu speichern, dass ich diese beim nächsten PHP-Skript wieder auslesen kann.
Und in dieser Beziehung scheint PHP noch sehr schwach aufgestellt zu sein. Oder gibt's da einen Trick (außer Memcache) den ich noch nicht kenne?
SHMOP gibt's auch noch.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
SHMOP gibt's auch noch.
MfG ChrisB
Das funktioniert (auch bei meine Hoster).
@ChrisB: Vielen Dank!
Thomas
--
Outlook Duplikate suchen
-
-
-
-
Grüße,
IP in der SQL db wäre doch nicht so abwegig - was spricht dagegen?MFG
bleicher
