Meine Socketzugriffe sind vollkommen ausgelastet und ich kann mir bei meinen Seiten beim
Besten Willen nicht vorstellen, dass es an der Userzahl liegt.
Laut analythics habe ich maximal 200 Seitenaufrufe am Tag, aber soll 5000 sockets verbrauchen?
Geht das überhaupt?
Heute Mittag gegen 13 Uhr war der Abruf bereits auf 1500 gestiegen. Dachte ich mir, kein Problem, noch über 60% vorhanden und über ein halben Tag vorbei.
Allerdings muss in den Abendstunden irgendwas passieren, sodass ein plötzlicher Anstieg herrscht.
Kann man das irgendwie herauslesen oder die Socketsanzahl erhöhen?
soweit hier gemessen, greifst Du rekursiv sehr häufig auf eine eigene Domain selbst zu, also quasi ein Aufruf bedeutet auch mindestens einen Aufruf auf sich selbst - was auch immer da schief geht, auf konkret pepperoni-lovers.com:80 - kommt das so hin?
Soweit ohne, dass Du Infos wie Deinen Benutzernamen genannt hast, ich richtig geraten habe
Genau, dies ist die Hauptseite, welche betrieben wird. Meine Zweit und Drittseite befindet sich im Aufbau und dürfte daher nicht der gebende Grund sein.
Edit*
Selbst wenn jeder Besucher “doppelt” zählen würde, wären es dann um die 400 Zugriffe, und keine 5000. zudem wundert es mich, dass es in den Abendstunden ist.
Kann ich denn einen Angriff ausschließen? Oder liegt das wirklich an den “Stoßzeiten”?
Kann ich denn irgendwie auslesen, was verantwortlich ist und es ggf. entfernen?
also ich meinte ja auch rekursiv, das heißt, dass sich die Seite offenbar selbst aufruft und dann natürlich wiederum selbst, usw.
Was genau die Ursache ist wäre jetzt interessant, hierzu würde ich mal Dein CMS überprüfen, zB. durch das Abschalten einzelner Module o.Ä, denn ich kann Dir genau sagen, wohin zugegriffen wird, jedoch nicht was genau der Funktionsaufruf in welchem CMS-Modul war
Wahrscheinlich ists nur eine fehlerhafte Einstellung.
Villeicht kann es dann anderen helfen, die das selbe Problem haben.
Ich habe bisher eine “Soutbox” von meiner Seite verbannt, und im Vergleich zu gestern habe ich jetzt im Moment 230 Socket aufrufe (gestern waren es um diese Zeit 1500).
Ich werde wohl die “Stoßzeit” heute Abend abwarten müssen, ob dies den das Problem war.
Wegen dem selbst abfragen:
Ich hab meine subdomain “WWW” als Weiterlweitung an pepperoni-lovers.com eingestellt.
Dies musste ich so tun, damit ich gleichzeitig emailweiterleitungen nutzen kann (ich verstehe auch nicht warum, die anleitung kam von meinem domain Betreiber)
Das wäre vielleicht möglich, ist aber von der Einstellung bestimmt nicht korrekt - da hat www. nichts mit der E-Mailweiterleitung zu tun.
Leite einfach seitens den DNS-Einstellungen pepperoni-lovers.com via Typ A oder CNAME auf unsere Dienste weiter (und genauso nochmal für *.pepperoni-lovers.com) und pepperoni-lovers.com in Typ MX an den E-Mailprovider.
[quote=“miro”][…] via Typ A oder [size=85]CNAME[/size] […][/quote]Da du weißt das er email nutzen möchte, solltest du wissen das CNAME nur bedingt eine Option ist Er also [size=85]A[/size] nutzen muss um hierher aufzuschalten.
Ich gehe auch davon aus, dass in die Richtung auch was vom Domain Anbieter gesagt wurde nachdem email nicht ging… Die [size=85]www.[/size] Subdomain sollte natürlich via [size=85]CNAME[/size] auf seine Domain zeigen.
Diese Einstellung hat mein Domainbetreiber (unitet domains) mir empfohlen, da ich ebenfalls eine Emailweiterleitung nutze (Weiterleitung, kein eigener Mailserver)
Es hatte einen Grund, aber ich möchte jetzt nicht herumexperimentieren warum das so war
Es hatte etwas mit CNAME zu tun, dass man nur Emailweiterleitung nutzen kann, wenn die Hauptadresse (also ohne www.) nicht als CNAME klassifiziert wird, daher das CNAME auf www. und die Umleitung auf www.
Schön Komplex, ja, sonst wärs ja Langweilig.
(Back to topic, Socketauslastung jetzt bei 350, ich fress einen Besen, wenn es wirklich an der Shoutbox lag …)
also eine DNS-Aufschaltung liegt zur Zeit gar nicht vor - bitte ignoriere UD hier mal, nimm bitte folgendes vor, die Domain soll dabei via DNS konfiguriert werden, nicht Weiterleitung, Frame-Weiterleitung oder sonstwas:
pepperoni-lovers.com Typ A mit Ziel: 144.76.167.69
*.pepperoni-lovers.com Typ A mit Ziel: 144.76.167.69
…falls so etwas da nicht namentlich genannt wird, dann halte bitte für eine Option ausschau, die besagt, dass United Domains den E-Mailverkehr regelt (diese einfach aktivieren); dann ist die Domain erstmal korrekt aufgeschalten. Der Rat von UD begründet sich hier wohl eher in der Fehleranfälligkeit für Benutzer, die DNS nicht richtig konfigurieren können - das kommt leider durchaus vor.
Miro erwähnte die „rekursiven“ Zugriffe der Seite „auf sich selber“ ja bereits – wo genau die herkommen bzw. wofür du Sockets nutzt wissen wir ja nicht, aber ich sehe da eine Menge Aufrufe eines Thumbnail-Scriptes in der Form
Das wird vermutlich dazu führen, dass dieses Script dann den Bildinhalt wiederum per HTTP anfordert, was aber eigentlich unnötig sein sollte – denn die Bilder liegen ja in deinem wp-content Verzeichnis, also sollten sie sich auch genauso gut über das lokale Dateisystem des Servers einlesen lassen, ohne einen weiteren „Round-Trip“ via HTTP zu machen (und damit einen Socket-Zugriff zu „verbrauchen“.)
Suche also mal die Stelle, an der dieses Script eingebunden wird (als Inhalt des src-Attributes von Bildern im HTML-Quelltext der Seite), und versuche die Aufrufe so abzuändern, dass sie wie folgt aussehen:
Das zeigt immer noch eine verkleinerte Version des selben Bildes an – allerdings ohne die Adresse des Bildes als HTTP-URL zu übergeben, sondern als (relativen) Pfad innerhalb des lokalen Dateisystems. Damit sollte schon mal eine Quelle für „überflüssige“ Socket-Verbindungen wegfallen.
(Ich weiß nicht, wie genau das Script eingebunden wird – ob das eine Ausgabe ist, die du in einem Template selber erzeugst, oder ob das ein Plugin ist das irgendwo zentral konfiguriert wird – falls letzteres, schau mal ob da irgendwo ein „Basis-Pfad“ o.ä. anzugeben ist, und ändere den wie angegeben um.)
Islidex it ein wordpress Plugin welches auf ausgewählte Bilde zugreift und daraus eine Slidebar erstellt.
Um zu wissen welche Bilder es anzeigen soll, muss dieses Plugin abfragen, welche Bilder dies sind.
Es ist so eingestellt, dass es die Beitragsbilder nutzen soll. Das dies dann wiederum abfragt, welches die Beitragsbilder sind, würde den Socket also plausibel erklären.
Das ist aber eine Abfrage, die nicht so funktionieren sollte - ich meine eher, dass es die Abfragequelle da als fremde Seite interpretiert und nicht als eigene, weswegen es “nach draußen telefonieren” will um die Bildinfos zu suchen, obwohl das Bild doch da ist, nämlich lokal.
Schau bitte inwiefern sich dieses Plugin konfigurieren lässt, nach chrisb’s Analyse ist das durchaus plausibel, dass es daran liegt. Ein Test mit dem Deaktivieren des Plugins dürfte dies nachweisen können indem die Socketzugriffe nicht mehr so hoch sind.
Das heißt konkret einfach, dass das Plugin so zu konfigurieren ist, dass es unter
denn wie Du siehst wiederholt sich der rote Teil und zeigt damit auf sich selbst, was für einen rekursive Mehrfachaufruf hindeutet und damit das Problem erklärt
Der Socketzugriff ist da als solcher auch komplett unnötig, da es das Bild lokal ohne Sockets (sondern mit Datei-öffnen-Operationen) aufrufen kann, statt über eine HTTP-Abfrage (= TCP-Socket).
)
