Beiträge von Synonym

Ja, da siehste mal, dass sich da vieles geändert hat. Ein reiner Algo war vor langer Zeit. Google (die Suche selbst) ist jetzt immer noch ein reiner Algo, aber eben auch ein Algo besteht nur aus Funktionen und Ergebnissen anderer Gleichungen. Und von dieses immer wieder gesagten "über 200 Faktoren" sind viele komplett automatisch, andere händisch. Muss man sich auch so vorstellen, dass der Faktor "Spamseite" durchaus im Algo immer wieder neu justiert wird, damit der Algo das automatisch erkennen kann. Nur für die Justierung dient dann ein Datenpool "Spammeldungen", die stimmen können, aber nicht müssen. Auf dessen Basis wird dann quasi der Algo (Teilfunktion) erstellt und fließt in den "großen" ein. Somit trifft der dann automatisiert auch andere Seiten, die vorher noch nie einer gesehen hatte. Somit kann Google hier wieder sagen, es geht alles "automatisch". Aber mal ehrlich, automatisch geht gar nichts, nirgends. Alles braucht einen Input und die Logik des Algos muss auch definiert werden. Und genau hier entstehen die Fehler.

"Hab diese QR-Anleitungen von "Mitarbeitern" nie gelesen"
Das ist schade. Der letzte war etwas "geschwärzt", aber der davor war sehr ausführlich und informativ. Da steht auch nicht nur allgemein SEO drinnen, sondern alles mögliche, unter anderem was ein Browser ist, wie ein Cookie funktioniert, wie man sich in Browser xy den Quelltext anzeigen lassen kann etc. Im Grunde ist das eine Anweisung für Leute, die schlicht null Ahnung von Internet und Computern haben.

Und dann eben das SEO Zeug, aber auch nicht nur, dass man dies und jenes machen soll, sondern direkte und echte Beispiele. z.B. warum die Seite toysrus für bestimmte Keys als "sauber" anzusehen ist, für andere aber ein Flag gesetzt werden soll und für wieder andere direkt ein "Filter" vorgenommen werden "muss". Da ist alles erklärt, auch die ganzen "Filter" bzw. "Flags". Welche es gibt, für was und wann. Warum und warum nicht etc.

Auch bei toysrus, habe ich noch im Kopf, weil ich das einfach eine Frechheit fand. Da war das Beispiel mit einer Unterseite. Da wurde ein kleines ferngesteuertes Auto verkauft (kabelgebunden, kein Funk). Diese Unterseite sollte für die Suchanfrage "Babyspielzeug" in den Filter und als "unrelevant" markiert werden, weil... Der Grund, der in der Anleitung so drinnen stand: "Weil dieses Auto Kleinteile enthält oder enthalten könnte, die das Baby verschlucken könnte. Das Auto somit für ein Baby nicht geeignet sei und der Treffer für die Suchanfrage daher als "unrelevant" einzustufen ist".

Die nehmen sich also auch das Recht heraus, über Produkte zu entscheiden und dann zu sagen ja oder nein. Da geht es nicht nur rein um die Webseite, sondern auch um das, was da verkauft wird. Oder andere Seiten mit der Begründung "schwer verständliche Navigation", "Unübersichtlicher Aufbau" etc.

Und ja, Dein Vergleich mit Wiki war gar nicht schlecht. Ich selbst dachte da direkt an DMOZ Und das vBulletin hier ist auch nicht viel anders. Eine Führung ganz oben, ein QR-Team und ganz ganz viele User, die Fehler suchen und berichten müssen und gleichzeitig dann quasi auch entscheiden, welche der gemeldeten Fehler dem QR-Team überhaupt vorgelegt werden.

Hast mich falsch verstanden Cura. Panda ist automatisch, da bin ich mir auch sicher. Nur die Datenquellen nicht unbedingt. Dieses "was ist böse, das nicht, was bekommt ein Flag, was nicht" erfolgt eben per Hand.

Zitat

Und wenn Du jetzt sagtst

Ja wenn? Das mache ich nämlich Mist, fange schon an wie der 800er

Zitat

Und wenn Du jetzt sagtst, dass da erst tausende Laien, Hausfrauen etc rumwerkeln, deren Fehler dann von echten QR nach Aufforderung korrigiert werden ist das eigentlich eine Sauerei.

Aber genau danach schaut es aus. Das sagt Google nicht selbst, aber das geht aus den "QR-Anleitungen" hervor, die ja nicht Google, sondern Teilnehmer davon veröffentlicht haben. Da schaut in etwa so aus Google -> Cutts -> echte Rater -> Datenerfasser

Zitat

Google spart zunächst mal Geld für gutes Personal und die Webmaster müssen dann darum betteln nicht betteln gehen zu müssen

So ist es aber. Der Algo hat recht, auf Basis seines Inputs. Du oder ich als Webmaster musst dann "beweisen", dass der Input falsch ist.

Und ja, 1 + 1 = 10 Die Rechnung stimmt auch Ist nur eine andere Sichtweise. Andere würden sagen, nee, das ist 2 oder 11. Aber nein, 10 stimmt!

Und Google Aussage, die würden die richtigen treffen, stimmt auch, nur ob die auch richtig ermittelt wurden ist fraglich.

Zitat von catcat

Auch, wenn die 1000x behaupten, sie können gute und schlechte Sites unterscheiden anhand von x Merkmalen... das ist in meinen Augen größtenteil Mummpitz.

Ist es auch, irgendwie. Die Auswertung auf Basis der Merkmale werden wohl schon stimmen, also ist die Aussage richtig, doch wer sagt, dass die Merkmale stimmen (da viele von Usern erfasst, die keine Ahnung haben)? Somit stimmt Deine Aussage!

Aber dem jetzt mal außer Acht gelassen. Hat hier jemand Änderungen wegen dem Panda 4.0 bemerken können?

Genau das ist das Problem, eine Logik ging es da nicht. Gut, Panda ist nun eine automatisiere Sache, greift aber halt auch auf Flags zurück und die werden manuell vom QR gesetzt. Und ja, Deine Einschätzung ist wohl richtig, daher gibt es ja auch so viele unberechtigte Opfer. Daher soll man ja auch den Wiederaufnahmeantrag stellen, denn das prüft dann ein echter QR von Google und keine Hausfrau zwischen Sellerie und Rinderbraten.

Ja und nein, Cache ist hier eben nicht Cache.

Da gibt es die echten Obcode und Object-Caches wie APC und memched, da arbeiten wirklich selbst und autark. Dann gibt es noch die "Caches" in der Datenbank selbst. Das sind aber eben quasi nur "aktuelle Zustände", die hinterlegt werden, damit die nicht bei jedem Zugriff neu berechnet werden müssen. Gleich das Ergebnis zu haben ist halt schneller, als es erst berechnen zu müssen und die Query für den Cache ist schlanker. Muss man sich so vorstellen, dass die Seite eines Threads quasi fertig gerendert als "cache" in der DB gespeichert wird. Dann muss man nur noch den Code abfragen und anzeigen, nicht neu alles zusammenbauen. Hat aber wohl auch den Nachteil, dass es Verzögerungen gibt. Das müssen wir testen, was sinnvoll ist und was nicht. Wenn ich mich nicht irre, dann gibt es die Option auch für Gäste. Also angemeldete User direkt, Gäste mit Cache oder so. Irgendwas war da.

Und dann kommt noch ein weiterer Cache hinzu, der oben noch gar nicht steht (wollte ich schon lange sagen, steht auf meiner "Info für Alex-Liste", vergesse es aber immer wieder) und an dem auf jeden Fall was gemacht werden muss: Der qCache von MySQL.

Nur kurz: Du verwendest aktuell einen sehr hohen Key-Buffer (glaube 2GB), das ist gut, aber... Gut für MyISAM-Tabellen, das Forum verwendet aber InnoDB (4 kleine MyISAM, 2 Memory und der Rest InnoDB) Also hier muss man ansetzen, aber dazu braucht es detaillierte Daten aller laufenden Dienste und Datenbanken auf dem Server. Es bringt nichts, den Key-Buffer einfach um 1GB zu reduzieren und den qCache um 1GB zu erhöhen. Kommt drauf an, welche anderen Datenbanken da noch auf dem Server sind welche Storage Engine die verwenden und wie viel Platz deren Indexe einnehmen. (Dazu aber dann mehr in einem eigenen Thema) Ebenso anderes Thema, den Server aufräumen. Denn auch die Db-Sicherungen belegen die Speicher, auch wenn die gar nicht verwendet werden, sowie die alten Tabellen aus vb4 und älter bzw. ehemalige Plugins. Dein Forum hier hat 50% mehr Tabellen als mein original vb5 Aber wie gesagt, das gibt eigene Themen im Bereich Hosting, gehört hier nicht wirklich er.

Ansonsten, die ganzen Caches, vor allem die echten bzw. qCache, reduzieren die Anzahl der Anfragen in der Regel nicht, denn gestellt werden müssen die ja. Der Unterschied ist nur, dass MySQL sie dann nicht selbst "berechnen" und dafür auf die Festplatte zugreifen muss, sondern sagen kann "Die Antwort liegt hier im Memory". Ist quasi wie bei HTTP, wo ein Request gestellt wird und dann 200 oder 403 kommen kann. Der Request ist da, nur der Server muss einem reagieren und ausliefern und einmal "nicht".

Und, gehört ja auch irgendwie mit zum Cache, auch wenn nicht vBulletin. Schiebe mal bitte einen Zugang zur APC.php in das Root vom Testforum (als Symlink, eventuell Zugangsdaten in der apc.php hinterlegen). Ich muss mal sehen, was da so hinterlegt / gespeichert wird.

Nachtrag: Verwirrend, ja, das auf jeden Fall und schlicht auch zu viel meiner Meinung nach. Wäre der Core besser geschrieben, dann bräuchte es das ganze auch nicht.

Hier geht es also um die Caches von vBulletin und hier insbesondere den Datastore, der meiner Meinung nach eine sehr wichtig und tragende Rolle einnimmt.

Was ist der Datastore?
Grob gesagt werden im Datastore Ergebnisse von Abfragen gespeichert, die vorher aus anderen Tabellen abgefragt wurden. Der Sinn ist also, die vielen Anfragen der einzelnen Tabellen zu reduzieren, da oft die Antwort "gleich" bleibt und daher direkt den Datastore abzufragen. Somit muss eine Information dann nicht mehr über z.B. 7 Tabellen zusammengesucht werden, sondern steht direkt als fertiges Ergebnis im Datastore und kann mit einer Query abgefragt werden.

Der Haken an der Sache ist nur, dass der Datastore selbst in der Datenbank gespeichert ist. Auch wird dieser nicht einmal abgefragt, um alles zu haben, sondern viele viele Male pro Seitenaufruf.

So, und hier kommen dann schon die eigentlichen Caches, die richtigen Caches ins Spiel: z.B. APC. Ist das aktiviert, dann wird der Datastore nicht in der Datenbank gespeichert, sondern direkt im Hauptspeicher. Dort ist der Zugriff dann natürlich unverhältnismäßig schneller!

Warum sind Caches aber so wichtig?
vBulletin ist so ausgelegt, dass alle Abfragen möglichst kurz und einfach sind. Das hat aber auch den Nachteil, dass zig Datenbankabfragen getätigt werden müssen. Z.B. bei einem Post: Nur Auszugsweise: Die Forenberechtigungen, die Optionen, die Session, der Post selbst, die Signatur, das Avatar, der Username, die Reputation, die ganzen Templates , die für die Anzeige benutzt werden und natürlich jede einzelne Phrase (Platzhalter im Template), denn die stehen auch in der Datenbank. Teilweise (sehr oft) erfolgen diese Abfragen nicht direkt in einer Tabelle sondern mit Joins über mehrere. Daher gibt es auch die internen Caches, die diese Ergebnisse zwischenspeichern.

So ergibt das z.B. auch, dass für eine ganz simple Seite, die wohl jeder von uns rein in HTML erstellen könnte, 75 DB-Anfragen erforderlich sind. Sie Seite /contact-us (ganz unten rechts).

Der Debug von vBulletin:

Informationen zur Fehlersuche


    Seiten-ID: 5
    Übergeordnete ID: 1
    Seitentemplate-ID: 8
    Route-ID: 15
    Seitentyp: custom
    Seitenlayout-ID: 1
    Seitenlayout-Template: screenlayout_1
    Kanal-ID:
    Knoten-ID:
    Datenbankzugriffe: 75 (?)
    AJAX Anfragen: 1
    Facebook aktiv: Nein (Nicht aktiviert oder keine appid & Schlüssel angegeben.)
    Style-ID: 2
    Templates/Renders: 18/25
    CSS Templates: 6
    Current Time: r

So, soviel erst mal. Die anderen "Caches", also Node-Cache und dergleichen, was vBulletin da noch so alles ablegt, kommen später.

Alex, ich habe alles so wie bei Dir, bestmöglich nachgebildet. Alle Caches sind aus ... Aber mal einen neuen Thread zu, muss auch Infos sammeln und das gehört hier nicht wirklich rein.

Zitat von catcat

160 DB-Zugriffe? :error: Alter...
Da haben die Entwickler aber voll die Sau rausgelassen :bad:

So, mal so als OT hier rein. Eben im Testforum auf der Startseite:

[B]Informationen zur Fehlersuche[/B]


    Seiten-ID: 1
    Übergeordnete ID: 0
    Seitentemplate-ID: 42
    Route-ID: 4
    Seitentyp: custom
    Seitenlayout-ID: 2
    Seitenlayout-Template: screenlayout_2
    Kanal-ID: 1
    Knoten-ID:
    [COLOR=#FF0000][B]Datenbankzugriffe: 240 (?)[/B][/COLOR]
    AJAX Anfragen: 1
    Facebook aktiv: Nein (Nicht aktiviert oder keine appid & Schlüssel angegeben.)
    Style-ID: 2
    Templates/Renders: 30/60
    CSS Templates: 6
    Current Time: r

Zitat

Einige hundert QR durchkämmen zwischen den Updates das Netz

Hunderte? Das sind tausende und die Mehrheit von denen arbeitet nicht für Google, die nehmen nur an dem QR-Programm teil. Kann jeder, da muss man keine Ahnung haben. Man bekommt einen Zettel, was man wie machen soll und dann kreuzt man einfach an. Und wenn man die Anweisungen falsch versteht oder verstehen will, dann kreuzt man halt falsch an

Achso, das meinst Du. In der Config von vBulletin kannst Du aber nur den APC-Objekt-Cache deaktivieren, nicht APC selbst, also den Obcode. Der normale ist aber also an.

Doch CatCat, kann man Das Problem nur, dann gibt es einen Folgefehler, den man so nun nicht erkennt, da die Angabe zu spät kommt. Die ganzen URLs sind der Bilder sind falsch (&). Der Validator spukt die so aber nicht als Fehler aus, weil es eben nicht richtig testen kann.

Und 100% sicher bin ich mir auch noch nicht, ob da zwischen "preheader" und "header" nicht noch was anderes passiert. Bei der Software weiß man ja echt nicht.

Danke, also das hier: Google Payday Loan Algorithm 2.0 *** Link veraltet ***
Allerdings muss ich auch sagen, dass ich da so rein gar nichts verstehe... Ist wohl noch zu früh am Morgen

Ja toll, da werden die Rankings seit ein paar Tagen gerade wieder etwas besser und dann kommt Google Panda 4 gleich hinterher. Mich würde nun aber wirklich interessieren, ob Panda 4 nun wirklich am 20.05.2014 startete oder vielleicht doch schon ein paar Tage vorher. Wenn schon vorher, dann könnten die Änderungen am Wochenende ja auch darauf zurückzuführen sein ... Hm ...

Ok, das "-1" ist klar, das ist "Forum Standard". Aber der Rest wird im Core fest vorgegeben, die Einstellungen aus dem ACP nicht beachtet. -> zu 99% -> BUG!

Tzzz, da denkt man, man hat eine Option was zu verändern und dann doch nicht.:wall:

Klar im Team, aber nicht mit anderen Usern als Kaninchen Aber habe ich das jetzt richtig verstanden? APC ist auch aus? Lege da mal bitte die apc.php ins Root oder einen versteckten Unterordner (samt Zugang), damit ich mir das ansehen kann.

-> nicht jetzt -> die nächsten Tage / Wochen.

Also bei Adsense sehe ich null Veränderung... Ist weiterhin bei -60% zum Vorjahr *heul*

Zitat von Alex07

der hier hat 64GB Ram
leider nur. könnte mehr vertragen.

:dance: Das haben meine alle zusammen nicht mal annähern. Ich glaube das sind so (mit dynamisch) 12 GB Aber schon mal gut zu wissen, denn die Serverdaten sehe ich ja nicht. So als Ansatz zur MySQL-Optimierung.

Wegen den Beiträgen. Habe die nun auf "5,10,20,30,40,60,80,100" gesetzt, aber es bleibt dennoch bei maximal 40. Keine Ahnung warum. Muss ich mal schauen. Systemcache ist geleert, neu angemeldet auch.

Wegen dem Cache auf jeden Fall, aber erst viel später. Erst muss des sonstige Zeug beseitigt werden, dann der Server selbst, dann der Cache. Wenn das nicht so ein 256MB -Server ist wie meiner (Piwik - ja, den habe ich noch immer), dann kommt der damit schon zurecht

"wir machen das für alle so"
Klar, für alle als Option, anders geht es ja nicht. Nur eben nicht als Default, da bleibt es bei 20. Aber genau dieses "für alle" ist ja der Punkt. Wenn da 2 oder 3 Leute auf 100 Stellen, dann ist das schnuppe. Hat das Forum aber mal 1000 wirklich aktiv User und 200 haben die Einstellung, dann schaut es anders aus

Hm, ich merke von meinen neuen "tollen" Positionen leider nicht wirklich viel. Tarffik +5% oder so. Die Keys sind halt noch immer auf Seite 2 oder 3. Gut, vorher war es Seite 50, 60 oder 70.

Alex, das war nur so eine Anmerkung. Lasse den vorerst Cache aus. Der muss erst gründlich getestet werden und das geht alleine in einem Testforum nicht sonderlich gut Aber ein anderes Thema wird noch kommen: Server-Optimierung, speziell MySQL, denn das ist alles andere als optimal. Man merkt, dass der Server richtig Leistung hat, aber da wird auch vieles von verschenkt

Momentan, also mit den "wenigen" Usern (und Gästen, Bots, etc.) und über den ganzen Zeitraum von etwa 4 Wochen gesehen, befeuert das Forum Deine Datenbank mit ca. 13 Anfragen pro Sekunde, 24 Stunden am Tag.

Zitat

bin etwas deprimiert deswegen. du bist da schon weiter.

Dazu gibt es keinen Grund :holly: Diese Daten hast Du alle nicht, ohne permanent im Debug-Modus zu arbeiten oder den Core zu durchforsten und eigene Debugs loggen zu lassen und das geht hier ja auch nicht