Drum and Bass? :headbanging: :headbanging: :headbanging:

'cuda

Dachte immer DB steht für was anderes... :lolol:

Recht er hat ;)

Bevor nun aber solch techniklastigen und themenfremden Diskussion hier ständig auf Platz eins der Forumsreihenfolge stehen, bitte ich doch darum, daß wir den 8er-lastigeren Themen den Vortritt lassen und dieses hier nun einschlafen lassen ;)

Um das ganze noch ein wenig zu verkomplizieren:

RDBMS müsste meiner Schätzung nach Relationales Datenbank Management System heißen.

Hoffe dass damit doch jetzt alles klar sein müsste.


Martin

wieso weiß ich jetzt nicht mehr als vorher??
Ich gebs auf!! Ich hab ja meine Experten!!

RDBMS: Relationales Datenbank Management System.
DB: Datenbank.
MyISAM: Tabellentyp einer MySQL-Datenbank. Kann keine Transaktionen und keine referenzielle Integrität
InnoDB: ein anderer Tabellentyp der MySQL-DB.
Oracle: Eine der beiden weltweitgrössten RDBMS (zweite ist DB2).

Noch was vergessen?

'cuda

Bei mir geht immer alles schnell!!
Ich hab ja auch den richtigen Admin bei mir zu hause
Gruß Rainer
PS: ne liste eurer Abkürzungen wäre nicht schlecht!!
will ja nicht Dumm sterben

Solange du nicht länger als sagen wir mal 2 Sekunden dafür brauchst, ist alles okay ;)

Ich verstehe nur!!! BAHNHOF BAHNHOF

Ja, MySQL ist eine sehr schnelle und schlanke DB, die (vorsichtig ausgedrückt) nicht viel kann. Wenn es nur um's Datenspeichern geht, reicht sie völlig aus. Ich würde auch nicht auf die Idee kommen, eine Oracle DB für einen Forum aufzusetzen. Will man allerdings 100%ige Sicherheit, Skalierbarkeit, und etc. kommt man an den "Grossen" nicht vorbei. Bei einem Kunden haben wir schon mit nur zwei Einstellungen einen gewaltigen Performanceschub herausholen können.

'cuda

95% ACK, Heinrich. MySQL ist an sich ne Kindergarten-Datenbank, ein besseres Karteikartensystem, allerdings hat sie, wenn MyISAM und g'scheit strukturiert, einen Geschwindigkeitsvorteil gegenüber so ziemlich allem auf dem Markt, auch gegenüber Oracle. MySQL ist durchaus tunebar, wenn auch viele, viele, viele Stufen unter "echten" Datenbanken. Ich hab schon mehrmals MySQL im Einsatz gehabt, wo Messwerte gesammelt wurden und die Datenbank sehr schnell auch mal einige hundert GBs gesammelt hat und trotzdem noch schneller war als die Konkurrenz. DAFÜR ist MySQL optimal. Das Problem ist, wenn man von der MyISAM abkehrt und denkt, für ein Forum wäre Transaktionssicherheit wichtig. Dabei geht MySQL dir schneller in die Knie als Paris Hilton, da hilft leider auch CPU und Speicher nicht (obwohl mans denken mag), da das Problem in dem Kern selbst liegt.

Die "Problemchen" oder nennen wirs konzeptionelle Wunschträume der Entwickler sind aber ausgemerzt, an sich sehe ich im Moment seitens DB und Frontend keinen driftigen Grund, warum der Seitenaufbau manchmal langsam ist, manchmal nicht. Die Benchmarkzeiten geben das auch nicht her, erst recht keine 11 Sekunden. Ich vermute was ganze anderes. Ich fleuche mit 1 mbit durchs Netz, und bei mir ist das Forum (bis eben aufs Posten, was ich hoffentlich heute oder morgen behebe) absolut responsive. Der Rechner, auf dem ich die Probleme wie Reinhard hatte, steht aber auch grad nicht vor mir ;) Ich hab was im Aug, mal sehen, ob ichs raus bekomme (pun intended)

Die Main-Seite zu öffnen hat ca. 2sec gedauert, Deutschland, Schweiz, Österreich öffnen hat ca. 2 sec gedauert, dieses Thema öffnen etwa 11 sec.
Manche Bereiche sind schnell, und zwar immer (Forenübersicht) andere hängen derart, daß sie teilweise nicht öffnen. Soll keine Kritik sein, sondern ein Hinweis, der vielleicht schneller zu einer Lösung führt.

BTW möchte ich sagen, daß niemand auf die Idee kommen sollte irgend einen Berich auszudünnen (Platz zu schaffen), denn das Forum lebt von seinem hohen Informationsgehalt.


Klaus

Tuo, Du hast gesagt "die gesamte db kommt auf ganz andere zahlen". Daraufhin habe ich gemeint, dass die DBs von mehreren Hundert GB für mich nichts Neues oder Besonderes sind.

Ich evaluire keine DB auf Grund von quantitativen Angaben. Nur MySQL hat garantiert weniger Einstellungen, die sich auf die Perfomance auswirken, wie z.B. Oracle oder DB2. Nur die MySQL-Engine ist bei weitem nicht so mächtig, eben schlank und schnell. Wird Datenvolumen grösser, gute Nacht Performance. Fett Speicher und schnelle CPU (uns zwar in genau dieser Reihenfolge) ist für jedes RDBM-System vorteilhaft.

'cuda

ich hab zwar nicht die geringste ahnung, was das mit oracle zu tun hat, aber nun gut.

ich weiß nicht, wie du darauf kommst dbms rein aufgrund quantitativer angaben ohne kenntniss des frontends resp. der struktur zu evaluieren aber nun gut.

meine aussage bzgl. der anzahl der recs bezog sich einzig und alleine darauf, daß der i/o load der search-words tabelle rein gar nichts mit dem forum an sich zu tun hat, da sich die zahlen (und nicht zuletzt alleine schon die tabellen-engine) hier vollkommen unterscheiden. davon abgesehen (und daher von mir mit den worten zweifelhaft gebrandmarkt) findet das indexing auf pgrep basis statt und somit weit entfernt eines jeden dmbs....bei hohem drystone und ausreichend ram inkl. bandbreite zw. selbigen und cpu positiv zu bewerten, aber auch nur solange, bis genau dieser vorteil ins gegenteil kippt, was hier der fall ist.

aber ich denke ich verziehe mich jetzt einfach mal mit den worten: ich kümmer mich drum, bevor ich jeden meiner sätze nochmals ausführlich dastellen muss.

Lieber Tuo,

ich bin Oracle-Admin und deswegen sind für mich die DB-Grössen von mehreren Hundert GB nichts besonderes.

Das mit dem DNS ist es doch so, dass die IPs gecached werden. Also wenn ein Problem mit dem DNS bestehen würde, wäre es "nur" beim ersten Auflösen, dann ist die IP ja "gespeichert". Leider wird DNS-Cache immer wieder geleert.

Was Du machen kannst, ist so ein Tool zum Analysieren vom Traffic nehmen. Ich weiss jetzt nicht wie so ein Ding heisst, aber da kannst Du alle Latenzen sehen und wielange es dauert.

'cuda

1.6 millionen recs in der searchwords-tabelle...die gesamte db kommt auf ganz andere zahlen ;) aber vom gefühl her nix, was der server nicht wegstecken könnte.

ich hatte am anfang auch probleme und hab daraufhin optimiert, und hab seither mit 1mbit TDSL auf zwei standorten seitenaufbau von 1 bis 2 sekunden, also wirklich okay. die postingprobleme haben ja damit nix zu tun.

wie heinrich bereits sagte, fastpath bringt dir nahezu nüscht. die DNS thematik ist zwar relevant, aber je nach TCP-Stack resp. Browser nicht des Übels Wurzel da doch jeder vernünftige Stack da ein DNS-Caching vornehmen sollte. Ich betrachte seit einiger Zeit die Seitenaufbau/Bufferdispatch-Zeiten und das witzige ist, daß diese wirklich für alle Benutzer im großen und ganzen gleich sind (und auch vergleichswiese gering sprich sich darin die großen verzögerungen die berichtet werden nicht ablesen lassen), also auch das (von mir am anfang vermutete) AJAX keine rolle spielt. Die Probleme scheinen weder serverseitig noch forensoftwareseitig zu liegen, ich tippe im moment auf was ganz anderes, was ich mal mit reinhard als "dummy" durchtesten werde...

@Rudi: Für den Seitenaufbau ist FastPath eher irrelevant. Dann eher die DB, wobei 1,6 Mio Zeilen sollte eigentlich jede DB aushalten.

'cuda

Denke mal ander Leitung liegts nicht hab ne 6000er und sogar noch Fastpath bin ein alter Zocker hehe. Mir kommts so vor als ob die DB Anbindung manchmal hackt. Auf was für einem Gerät läuft den die HP?

Wen sich Seiten sehr langsam, garnicht oder erst nach öfterem klicken öffnen kann das auch an schlecht verfügbaren DNS-Servern liegen. Normaler weise bekommt man automatisch einen von seinem Provider zugewiesen und man braucht nichts ein zustellen. Wenn Probleme auftreten sollte man einfach mal manuell einen in den Netzwerkeinstellungen angeben und dann mal Testen. Aktuelle Listen bekommt man hier DNS-Server Liste .
Eine gute Erkärung für ungeübte gibts hier DNS howto

Letzteres Problem ist dann aber weniger Forenbedingt als darauf zurückzuführen, daß deine Session abgelaufen ist. Die Session-Zeit hat sich eigentlich im Vergleich zur vorherigen Version des Forums nicht geändert. Äußert sich in der Regel darin, daß man - nach längerer "Standzeit" um mal im Kraftfahrzeugjargon zu bleiben - einen Post schreiben will, der Server einen aber schon längst "vergessen" hat und beim abschicken dies schmerzlich deutlich wird. Abhilfe dagegen sollte das Auto-Login schaffen, welches nen Cookie auf deinem Rechner setzt, über den der Server dich wieder einloggen kann, ohne, daß du was davon mitbekommst.

die Geschwindigkeit hat sich bei mir auch verlangsamt,
auch passiert es mir öfter, das ich, nachdem ich einen
Beitrag geschrieben hab und diesen übermitteln möchte,
rausflieg und mich neu einloggen soll.
Danach muss ich alles neu schreiben, puuh.

Gruß Ronny

Die Geschwindigkeitsprobleme beim Posten von längeren Beiträgen hängen mit einem wie ich finde etwas unglücklichen Datenbankcaching zusammen. Alle jemals eingegebenen Suchbegriffe werden in der Datenbank gespeichert, bei einem neuen Post wird der komplette Post nach den gängigen Suchbegriffen gegrep'ed und indiziert. Inzwischen ist die Liste an Suchbegriffen auf knapp 1.6 millionen Einträgen angewachsen, was selbst für modernere Pattern-Matchingalgorithmen ein Brocken ist, erst recht bei längeren Posts.

Ich werde in den kommenden Tagen die gespeicherten Suchbegriffe mal optimieren, um sie wieder auf ein erträgliches Maß zu bringen, und sämtliche Posts über Nacht neu indizieren lassen.

Was den Seitenaufbau angeht war ich ja bereits mit Reinhard im Dialog. Die bekannten Probleme sind soweit beseitigt, das zumindest bei mir zuhause (ebenfalls 1mbit) eigentlich wieder alles in Lot war (und laut aussage auch bei reinhard für einige zeit), aber seit neuerem scheinen einige mit schmalerer Bandbreite wieder Probleme zu haben, die ich allerdings noch nicht bestätigen kann. Aber auch da werde ich nochmals nachschauen.

Dem kann ich nur beipflichten. 1-2 Sekunden sowohl im Buero (32mbit) als auch zu Hause (3 mbit).

'cuda

Manchmal öffnet eine Seite nur auf den zweiten Klick
Wenn sie sich öffnet, dann aber ohne Zeitverzug.

Dies geschieht unabhängig davon vor welchem Rechner ich sitze.


Micha

Bei mir laden die Seiten innerhalb 2 Sekunden :