Antispam-Plugin

WordPress empfiehlt als Antispam-Plugin Akismet. Dieses werde ich hier jedoch nicht verwenden. Die Funktionisweise von Akismet besteht darin, alle Daten von Kommentatoren an die in den Vereinigten Staaten stehenden Akismet-Server zu übertragen, auf denen die Funktionalität zum Erkennen von Spam umgesetzt ist. Technisch gesehen ist so ein zentraler Server sicher interessant und je mehr Daten er sammelt, desto zuverlässiger kann er Spam erkennen.

Jedoch ist dieser Ansatz für europäische Blogs problematisch. Die Informationen, die öffentlich sichtbar werden, also der Kommentartext, sind mit etwas gesundem Menschenverstand unproblematisch, weil dieser Blog weltweit lesbar. Aber nicht-öffentliche Informationen, wie z.B. IP-Adressen, Mailadressen u.s.w. sollten nicht einfach so herausgegeben werden. Artikel dazu findet man beliebig viele, ich verweise mal auf Wikipedia, Sergej Müllers Blog (nicht mehr online 2019), Datenwachschutzblog und auf die Möglichkeit, beliebig viele weitere Artikel zu dem Thema mit der Suchmaschine des Vertrauens zu finden.

So werde ich mir irgendwann einmal Alternativen zu Aksimet ansehen, z.B Antispam Bee, Mollom, Defensio oder Typepad Antispam.

Vielleicht reicht der Captcha-Mechanismus auch aus, um Spam zu unterbinden. Zur Zeit ist WordPress so konfiguriert, daß ich Kommentare zu den Artikeln manuell freischalten muß. Das beabsichtige ich zu tun, solange sie zum Thema sind und nicht grobe Verstöße gegen ungeschriebene, allgemeingültige Nettiquette Regeln beinhalten. Da Spam-Kommentare inhärent „off-topic“ sind und außerdem noch gegen die Nettiquette verstoßen, werde ich sie auf jeden Fall nicht freischalten. Aus heutiger Sicht ist also ein Antispam-Plugin für diesen Blog noch nicht eilig.

Wer sich aus Datenschutzgründen dafür interessiert: Die Server, auf denen dieser Blog läuft, stehen in Deutschland. Der Internetverkehr dorthin kann aber irgendwelche Wege durch irgendwelche Länder nehmen und unterwegs analysiert werden. Das ließe sich mit https verhindern oder zumindest erschweren, nur unterstütze ich zur Zeit leider kein https.

Anmerkung: Inzwischen ist der Spam auf diesem Blog zur Plage geworden. Deshalb setze ich jetzt Antispam-Bee ein, was den europäischen Datenschutzbestimmungen gereicht werden soll.

Share Button

Latency of DB-connections

Deutsch

Applications that are using a database are often running slower than one would  expect by the power of the hard- and software.  Both DB server and application server are running on powerful machines that are not even close to their limits.

The problem is the connection between the two servers. This connection is of course very fast, which can be quite impressive when huge amounts of data need to be transferred, all at once.  Ideally think of the huge  resultset  of one query.

Typical database access operations need multiple accesses to the DB-server.  Each one of these works according to a communication protocol.  Usually this implies some round trips.  So many small accesses to the database tend to slow the whole application, because it is mostly waiting for the connection.

What can be done about this?
First of all the real bottleneck should be identified before optimizing something that is not the problem.

It does make a lot of  sense to optimize the application for larger and fewer queries, so more data is transferred at once.  This may not be easy with frameworks, especially if eclipselink or hibernate is used.  A typical anti pattern is to read a large number of records from the database and then fetch detail information for each record from another table, with one request for each record.  This can usually be avoided by using complex SQL queries and it is sometimes worth the effort.  As always optimizations should only be done where they are either not very intrusive or where the benefit is likely to justify them.

Another more general optimization is to put application and database on the same server.  This is often not easy, because many system administrators do not like this too well.  But if sufficient performance can only be achieved by putting all on one server, this is recommended.  Maybe it is an advantage of NoSQL databases that system administrators do not know any best practices that suggest to install database and application on different servers, so they can be running on the same server, thus eliminating most (but not all) of the latency.

Share Button

Latenz von DB-Verbindungen

English

Applikationen, die eine Datenbank verwenden, sind oft zu langsam, obwohl man doch einen großen Server für die Applikation und einen zweiten großen Server für die Datenbank bereitgestellt hat. Und schaut man sich diese beiden an, sind sie womöglich noch nicht einmal so stark ausgelastet.

Das Problem ist, dass die Verbindung zwischen den beiden Servern zwar sehr schnell ist, was man vor allem daran sieht, wenn man große Datenmengen auf einmal überträgt.

Typische Datenbank-Applikationen benötigen aber viele einzelne Zugriffe auf die Datenbank. Bei jedem dieser Zugriffe muss ein Kommunikationsprotokoll angewendet werden, also mehrere Male eine Antwort über die Verbindung abgewartet werden. Deshalb führen viele kleine Datenbankzugriffe zu einer Verlangsamung der Applikation, weil dauernd auf die Netzwerkkommunikation gewartet werden muss.

Was kann man tun?
Sinnvoll ist sicher, die Applikation so zu optimieren, dass durch geschickte Queries mehr Daten auf einmal übertragen werden. Das ist oft nicht einfach, wenn man Frameworks wie zum Beispiel Hibernate oder Eclipselink verwendet.
Eine andere Optimierung ist es, Datenbank und Applikation auf demselben Server laufen zu lassen. Diese Optimierung ist auch nicht einfach, weil das die Systemadministratoren in der Regel überhaupt nicht mögen, aber es ist eine Möglichkeit, die man doch in Betracht ziehen sollte, wenn sich anders keine hinreichend gute Performance erzielen lässt.

Share Button