Gigabyte-Monster, das: WordPress-Plugin Social

Das WordPress-Plugin Social von Alex King und Crowdfavorite soll eigentlich ein Blog besser mit seinen „Sozialen Netzwerken“ verknüpfen und Kommentare aus selbigen in das Blog integrieren. Doch dabei zeigt sich erneut, wie ineffizient in der WordPress-Community „leider“ oft gearbeitet wird. Social ist im Wortsinn ein Gigabyte-Monster und schert sich einen feuchten Kehricht um Prinzipien wie DRY.

Die WordPress-Community ist sehr groß und sehr hilfreich, aber viele Plugin-Autoren sind keine echten Programmierer und deren Software stellenweise hoffnungslos ineffizient. Zudem wird beim Entwurf der Plugins selten angenommen, dass damit „große“ Webseiten betrieben werden. Das zeigt sich ebenso im Fall von „Social“.

Es ist oft der Zufall, der zu Beobachtungen wie den nachfolgend erläuterten führt. Weil wir auf Macnotes mittlerweile unsere Social-Media-Accounts mit HootSuite verwalten, war ich auf der Suche nach einer Möglichkeit, Facebook-Kommentare trotzdem automatisiert mit dem WordPress-Plugin Social zu aggregieren. Was ich jetzt weiß ist, das Plugin speichert eine spezielle „Story“-ID zu einer Account-ID in einem JSON-Format zu jedem Artikel. Die Account-IDs kennen wir, die „Story“-IDs sind immer andere und wenn wir eben nicht Social für das Verbreiten der Meldungen nutzen, sondern HootSuite, müssten wir diese umständlich für jeden Artikel von Hand zusammensuchen.

Metakeys in WordPress-Postmeta-Tabelle

Was ich aber ebenfalls weiß ist, dass Social ein Gigabyte-Monster ist und jeder der über 40 000 aktiven Nutzer sollte sich sehr gut überlegen, ob er es „wirklich“ weiter nutzen will. Es sei denn, die Anbieter ändern was an ihrer total ineffizienten Art und Weise, die paradigmatisch ist für viele WordPress-Plugins. Leider.

Verschmerzbar: „_social_notify“ und „_social_aggregation_next_run“

In der Postmeta-Tabelle werden Metadaten zu jedem Artikel gespeichert. Das Social-Plugin legt insgesamt 7 Stück davon an. In zweien finden sich lediglich Zahlen. In „_social_notify“ nur eine 0 oder eine 1, je nachdem ob die automatische Aggregation von Kommentaren für diesen Artikel aktiviert ist, oder nicht. Im feld „_social_aggregation_next_run“ wird jeweils ein Timecode gespeichert, der einem Cronjob sagt, wann er das nächste mal für diesen konkreten Beitrag nach „sozialen Kommentaren“ auf die Suche gehen soll. Die ineffiziente Architektur von dieser WordPress-Tabelle sorgt dafür, dass beide Werte nicht als Zahl oder Boolscher Wert, sondern als Longtext gespeichert werden. Doch dies ist ein Kompromiss zu all den anderen Daten, die in der Regel in dieser Tabelle gespeichert werden und verschmerzbar.

Chronistenpflicht: „_social_broadcast_content“

Doch dann gibt es weitere Felder wie „_social_broadcast_content“. Darin wird der Inhalt jeder Nachricht gespeichert, die man für den konkreten Artikel über Social publiziert. Hat man mehrere Accounts, und gibt man sich nicht viel Mühe, dann findet man darin quasi immer denselben Inhalt mehrfach kopiert. Für den zufällig gewählten Artikel in unserem Fall mit der ID 189589, den ich exemplarisch in diesem Beitrag auswerte, hat dieses Feld, wenn man es als Textdatei speichert, 3 KByte Größe. Bei über 32 000 Artikeln auf Macnotes erzeugt allein dieses Feld also rund 96 MByte in der Datenbank. Je mehr Artikel wir veröffentlichen, desto größer wird dieser und werden alle anderen Werte werden.

Warum aber speichert man die Werte in „_social_broadcast_content“ überhaupt? Nennen wir es Chronistenpflicht. Wenn ein Nutzer sich nicht mehr erinnert, kann man ihm anzeigen, was er bereits zuvor getwittert oder auf Facebook weitergesagt hat. Je mehr Accounts in Social Networks man verwaltet, desto größer wird der Inhalt entsprechend.

Ineffizient: „_social_broadcast_meta“

In dem Feld „_social_broadcast_meta“ werden die notwendigen Meta-Daten für den entsprechenden Artikel gespeichert, und zwar für jeden einzelnen Social-Media-Account extra. In der Regel bedeutet dies, dass man X mal den URL des Artikels dort stehen hat, den URL zum Artikelbild, den Titel des Artikels, usf. Es wäre sicherlich effizienter, wenn man diese Daten nur einmal speicherte. Vor allem, weil Social gar keine Individualität an dieser Stelle erlaubt. Hätte das Plugin eine Oberfläche, in der man für jeden Tweet oder Facebook-Post ein separates Bild auswählen könnte, prima. Doch Social nutzt „immer“ nur das Artikelbild. Als könnte es sich gerne auf einen einzigen Satz Metadaten beschränken, wenn es überhaupt diese Daten doppelt speichert, die sowieso von WordPress bereits zu jedem Artikel in der Datenbank gespeichert werden.

Im Ergebnis hat der Artikel mit der ID 189589 als Textdatei 2 KByte Größe. Bei der Größe von Macnotes entspricht das weiteren 64 Megabyte in der Datenbank.

Notwendig und ineffizient: „_social_aggregated_ids“ und „_social_aggregation_log“

Notwendig sind hingegen zwei weitere Felder, wenngleich man zumindest beim zweiten die Struktur diskutieren könnte. Das Feld „_social_aggregated_ids“ ist noch mit am konzisesten. Es speichert zu jedem Artikel die Sozialen Netzwerke, auf denen etwas weiter gesagt wurde, nebst den Account-IDs und den zugehörigen Story-IDs von denen ich anfänglich erzählte. Mit diesen Daten wird das Plugin in der Folge in regelmäßigen Abständen die APIs von Twitter und Facebook abfragen, ob es zu Story X auf Plattform Y von Account Z irgendwelche Interaktionen gibt. Wenn ja, liest „Social“ sie aus und fügt sie in die Kommentar-Tabelle von WordPress ein. „_social_aggregated_ids“ hat im Fall von Artikel 189589 eine Größe von knapp 0,4 KByte. Sie wäre heute sicherlich etwas größer, weil wir mittlerweile noch mehr Social-Media-Accounts verwalten, doch ist der Datensatz nicht redundant und in ihm wird nur gespeichert, was wirklich gespeichert werden muss.

Anders schaut es da schon bei „_social_aggregation_log“ aus. In diesem Feld wird so etwas wie eine Chronik oder ein Logbuch der Abfragen notiert, aber deutlich umständlicher als es sein müsste. Jedes mal, wenn das Plugin zu einem Artikel die Social-Media-APIs befragt, fügt es das Ergebnis quasi an dieser Stelle hinzu. Nehmen wir an, bei der ersten Abfrage, die 2 Stunden nach der Veröffentlichung des Artikels geschieht, findet es zwei Retweets und eine Favorisierung auf Twitter und fünf Likes auf Facebook sowie drei Kommentare auf einer Fanpage.
„Social“ speichert dann zunächst den Hinweis, ob es manuell oder automatisch angestoßen wurde und die Nutzernamen zu den Interaktionen, die IDs, ob es sich um einen Retweet, einen Like, usf. handelt. Was in diesem Feld „nicht“ gespeichert wird, ist die konkrete Nachricht, falls es eine gibt. Denn die wird ja in der Kommentar-Tabelle von WordPress abgelegt. Beim zweiten Durchlauf nach 4 Stunden geht das Ganze von vorne los. Alle Beiträge, die beim ersten Mal schon durchforstet wurden, werden erneut aufgeführt, nur an irgendeiner Stelle mit dem Hinweis „ignored“ (engl. für ignoriert) versehen. Offenbar notiert das Plugin so aber nur, dass es diesen Kommentar ignoriert hat und kein zweites Mal als Kommentar in die Datenbank aufgenommen. Denn beim dritten Durchlauf nach 8 Stunden, und nach 12 Stunden und nach 24 Stunden usf. findet man die gleichen „ignoriert“-Hinweise noch mal und noch mal und nochmal. Das ist eindeutig ineffizient.

Für den Artikel 189589 ergibt das „_social_aggregation_log“-Feld eine Textdatei mit der Größe von 31 Kilobyte. Bei über 32 000 Artikeln auf Macnotes entspricht das 992 MByte. Aber das war leider noch nicht die Spitze der Ineffizient.

Total ineffizient: „_social_broadcasted_ids“

Denn die folgt in Form des Feldes „_social_aggregation_log

Ähnliche Nachrichten