Wie andere auch, bin ich diesen Weg gegangen:
- Beginne mit einer Liste, vielleicht heruntergeladen aus einem aktuellen GitHub-Repo.
- Stoße sofort auf das 2000-Einträge-Limit.
- Oh, ich kann Regex verwenden – super!
- Komplexe Regexps überschreiten leicht 100 Zeichen.
- Teile sie auf.
- Verfeinere eine Regex, oh, sie ist auch über 100 Zeichen lang geworden.
- Teile sie noch weiter auf.
Das Tanzen mit Limits ist nicht hinderlich, es ist einfach nervig, besonders wenn die Limits künstlich sind. Dennoch verstehe ich, dass diese Filterung synchron ist und dass erweiterte Verarbeitung Leistungsprobleme verursachen kann, und ich schätze die Schwierigkeit, Limits festzulegen, die für die größtmögliche Zielgruppe funktionieren. Auch wenn ich mit den Limits kämpfe, kann ich ihnen vernünftigerweise nicht widersprechen.
Ich sehe den Code für die Filterung hier in word_watcher.rb. Als Entwickler würde ich gerne versuchen, ein Plugin zu schreiben, aber dieser Code sieht nicht erweiterbar aus. Ich hätte keine Ahnung, wie man JavaScript in einem Plugin einhakt, um die Ruby-Prozesse zu erweitern … oder ob das mit der Art und Weise, wie der word_watcher-Code geschrieben ist, möglich ist.
Hier ist eine Idee für eine Verbesserung, um die Last der Verarbeitung umfangreicher Listen zu verringern.
Anstatt die gesamte Liste für jeden Typ von Watchlist zu verarbeiten, ziehen Sie eine Schleife durch verschiedene Blöcke von Filtern in Betracht. Zum Beispiel können wir die häufigsten und missbräuchlichsten Filter in Block1 und andere in Blocks2-n legen. Der synchrone Filterprozess verarbeitet nur einen Block nach dem anderen und führt nur eine vollständige Schleife durch alle Filter beim endgültigen Speichern durch. Blöcke können auf vorhandenen Listen operieren, sodass niemand eine Änderung vornehmen muss. Vorhandene Listen werden in Blöcke von 1000 Einträgen aufgeteilt, sodass Block1 1-1000, Block2 1001-2000 usw. sind. Administratoren, die optimieren möchten, können nun wählen, ihre Filter mit höherer Priorität weiter nach oben in der Liste zu verschieben.
Ein Vorteil davon ist, dass nicht die gesamte Liste verarbeitet werden muss, um ein Problem zu erkennen. Die wahrscheinlichsten Probleme werden mit einem kleineren Block erkannt und der synchrone Prozess kann früher aus der Verarbeitung des kleineren Blocks zurückkehren. Sicher, wenn der zu überwachende Text nicht im ersten Block gefunden wird, muss ein anderer Block verarbeitet werden. Das ist ein geringfügig höherer Aufwand, um weniger wahrscheinlichen Missbrauch zu erkennen. Dies wird zu einer optionalen Abstimmung – wenn sich jemand dafür interessiert.
Eine zusätzliche Option wäre, dass der Administrator wählt, wie groß die Blöcke sind. Durch die Verringerung der Blockgröße, vielleicht auf 500 Einträge pro Schleifendurchlauf, wird jeder synchrone Prozess schneller, aber es können mehr Blöcke zu verarbeiten sein. Dies hängt von der Art des Missbrauchs ab und davon, wie gut die Liste priorisiert ist. Auch diese Art der Abstimmung wäre optional, und ehrlich gesagt bezweifle ich, dass viele Administratoren so viel abstimmen würden.
Beachten Sie, dass Feinabstimmung impliziert, dass wir quantifizierbare Metriken haben: Wie viel Zeit verbringen wir mit der Verarbeitung von Watch-Wörtern und wie viele Probleme fangen wir tatsächlich ab? Diese nerdige Detailtiefe sollte einer späteren Verbesserung oder einem Plugin überlassen werden, wenn sie wirklich wünschenswert ist.
Letztendlich, wenn die “Watch-Word-Block-Verarbeitung” wie hier beschrieben implementiert wird, kann die Anzahl der Elemente in der Liste über 2000 hinaus erweitert werden. Ja, es wird einen gewissen Mehraufwand beim Lesen längerer Listen und deren Aufteilung geben. Auch hier gilt: Wenn wir Metriken darüber haben, wie viel Zeit dieser Prozess in Anspruch nimmt, können Administratoren ihre eigenen Schwellenwerte für die Optimierung festlegen … aber ich bezweifle, dass viele Leute sich damit tiefgehend beschäftigen würden. Die veröffentlichte Richtlinie könnte lauten: “Das Limit bleibt 2000 Watch-Wörter ohne Watch-Word-Block-Verarbeitung. Mit Block-Verarbeitung gibt es kein spezifisches Limit, aber das praktische Limit könnte auf etwa 5000 geschätzt werden, wobei die Leistung mit zunehmender Anzahl von Einträgen merklich abnimmt.”
Gibt es hier Fortschritte?