Selfhtml Suche

[JCB]

Schön guten Tag :o)!

Ich möcht doch erst noch mal n großes Lob für SelfHTML aussprechen, bevor ich anfang zu "meckern" ;). Ich find SelfHTML ist einer der besten (wenn nicht sogar _DIE_ beste) Online-Doku. bzw. Referenz für HTML, JS etc.!!! Es ist für mich die 1. Anlaufstelle, wenn es um diese Themen geht. Nur, ich finde eine "Macke" hat SelfHTML auch. Nämlich die Suche. Nicht das Script ansich, sondern vielmehr die Tatsache, dass der Server sehr oft überlastet ist. Man will nur kurz nach etwas suchen und was ist. Server ausgelastet. Woran liegt das? Können da nur max. 10 User gleichzeitig etwas suchen?? Ich denke da könnte man noch was machen. Denn bei anderen Sites gehts ja auch. So, das ist meine Meinung. Nu dürfter dran rummeckern ;o).

Schönen Gruß, Jan

[Andreas Korthaus]

Hi!

Ich möcht doch erst noch mal n großes Lob für SelfHTML aussprechen, bevor ich anfang zu "meckern" ;). Ich find SelfHTML ist einer der besten (wenn nicht sogar _DIE_ beste) Online-Doku. bzw. Referenz für HTML, JS etc.!!! Es ist für mich die 1. Anlaufstelle, wenn es um diese Themen geht. Nur, ich finde eine "Macke" hat SelfHTML auch. Nämlich die Suche. Nicht das Script ansich, sondern vielmehr die Tatsache, dass der Server sehr oft überlastet ist. Man will nur kurz nach etwas suchen und was ist. Server ausgelastet. Woran liegt das? Können da nur max. 10 User gleichzeitig etwas suchen?? Ich denke da könnte man noch was machen. Denn bei anderen Sites gehts ja auch. So, das ist meine Meinung. Nu dürfter dran rummeckern ;o).

Da hast Du Recht, das ist wirklich sehr nervig. Hat vermutlich 2 Ursachen:
1. für die Größe des "projektes" einen verhältnismäßig "kleinen" Server
2. die Art der Suche, es wird jedesmal über 100MB an Textfiles durchsucht. Das ist vermutlich deutlich recourcenverschwendender und langsamer als eine Datenbank, die dafür optimiert wurde!

Aber es ist wird schon seit längerem an einer MySQL-Datenbank für die Suche gebastelt, ich weiß nicht wo genau das Problem liegt, aber es müssen schließlich alle Daten vernünftig strukuriert hier rein geschrieben werden, also schon ein größerer Akt, vermutlich noch größer als ich es mir jetzt vorstelle. Daher hilft wohl nur warten bis es denn man fertig ist. Aber vielleicht hilft der Thread ja das der ein oder andere sich wieder daran erinnert ;-)

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

1. für die Größe des "projektes" einen
   verhältnismäßig "kleinen" Server

naja, inzwischen geht es einigermaßen. Das war früher mal viel schlimmer.

2. die Art der Suche, es wird jedesmal über 100MB
   an Textfiles durchsucht.

Nur dann, wenn jedesmal das komplette Archiv durchsucht wird. Das muß aber nicht sein! Warum, glaubst Du, habe ich das Archiv in einzelne Indexdateien zerlegt, die im Such-Formular separat auswählbar sind?
(Hm, man könnte mal darüber nachdenken, das Jahr 2002 in zwei Teile zu schneiden ...)

Das ist vermutlich deutlich recourcenverschwendender
und langsamer als eine Datenbank, die dafür optimiert
wurde!

Richtig. Aber für die Aufgabenstellung, welche von der Self-Suche _derzeit_ erfüllt wird, eine Datenbank zu optimieren, das ist keine einfache Angelegenheit.

Aber es ist wird schon seit längerem an einer
MySQL-Datenbank für die Suche gebastelt, ich weiß
nicht wo genau das Problem liegt, aber es müssen
schließlich alle Daten vernünftig strukuriert hier
rein geschrieben werden, also schon ein größerer
Akt, vermutlich noch größer als ich es mir jetzt
vorstelle.

Definiere "suchen" - das ist das Problem.

Eine Such-Funktion, die lediglich Worte einer bestimmten Mindestlänge (sagen wir mal: 4 Zeichen) finden kann, liefert mySQL bereits fertig mit (FULLTEXT-Index).
Aber die ist nicht verwendbar, um all das nachzubauen, was die bisherige Suche kann.

Die kann nämlich
1.) reguläre Ausdrücke in Suchbegriffen und
2.) Phrasensuche,
also eben gerade _nicht_ beschränkt auf Worte arbeiten.

Eine Datenbank, die alle Worte eines Postings in einem entsprechend sortieren Indexbaum ablegt, findet natürlich Postings aufgrund von Worten sehr schnell.
Du könntest damit nach "Internet" + "Explorer" suchen - Du würdest allerdings auch alle Dokumente finden, die diese beiden Worte ohne jeden Zusammenhang enthalten.
Nach der Phrase "Internet Explorer" könntest Du damit jedoch nicht suchen - weil 'Phrase' kein von dieser Suche unterstütztes Konzept wäre.
Wenn Du aber den gesamten Inhalt aller Postings durchsuchen mußt, um Phrasen zu finden, was nützt Dir dann noch eine Datenbank? Da ist die bisherige reine Perl-Implementierung sicherlich schneller.

Es gibt ein Gedankenmodell, welches darauf beruht, die Suche nach einer Phase wie "Internet Explorer" abzubilden durch
a) eine Suche nach Internet AND Explorer (beides ist mit einem Wort-Index realisierbar) _und_
b) einer nachgeschalteten Volltextsuche durch sämtliche in Schritt a) gefundenen Treffer (in der Hoffnung, daß das dann signifikant weniger als alle sind).
Das _ist_ sehr schnell - ich selbst setze ein solches System (unter Verwendung von mySQL-FULLTEXT) beruflich ein und kann die Idee daher nur unterstützen.

Es sind allerdings noch ein paar zusätzliche Verfeinerungen notwendig - beispielsweise eignet sich "Internet" nicht gerade toll als Suchbegriff, weil es viele tausend Treffer produzieren würde.
Man bräuchte also eine Art "Bewertungsfunktion" für die eingegebenen Suchbegriffe, um erkennen zu können, daß etwa bei einer Suche nach "Internet hype" die beste Strategie _nicht_ darin besteht, nach "Internet" AND "hype" zu suchen, sondern einfach nur nach "hype" und _dann_ den Volltextfilter dahinter zu schalten.
Das ist eine Erfahrungssache und erfordert ausgiebige Analysen des Inhalts (ich habe alleine dafür mehrere Programme geschrieben und mich eine ganze Weile damit beschäftigt, eine Stopwortliste für diesen Zweck zu bauen - und was tun, wenn _alle_ Worte der Phrase auf dieser Stopwortliste stehen? "Internet Explorer" wäre ein guter Kandidat dafür).

Auch ist die mySQL-spezifische Einschränkung auf eine Mindestlänge von 4 Zeichen pro Wort ein Problem. Da findet man schon mal nicht mehr "WWW" oder die gängigen Kürzel wie MS, NS, JS usw.
Man _kann_ den C-Quelltext von mySQL so anpassen, daß diese Einschränkung wegfällt (die Mindestlänge steht dort als Konstante drin). Hier in der Firma habe ich das gemacht, mySQL neu übersetzt und alle Indexe neu gebaut (die werden dann natürlich größer, aber nicht erheblich) - und es funktioniert prima. Mit einem mySQL in der Standardauslieferung geht so etwas natürlich nicht.

Der Punkt dabei ist allerdings letzten Endes nicht, daß eine neue Suche unbedingt den kompletten Funktionsumfang der bisherigen Suche abdecken muß. Es wäre aber schön, wenn sie es täte. Leider ist eine solche "Entscheidungslage" (nämlich eben _keine_ Aufgabenstellung, sondern ein "mach mal" ...) völlig unbrauchbar für den Beginn einer Implementierung.
Man _könnte_ sehr wohl ein Konzept aufstellen, welches darin bestünde, _neben_ der bisherigen Volltextsuche eine wortbasierte Suche anzubieten und die mächtigere Suche quasi als "Experten-Modus" darin nur zu verlinken. Mit einem gepatchten mySQL wäre diese Wort-Suche relativ schnell implementierbar.
Was in meinen Augen fehlt, das ist also eher ein ganzheitliches Betriebskonzept, welches sich dann auch mit der Usability dieser beiden Suchfunktionen und ihrer Einbindung in das gesamte Self-Portal befassen müßte ... nicht so sehr irgendwelche programmiertechnischen Skills im Detail.

Und außerdem ist natürlich zu bedenken, daß Daniela die Reimplementierung der Suche in ihrer Freizeit macht - und wieviel oder wie wenig sie davon zu opfern bereit ist, vermag ich nicht zu beurteilen.
Meine Nachrichtensuche, die auf dem oben beschriebenen Prinzip des nachgeschalteten Volltextfilters basiert, hat knapp _ein_Jahr_ Entwicklung vom ersten Entwurf bis zum produktiven Einsatz (der vor drei Wochen war) erlebt ... der Funktionsumfang ist natürlich nicht exakt vergleichbar (meine Lösung muß sich mit etlichen zusätzlichen Problemen herumschlagen, beispielsweise Authentifizierung, Entitlement und Accounting), aber ein paar Monate full-time-Entwicklung und Test kann man für ein derartig ausgereiftes System durchaus veranschlagen, wenn man sich das erste Mal an so etwas heran wagt.

Viele Grüße
      Michael

[Orlando]

Hi,

[...] Nur, ich finde eine "Macke" hat SelfHTML auch. Nämlich die Suche. Nicht das Script ansich, sondern vielmehr die Tatsache, dass der Server sehr oft überlastet ist. Man will nur kurz nach etwas suchen und was ist. Server ausgelastet. Woran liegt das? Können da nur max. 10 User gleichzeitig etwas suchen?? Ich denke da könnte man noch was machen. Denn bei anderen Sites gehts ja auch. So, das ist meine Meinung. Nu dürfter dran rummeckern ;o).

Zitat http://selfsuche.teamone.de/:

"Michael Schröpl betreut das Script der SELFHTML-Suche. Fragen
   zu diesem Script bitte an ihn richten."

Wir können aber auch hier auf ihn warten...

LG Orlando

[Michael Schröpl]

Hi Orlando,

[...] Nur, ich finde eine "Macke" hat SelfHTML
auch. Nämlich die Suche.
Nicht das Script ansich, sondern vielmehr die
Tatsache, dass der Server sehr oft überlastet ist.

tja, wenn der Server aufgrund seiner prominenten Stellung nun mal das Ziel von DOS-Angriffen etc. geworden ist, dann schränkt das seine Verfügbarkeit eben ein. Und da die Suche mehr CPU-Last auf den Server bringt als ein statischer Seitenzugriff, haben sich die Angreifer anscheinend die Suchmaschine als "Opfer" ausgesucht.

Demzufolge hat Christian Kruse in die Suche eine Lastbremse eingebaut, die auf der Anzahl parallel laufender Such-Operationen basiert.
Ob die konkrete Grenze im normalen Betrieb so glücklich gewählt ist, vermag ich mangels Auslastungsdaten des Servers nicht zu beurteilen - aber ohne diese Lastbremse wäre auf dem Server zwischendurch mal weit mehr nicht verfügbar als nur die Suche (nämlich alle Subdomains, also insbesondere das Forum und SelfHTML und der TeamOne-Firmenauftritt und ...) - das wäre sicherlich weitaus schlimmer.

Man will nur kurz nach etwas suchen und was ist.
Server ausgelastet. Woran liegt das?

Tja, bedanke Dich bei den bösen Angreifern.

Können da nur max. 10 User gleichzeitig etwas
suchen??

Wenn sich alle wohlverhalten würden, dann könnten durchaus mehr als 10 Benutzer gleichzeitig etwas suchen.

Das hängt allerdings auch mit einer sinnvollen Benutzung der Suche zusammen. Wähle die zu durchsuchenden Indexdateien mit Bedacht - es muß nicht immer das Archiv dabei sein. Oftmals ist eine Suche nur in SelfHTML und den Feature-Artikeln die bessere Idee - dort ist vor allem auch die Qualität der Treffer viel höher, und gleichzeitig dauert die Suche nur einen Bruchteil der Zeit (und blockiert entsprechend kürzer das "Potential" des Servers).

Ich denke da könnte man noch was machen.
Denn bei anderen Sites gehts ja auch.

Je populärer der Server, um so mehr Feinde hat er auch und muß sich diesem Thema stellen.

So, das ist meine Meinung. Nu dürfter dran
rummeckern ;o).

Es gibt nichts zu meckern.
Das Problem ist nicht ein Problem der Suchmaschine, sondern ein Problem der Besucher.

Zur Problematik der Indexdateien sage ich im anderen Teilbaum noch etwas.

Viele Grüße
      Michael