DREHSCHEIBE-Online 

Anzeige

HIER KLICKEN!

 01 - News 

  Neu bei Drehscheibe Online? Hier registrieren! Zum Ausprobieren und Üben bitte das Test-Forum aufsuchen!
News und aktuelles Betriebsgeschehen - Achtung: Werbung und Updatemeldungen für Websites werden gelöscht, bzw. ins Allgemeine Forum verschoben!
Links bitte mit kurzer Erklärung zum verlinkten Inhalt versehen, andernfalls werden diese entfernt.

Seiten: 1 2 3 4 5 6 All

Angemeldet: -

Liebe Nutzerinnen und Nutzer von Drehscheibe Online,

in den letzten Tagen und Wochen gab es zahlreiche Klagen über die Foren von Drehscheibe Online, insbesondere über die langen Wartezeiten und die zeitweilige Nichterreichbarkeit. Diese Klagen sind zu einem guten Teil gerechtfertigt. Allerdings sind dabei einige User weit übers Ziel hinausgeschossen, während Andere versucht hatten, von ihrem Kenntnisstand aus Ursachenforschung zu betreiben, bzw. Lösungsvorschläge zu erarbeiten. Diese aktive Mitarbeit der User freut unss ganz besonders, auch wenn dabei bei einigen Leuten eher abenteuerliche Vorschläge herausgekommen sind.

Zuerst mal möchte ich eines feststellen:
Wir sitzen nicht herum und warten darauf, dass sich die Probleme von allein lösen, sondern arbeiten aktiv an einer dauerhaften Lösung. Nachdem sich eine Lösung, welche voraussichtlich für längere Zeit und nicht nur für einige Monate genügt, nicht innerhalb einiger Tage realisieren lässt, werden wir zunächst einige Maßnahmen ergreifen, welche vorerst die Serverlast etwas verringern, um das Lesen und Schreiben bei DSO wieder angenehmer zu machen.
Dabei bitte ich um Verständnis, dass wir hier nicht im Einzelnen erläutern, was wir im Einzelnen wann und wieso machen - wir reden nicht gern über ungelegte Eier ;-).

Einige Anmerkungen zu den Ursachen und zu den vielen Vorschlägen us dem Forum:
Zahlreiche User haben Mutmassungen angestellt, wieso DSO innerhalb sehr kurzer Zeit wesentlich langsamer geworden ist. Meistens wurde entweder die Datenbank-Konfiguration, die Forensoftware oder der Forenserver verdächtigt. Dies ist jeweils teilweise richtig, aber die Performance-Probleme resultieren aus einer Kombination verschiedener Ursachen.
Leser mit tiefergehenden Kenntnissen im Bereich Datenbank bitte ich um Verzeihung, dass ich mit Rücksicht auf die große Mehrheit der Nicht-IT-Fachleute im Forum nach Möglichkeit auf Fachausdrücke und eine ausführliche Darstellung der Hintergründe verzichte.

Einerseits wird der Bestand an Beiträgen bei Drehscheibe Online immer größer. Inzwischen sind es über 1,3 Millionen Beiträge, welche in der Datenbank annähernd drei GB belegen. Dies ist beim Lesen und Schreiben an sich kein Problem. Auch bei einer zehnfachen Menge würde das eigentlich kaum langsamer gehen, denn jeder Beitrag ist durch eine eindeutige Nummer gekennzeichnet, die man auch im Link zu einem Beitrag findet. Sobald man den Link zu einem Beitrag anklickt, dann wird er innerhalb einer hundertstel Sekunde gefunden. Dies funktioniert so, wie wenn man in einem Telefonbuch nach einem Namen sucht - man blättert nicht das Buch von vorn nach hinten durch, sondern geht nach der alphabetischen Sortierung und ist damit schnell am Ziel. Was dagegen immer länger dauert, je mehr Beiträge vorhanden sind, ist naturgemäß das Suchen nach bestimmten Begriffen. Dies führt unter bestimmten Umständen - welche gar nicht so selten sind - dazu, dass alle Beiträge von vorn bis hinten durchsucht werden müssen. Dies wiederum bremst natürlich den Server für eine gewisse Zeit. Deshalb kann manche umfangreiche Suche bis zu zwei Minuten dauern. Dies bedeutet natürlich NICHT, dass der Server in dieser Zeit nichts anderes mehr machen würde - aber alle anderen Aufgaben werden dann langsamer erledigt. Wenn gleichzeitig etliche User die Suchfunktion intensiv nutzen, dann dauern naturgemäß die ansonsten sehr schnellen Abrufe der Beiträge auch länger.

Dies führt zur zweiten Ursache: DSO hat immer mehr User, welche immer mehr Beiträge lesen und schreiben. Inzwischen werden am Tag meistens mehr als 1000 Beiträge geschrieben und diese Beiträge werden über 300.000 mal am Tag gelesen. Dies wäre auch kein Problem - wenn die Zugriffe gleichmäßig erfolgen würden. Das ist aber illusorisch - denn naturgemäß sind z.B. nachts nur wenige User online. In der Praxis werden 90 % der Zugriffe in 50 % der verfügbaren Zeit getätigt. Und auch diese Zugriffe sind dann nicht gleichmäßig verteilt. Die Auslastungskurve des Servers geht grundsätzlich in einem recht wilden Zickzack auf und ab. Damit gibt es aber immer wieder kurze Zeiten, in denen extrem viel los ist, gefolgt von ebenso kurzen Augenblicken mit weniger Serverlast.
Je höher aber die durchschnittliche Belastung der Kiste ist, desdo höher ist die Wahrscheinlichkeit, dass die Abfragen noch nicht abgearbeitet sind, bis die nächsten Anforderungen hinterher drängeln. Und genau dann beginnt das, was ein User in seiner Signatur etwas reisserisch mit "Ich hasse es!" betitelt hatte.
Man kann sich das relativ einfach vorstellen: Wenn eine Anfrage, z.B. zum Lesen eines Beitrags, normalerweise 0,02 Sekunden dauert, dann könnten 50 User im Sekundentakt (50 * 0,02 = 1 Sekunde) Beiträge anklicken, ohne dass sie merkliche Wartezeiten hätten. Wenn dabei einmal mehrere Leute gleichzeitig klicken, dann würde es etwas länger dauern - und sich in den Augenblicken, wo niemand klickt, wieder normalisieren. In der Praxis wird aber niemand jede Sekunde einen neuen Beitrag anklicken, außer vielleicht, um für ihn weniger interessante Themen als gelsen zu markieren. Somit würden in diesem Fall noch viel mehr User gleichzeitig lesen können. Wenn sich jedoch aus irgendwelchen Gründen die Antwortzeit im Beispiel auf 0,04 Sekunden erhöht - was für den Menschen noch immer eine kaum erfassbare Zeitspanne ist, dann würde innerhalb weniger Sekunden ein beträchtlicher Rückstau entstehen. Plötzlich warten die 50 User einige Sekunden lang auf die Beiträge - und klicken aber munter weiter. Nun verwendet jedoch das WWW ein sogenanntes "verbindungsloses Protokoll". Dies bedeutet, dass der Server niemals weiß, ob der PC des Anwenders überhaupt noch auf die Antwort wartet. Er liefert also den Beitrag aus - auch wenn der ungeduldige Mensch am Rechner schon weiter geklickt hat, den Beitrag per "Aktualisieren" noch einmal aufruft, oder gar nicht mehr bei DSO online ist.
Und genau hier beginnt die Malaise. Sobald die angeforderten Seiten nicht mehr schnell genug zurück geliefert werden, wird es immer langsamer. Wenn es langsamer wird, sind viele User versucht, weiere Beiträge in zusätlichen Tabs zu öffnen, oder durch erneutes Anklicken, bzw. aktualisieren den Server vermeintlich zu einer schnelleren Reaktion zu bewegen. Dies hat jedoch denselben Effekt, wie wenn sich die Autofahrer bei einer Staumeldung alle auf die überlastete Autobahn begeben würden - in der Hoffnung, dass es dann schneller gehen würde. Der Autofahrer weiß natürlich, dass in diesem Fall eher das Gegenteil eintritt - der Internet-User im allgemeinen nicht. Allerdings hat der DSO-User auch keinen Verkehrsfunk, der ihn vor dem Stau warnt und naturgemäß auch keine Umleitungsstrecken.

Hier kommen wir zur "Lieblings-Fehlermeldung" vieler Nutzer. Je höher die Serverlast ist, desdo länger braucht der Server natürlich auch, um le nötigen Daten aus der Datenbank auszulesen. Aus Sicherheitsgründen ist jedoch die maximale Anzahl der gleichzeitig aktiven Datenbankverbindungen beschränkt. Ist diese Zahl überschritten, dann kommt die "beliebte" Fehlermeldung. Wir könnten natürlich diesen Wert von der Administration des Providers erhöhen lassen. Allerdings würde das zu einer Erhöhung der allgemeinen Serverlast führen. Es würden weniger User die Fehlermeldung sehen, aber dafür würden die anderen Leute länger auf ihre Beiträge warten - und bei besonders hoher Last könnte die Datenbank komplett abschmieren und die Foren wären für eine halbe Stunde nicht mehr erreichbar. Diese Fehlermeldung hat also - um wieder die Analogie zur Autobahn zu bemühen - eine Ähnlichkeit mit der Blockabfertigung bei den Alpentunneln - wo bei hohem Verkehrsaufkommen die Autos vor der Einfahrt angehalten werden, um Staus im Tunnel zu vermeiden.

Aufgrund der Tatsache, dass sich die Überlast innerhalb weniger Sekunden auf dramatische Werte aufschaukeln kann, ist es auch erklärlich, dass es mitunter zu relativ ruhigen Zeiten zu Problemen kommen kann - nur steigt mit der Anzahl der aktiven User die Wahrscheinlichkeit, dass es klemmt. Aber es kann auch bei sehr grossem Besucheraufkommen flüssig laufen - nur ist das weniger wahrscheinlich. Auch dies ist ähnlich wie beim Straßenverkehr - wenn immer mehr Autos auf einer Straße fahren, dann kommt irgendwann der Punkt, wo der Verkehr zähfließend wird und wenn dann nicht der Zustrom an Fahrzeugen aufhört - kommt es zum Stau. Oder - dies ist ein Eisenbahnforum: Wenn eine Bahnstrecke so dicht belegt ist, dass in jedem Block ein Zug steht, dann geht erst mal gar nix mehr ...
Im Übrigen sollte man die Anzeige der gerade aktiven User nicht überbewerten. Ein User wird beim Aufruf der DSO-Startseite einmal erfasst und dann erst wieder, wenn er die Startseite neu lädt. Nach 10 Minuten wird dieser Wert verworfen. Wer also einmal DSO startet und dann immer irgendwo in den Foren aktiv ist, wird nur 10 Minuten lang mitgezählt. In der Praxis dürften bei DSO im Durchschnitt etwa 2 - 3mal so viele User aktiv sein, wie angezeigt. Dies bedeutet, dass nachts etwa 50 - 100 User online sind und tagsüber und Abends bis zu 2000 Personen.

Im zweiten Teil werde ich dann auf einige Vorurteile eingehen und kurz andeuten, was wir in allernächster Zeit als Lösung präsentieren werden.

Gruß

Alfons


Alfons Grünewald

danke für die Erklärungen und viel Erfolg!

geschrieben von: SchienenStoss

Datum: 16.04.07 21:29

beim "Umbau" der Hard- und Software. Ich bin sicher alles wird gut! Zumindest bis wieder die Userzahlen dramatisch ansteigen. Jedenfalls Danke an alle Admins und Moderatoren für die sehr gute Arbeit trotz der "Meckerei" einzelner.

_______________________________________
Ein Intelligenter kann sich dumm stellen, nur was macht ein Dummer?
Nur um mal ein Gefühl für die Auslastung des MySQL-Servers zu bekommen: wie viele Datenbankabfragen hat der denn pro Sekunde im Schnitt? Ich weiß, die Zahl ist nur bedingt aussagekräftig, aber würde ich aus privatem wie beruflichem Interesse (arbeite in einer Internetagentur und hab daher sowohl privat wie auch geschäftlich mit sowas zu tun) mal interessieren.

http://muenchnerubahn.de/bild/forenb.jpg
Hi,

bei mir ist es schon deutlich schneller geworden als zum Beispiel im Vergleich zu letztes Wochenende. Also egal, was ihr geändert habt, ihr seid auf dem richtigen Weg :-)

Viele Grüße
Michael
Michael1983 schrieb:
-------------------------------------------------------
> Hi,
>
> bei mir ist es schon deutlich schneller geworden
> als zum Beispiel im Vergleich zu letztes
> Wochenende. Also egal, was ihr geändert habt, ihr
> seid auf dem richtigen Weg :-)
>
> Viele Grüße
> Michael

Ist mir auch schon aufgefallen, gestern abend z.B. wurden 530 User angzeigt und es ging besser, als sonst immer, warum es besser ist, werden wir bestimmt bald erfahren!
Hallo admins,

danke für die Erläuterungen (gehöre auch zum Kreis der nicht-IT-Fachleute) und gutes Gelingen bei eueren Vorhaben.

Gruß
Rainer
Hallo an die Admins,
vielen Dank für die ausführlichen Erklärungen. Dem ist so; viele SQL-Abfragen gleichzeitig und dann auch noch über die komplette Datenbank können deren Tod bedeuten, zumindest zeitweise. Sicherlich wird Eure DB gespiegelt. Wie wäre es, Ihr könntet die SQL-Abfragen über den Spiegel laufen lassen. Das würde zumindest nicht den Master belasten und wenn dann noch der Server im Cluster (sicherlich) läuft auch noch die Prozesse auslagern. Die Suchdatenbank muss ja nicht sekundenaktuell sein.
...war nur mal so spontan angedacht.

Ich denke mal, dass Ihr auch eine gute Lösung für das Suchproblem findet. Bisher seit Ihr wenigstens immer auf dem richtigen Weg gewesen, Mißstände zu bereinigen.
ciao Detlef



1-mal bearbeitet. Zuletzt am 2007:04:17:17:06:28.

Also lieber fragen statt suchen!?

geschrieben von: ehemaliger Teilnehmer

Datum: 17.04.07 17:20

<<<Was dagegen immer länger dauert, je mehr Beiträge vorhanden sind, ist naturgemäß das Suchen nach bestimmten Begriffen. Dies führt unter bestimmten Umständen - welche gar nicht so selten sind - dazu, dass alle Beiträge von vorn bis hinten durchsucht werden müssen. Dies wiederum bremst natürlich den Server für eine gewisse Zeit. Deshalb kann manche umfangreiche Suche bis zu zwei Minuten dauern. Dies bedeutet natürlich NICHT, dass der Server in dieser Zeit nichts anderes mehr machen würde - aber alle anderen Aufgaben werden dann langsamer erledigt. Wenn gleichzeitig etliche User die Suchfunktion intensiv nutzen, dann dauern naturgemäß die ansonsten sehr schnellen Abrufe der Beiträge auch länger.>>>

Ist die Überschrift angesichts dieser Zeilen dann mit einem ! zu versehen?

Würde mich in Gedanken an einige Jünger der Suchfunktion, die sich bei der ersten doppelt gestellten Frage schon aufgrund ihrer nutzlos verplemperten Zeit ein wenig erregen, ja zu einem zarten Grinsen hinreißen lassen...

Mein Fazit: Lieber einmal mehr fragen, als durch Suchen den Server lahmlegen :-).
Kann man das so stehen lassen?

Es sei denn, alle wären so vernünftig und würden Geduld mitbringen. Aber wie Alfons weiter ausführt, ist das scheinbar nicht so sehr ausgeprägt... :-(

Schöne Grüße aus der Friedensstadt Osnabrück von

jörg blaschke

Na, da bin ich aber froh...

geschrieben von: ec paganini

Datum: 17.04.07 17:41

... , daß ich alles richtig gemacht habe. Wenn die "beliebte" Fehlermeldung kommt, verlasse ich DSO komplett und starte einen weiteren Versuch erst nach 15-30 Minuten.

Von dem ganzen IT-Kram verstehe ich nur ein wenig Bahnhof (nur ein ganz kleiner Nebenbahnendbahnhof).
So kann ich Euch nur ein glückliches Händchen und die nötige (Freizeit!) wünschen, daß es wieder besser läuft. Herzlichen Dank von meiner Seite für Euren Einsatz.

Re: Einige Worte zu Server, Geschwindigkeit usw. (Teil 1 - wieso es klemmt)

geschrieben von: ehemaliger Teilnehmer

Datum: 17.04.07 20:36

Also so ganz stimmt das aber nicht.

Das Protokoll HTTP ist sehr wohl ein verbindungsbehaftetes, d.h. wenn der Client das Socket schließt, werden keine Daten mehr geliefert.

Außerdem ist der Flaschenhals eindeutig die MySQL-Datenbank. Da aber die Daten weit verstreut liegen, lässt sich nicht einfach eine Rechnung aufstellen, wie viele Benutzer gleichzeitig zugreifen können.

Die produzierten Fehlermeldungen - übrigens aus Sicherheitsgründen durchaus bedenklich - zeigen, dass die maximale Anzahl an Verbindungen zum Datenbankserver überschritten wurden. Möglicherweise schließen nicht alle Verbindungen ordnungsgemäß.

Wie auch immer, daran, dass angeblich einige immer so oft klicken, kann es eigentlich nicht liegen.

Was auf jeden Fall sinnvoll wäre, wäre eine Verteilung der Anfragen an mehrere Server.* Ich kenne mich damit zwar nicht detailliert aus, aber möglich sein sollte das mit entsprechenden Programmen schon. Ob die Forensoftware so die optimale ist weiß ich auch nicht.

*Gemeint ist jeweils ein und das selbe Forum, nicht die Verteilung ganzer Foren auf unterschiedliche Server.
Hi!

Also wie ich sehe, machst du dir auch so deine Gedanken *g*. Mich persönlich interessiert viel mehr der kommende Teil 2 der Ausführungen von Alfons, da Teil 1 ja nicht wirklich unbedingt Neues enthielt, sondern Bekanntes noch einmal allgemein verständlich zusammenfasste.

Sicherlich sind die Hauptursachen im Zusammenhang mit der Datenbank zu suchen. Forensoftware: ich persönlich halte Phorum hier bei DSO als die beste Wahl der Software. Aus mehreren Gründen: die ständige Weiterentwicklung, die Baumstruktur(!!) (flache Ansicht können alle) und auch vom Preis als OpenSource.

Primäres Ziel eines rundlaufenden Forums sollte eine hohe Verfügbarkeit und Performance sein, also auch nur Zugriffe auf die Datenbank, wo nötig. Wenn man sich mal mit dem Sql-Layer von Phorum befasst, so sieht man, das die Entwickler schon auf Geschwindigkeit und saubere Programmierung achten.

Geschwindigkeit wird durch "Goodies" ausgebremst, die zusätzliche Last bzw. Datenbankzugriffe erzeugen. Drei Beispiele für Phorum:

- bei eingeschalten "Privaten Nachrichten" erfolgt bei jedem Zugriff eines Users auf einen Beitrag ein zusätzlicher Zugriff auf seine ID, um abzufragen, ob neue PN erhalten wurden. Wenn ja, wird oben in rot das bekannte "du hast neue PN" eingeschrieben.

- Klickzähler: für jeden gelesenen Beitrag wird per User in der Beitrags-ID der ViewCount um eins erhöht. Dazu braucht man also wieder einen schreibenden DB-Zugriff zusätzlich zum Lesezugriff des Beitrages selbst.

- Suche: Bei jeder Suche wird in der Datenbank eine temporäre zusätzliche Tabelle angelegt, die nach dem Ergebnisauswurf wieder gelöscht wird. Trotzdem wird erstmal wieder in der DB (zusätzlich) herumgeschrieben.

Alles solche Dinge die bremsen und auch von den Phorum-Entwicklern für hochbelastete Foren nicht empfohlen werden. Für mich wäre hier hier der erste Ansatz der Performanceschraube. Wenn man auf verschiedene Server, wie von dir geschrieben, verteien wollte, bräuchts vielleicht auch noch einen Load-Balancer oder irgendsowas.

Wie gesagt, meine Meinung, bin gespannt auf Teil 2 vom Alfons.

Gruß
Daniel



1-mal bearbeitet. Zuletzt am 2007:04:17:23:49:32.
Das legendäre Interview! Er wollte uns das damals nur (so wie jetzt Alfons) allgemein verständlich erklären... ;-)))


Na, da bin ich ja mal gespannt! Täusche ich mich, oder hat sich die Situation seit dem Wochenende bereits gebessert? Ich habe hin und wieder auch noch Wartezeiten, aber die sind nicht mehr so eklatant, wie noch in der letzten Woche.


Bis neulich

Rolf Köstner

https://abload.de/img/vflosnabrckyjjog.jpg ...... 2. Bundesliga, wir kommen! Ach ja: wo kann ich eigentlich Karten für die Spiele VFL Osnabrück gegen Hannover 96 für die Saison 2019/2020 bekmmen?


2. Server

geschrieben von: Der Zeuge Desiros

Datum: 18.04.07 12:13

"Wenn man auf verschiedene Server, wie von dir geschrieben, verteien wollte, bräuchts vielleicht auch noch einen Load-Balancer oder irgendsowas."

Ja,

technisch wäre das o.k. Aber genau das "irgendsowas" könnte schnell zum Casus Knaxus werden: es nennt sich im Klartext "Geld" und ist selbst in den Kassen unser guten alten DREHSCHEIBE nur endlich vorhanden - leider.

Gruß

Heiko
Hallo,

Zitat:
Täusche ich mich, oder hat sich die Situation seit dem Wochenende bereits gebessert? Ich habe hin und wieder auch noch Wartezeiten, aber die sind nicht mehr so eklatant, wie noch in der letzten Woche.

Vielleicht sind es auch nur die Ferien, die in vielen Bundesländern aufgehört haben??

MfG klippekort
FloSch schrieb:
-------------------------------------------------------
> Nur um mal ein Gefühl für die Auslastung des
> MySQL-Servers zu bekommen: wie viele
> Datenbankabfragen hat der denn pro Sekunde im
> Schnitt? Ich weiß, die Zahl ist nur bedingt
> aussagekräftig, aber würde ich aus privatem wie
> beruflichem Interesse (arbeite in einer
> Internetagentur und hab daher sowohl privat wie
> auch geschäftlich mit sowas zu tun) mal
> interessieren.


Hallo,

ich habe im Teil 2 etwas zur Anzahl der Abfragen je Seitenabruf geschrieben - Du kannst davon ausdgehen, dass in Spitzenzeiten bis zu 200 Abfragen je Sekunde ausgeführt werden.

Gruß

Alfons


Alfons Grünewald

Detlef Klein schrieb:
-------------------------------------------------------
> Hallo an die Admins,
> vielen Dank für die ausführlichen Erklärungen. Dem
> ist so; viele SQL-Abfragen gleichzeitig und dann
> auch noch über die komplette Datenbank können
> deren Tod bedeuten, zumindest zeitweise.
> Sicherlich wird Eure DB gespiegelt. Wie wäre es,
> Ihr könntet die SQL-Abfragen über den Spiegel
> laufen lassen. Das würde zumindest nicht den
> Master belasten und wenn dann noch der Server im
> Cluster (sicherlich) läuft auch noch die Prozesse
> auslagern. Die Suchdatenbank muss ja nicht
> sekundenaktuell sein.
> ...war nur mal so spontan angedacht.
>
> Ich denke mal, dass Ihr auch eine gute Lösung für
> das Suchproblem findet. Bisher seit Ihr wenigstens
> immer auf dem richtigen Weg gewesen, Mißstände zu
> bereinigen.
> ciao Detlef

Hallo Detlef,

eine echte Spiegelung ist sehr aufwendig, da in einem Forum sehr viele Schreibzugriffe stattfinden. Eine klasische Replikation, bei der die Daten von einer Master-Datenbank in bestimmten Abständen auf die Slave-Datenbank geschrieben werden, ist aber nur bei Daten geeignet, welche sich nur selten ändern.

Gruß

Alfons


Alfons Grünewald

Re: @Bunsenbrenner

geschrieben von: Alfons Grünewald

Datum: 19.04.07 20:08

Die Benutzerdaten werden immer abgefragt, auch wenn keine PNs eingeschaltet sind. Die PN selbst belastet das System fast gar nicht.

Der Klickzähler erzeugt einen Schreibzugriff, der allerdings recht schnell ist. Der Beitrag wird über seinen Primärindex aufgerufen und ein Update-Befehl ausgeführt.

Die Suche ist für ein Forum unverzichtbar - allerdings habe ich aus gegebenem Anlass die Suche für nicht eingeloggte Nutzer ausgeschaltet. Dies haben nämlich einige Leute benutzt, um DSO vorsätzlich auszubremsen :-(.
Die Suche ist im Gegensatz zu Phorum 3 wesentlich effizienter geworden, da sie überall, wo es möglich ist, den Volltextindex von MySQL nutzt. Bei den sehr häufig gesuchten Loknummern nützt dieser allerdings nichts und es muss ein Full Table Scan durchgeführt werden.

Gruß

Alfons


Alfons Grünewald

Re: @Bunsenbrenner

geschrieben von: bunsenbrenner

Datum: 19.04.07 21:09

Hallo Alfons,

schön dass du auf einige Äußerungen der User eingehst.

Ich habe eigentlich nur einige Gedanken aufgeschrieben - nach dem "RTFM" of Phorum ;-). Das die Suche unverzichtbar ist, steht für mich außer Frage, für mich war nur der Aspekt neu, dass dabei temporäre Tabellen geschrieben werden, was ja nicht jede Forensoftware macht.

Für mich persönlich hat der Klickzähler keinen Informationsgehalt, der Inhalt der Beiträge zählt für mich mehr als die Anzahl der Aufrufe. Von daher wäre es für mich ein Feature, auf das ich sofort verzichten könnte, auch aus anderen Gründen, die ich schon verschiedentlich geäussert habe.

Man kann im Development von Phorum nachlesen, das immer mehr Caching-Funktionen in die Software implementiert werden. Die relativ neue Funktion des Cachings der Userdaten scheint mir ein sehr guter Weg, um Lesezugriffe von der Platte zu sparen (mir ist schon der Zusammenhang bewusst, dass das auch RAM braucht..).

Wenn ich nun 1 und 1 zusammenzähle, so kommen als künftige Massnahmen euererseits also die (geschehene) Abschaltung der Suche für unreg's und eine teilweise Auslagerung alter Beiträge als zeitnah umsetzbare Arbeiten in die vorrangige Wahl. Bin gespannt. ;-)

Gruß
Daniel



1-mal bearbeitet. Zuletzt am 2007:04:19:21:18:25.
Alfons Grünewald schrieb:
-------------------------------------------------------
> ich habe im Teil 2 etwas zur Anzahl der Abfragen
> je Seitenabruf geschrieben - Du kannst davon
> ausdgehen, dass in Spitzenzeiten bis zu 200
> Abfragen je Sekunde ausgeführt werden.

Danke für die Zahl!

http://muenchnerubahn.de/bild/forenb.jpg

Seiten: 1 2 3 4 5 6 All

Angemeldet: -