Die Apache SSL Client Zertifikatsauthentifizierung funktioniert nicht mehr. Fehler: Forbidden You don’t have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication.

Wenn z.B. nach einem Update auf Debian 10 Buster eine vorher funktionierende Apache SSL Client Certificate Authentication nicht mehr funktioniert und der Fehler

Forbidden You don’t have permission to access this resource.Reason: Cannot perform Post-Handshake Authentication.

auftritt, dann liegt es daran, dass es bei TLS1.3 Probleme mit der Authentifizierung mit Client Certificates gibt:

Als kurzfristige Lösung kann man in der Apache SSL Config die Verwendung von TLS1.3 deaktivieren.
vim /etc/apache2/mods-available/ssl.conf

SSLProtocol all -SSLv3 -TLSv1.3

Nach einem Reload der Apache Config funktioniert die Client Zertifikats Authentifizierung wieder.

TYPO3 Extension Repository kann nicht mehr aktualisiert werden. Fehler: An exception occurred while executing; INSERT INTO tx_extensionmanager_domain_model_extension …….incorrect string value:

Beim Versuch bei einer TYPO3 Installation die Extension Repository zu aktualisieren trat folgender Fehler auf:

An exception occurred while executing; INSERT INTO `tx_extensionmanager_domain_model_extension ……. Incorrect string value: ‘\xC4\x85gol)’ for column `DBNAME`.`tx_extensionmanager_domain_model_extension`.`update_comment` at row 8

Dieser Fehler trat auf einem neuen Debian 10 Server mit alten TYPO3 Installationen auf. Bei Debian 9 funktionierte das Update der Repository noch ohne Probleme.

“Incorrect string value: ‘\xC4\x85gol)&#039” deutet auf ein Zeichensatz Problem hin. Bei einer Netzrecherche fand ich gleichartige Problem die nicht nur auf TYPO3 bezogen waren. Dort wurde vorgeschlagen den Zeichensatz der betreffenden Tabelle auf utf8mb4 zu konvertieren.
Glücklicherweise löste dies das Problem mit dem fehlgeschlagenen Repository Update in TYPO3. Anschließend musste noch die betreffende Tabelle geleert werden.

Lösung:
ALTER TABLE tx_extensionmanager_domain_model_extension CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

TRUNCATE table tx_extensionmanager_domain_model_extension;

Fehler: “Oops, an error occurred!” beim Updaten der TYPO3 Extension “Dynamic Content Elements (DCE)

Problem: Nach dem Update der TYPO3 Extension “Dynamic Content Elements (DCE)

tritt im Backend die Fehlermeldung “Oops, an error occurred!” auf.

Lösung: Dieses Problem lässt sich leicht beheben, indem man im Installtool von TYPO3 die Extension Autoload Informationen mit dem Befehl “Create autoload information for extension” neu aufbaut:

Danach funktioniert TYPO3 wieder ohne Probleme.

Wenn man ein DCE Update plant, öffnet man das Installtool am besten vor dem DCE Update in einem anderen Browserfenster. Dann ist die Lösung nur ein Klick weit entfernt.

Wenn man Shellzugriff auf die TYPO3 Installation kann man alternativ auch den Ordner “autoload” im Ordner typo3conf löschen.

TYPO3 8.7 form_legacy Wizard ausblenden / Code anzeigen / Form definition anzeigen / Hide Form Wizard

Bei der form_legacy Extension in TYPO3 8.7 kann man nicht wie bei der Form Extension in TYPO3 7 zwischen Form Code Definition und Wizard / WYGIWYS Editor / Assistent umschalten. Es wird standardmäßig nur der Wizard angezeigt. Um wieder Zugriff auf den Code der Form Konfiguration zu erhalten muss man das User TSConfig des aktuellen Benutzers anpassen.

Folgender Typoscriptbefehl blendet den Formwizard aus:

setup.default.tx_form.showWizardByDefault = 0

Quellen:

TYPO3 8.7 Update der DCE RTE Flexform Konfiguration bei DCE Elementen aus TYPO3 7.6

Problem:

Durch den Wechsel des TYPO3 HTML Editors auf den CKEditor tritt bei einen DCE Inhaltselement mit einem RTE Element ein Problem auf, dass beim Speichern jedes Mal zusätzliche Leerzeilen zur Ausgabe hinzugefügt werden.

Beispiel der DCE HTML Ausgabe eines RTE Steuerelements mit alter Flexform Config (TYPO3 7.6) nach mehrmaligen speichern:

p><strong>Modernisieren Sie jetzt!&nbsp;</strong></p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>

Um dieses Problem zu beheben, muss man bei der TYPO3 8.7 DCE Definition das RTE Flexform Config updaten.

DCE RTE Flexform Konfig in TYPO3 7.6

<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
</config>
<defaultExtras>richtext[]:rte_transform[mode=ts_css]</defaultExtras>

DCE RTE Flexform Konfig in TYPO3 8.7

<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
    <enableRichtext>1</enableRichtext>
    <richtextConfiguration>default</richtextConfiguration>
</config>

Um das Update für alle DCE RTE Elemente in der Datenbank auf einmal zu erledigen, kann man dies direkt mit folgender SQL-Abfrage tun:

USE dbname;
update tx_dce_domain_model_dcefield set configuration=
'<config>
    <type>text</type>
    <rows>5</rows>
    <cols>30</cols>
    <eval>trim,required</eval>
    <enableRichtext>1</enableRichtext>
    <richtextConfiguration>default</richtextConfiguration>
</config>'
where configuration like '%rte_transform%';

Nach TYPO3 Update auf 8.7 werden bei DCE Inhalts- Elementen „Kopie 1“ oder „Kopie 2“ im Inhalt angezeigt

Die Ursache ist mir noch ein wenig unklar, warum nach dem Update auf TYPO3 8.7 bei kopierten Inhaltselementen des Plugins DCE die Header Spalten der tt_content Tabelle angezeigt werden. Darin befinden sich bei kopierten DCE Elementen die Zeichenfolge “Kopie 1”. Wobei die Zahl bei mehreren Elementen hochgezählt wird. Vorhanden waren die Einträge vor dem Update auf TYPO3 8.7 zwar auch schon, wurden aber nicht angezeigt. Erst nach dem TYPO3 Update haben die kopierten DCE Elemente einen h2 Header mit dem Inhalt “Kopie n”.

Eine Recherche hat zwei Lösungsvorschläge gebracht, die leider für mich nicht in Frage kamen.

Der erste Lösungsvorschlag war eine Typoscript Konfiguration

TCEMAIN.table.tt_content {
disablePrependAtCopy = 1
disableHideAtCopy = 1
}

Diese zeigte bei meiner TYPO3 Seite keine Wirkung. Die Header mit “Kopie 1” wurden immer noch angezeigt. Ich gehe davon aus, dass sich die Typoscript Einstellung nur auf neue kopierte Elemente auswirkt.

Der zweite Lösungsvorschlag war, die bei DCE Inhaltselementen standardmäßig ausgeblendete Spalte “Header” mittels “Sonstige” -> “Vefügbare Objekte” -> “Überschrift(header)” einzublenden und bei allen Inhaltselementen die Headerspalte manuell zu leeren.

Diese Lösung funktioniert zwar prinzipiell, ist aber bei umfangreichen TYPO3 Webseiten sehr aufwendig, da alle Inhaltselemente noch einmal bearbeitet werden müssen.

Nach einem Blick in die tt_content Tabelle der betreffenden TYPO3 Datenbank, kam mir die Idee das Problem auf Datenbankebene zu lösen.

update tt_content set header='' where header like '%Kopie%';

Mit dieser SQL Abfrage werden alle Header Elemente in der in der tt_content Tabelle geleert, die das Muster %Kopie% in der Spalte “header” enthalten. Nach einem Cachelöschen waren die unerwünschten Überschriften wie “Kopie 1” aus dem Inhalt der Webseite verschwunden.

Benchmark / Test: STRATO vServer V80 vs. STRATO Hardware Server D410

Hier sollen die STRATO – Hardware Server 400er Linie mit dem STRATO vServer Flaggschiff verglichen werden. Auf dem Papier sehen die Leistungswerte des größten STRATO vServers (V-Server Linux V80) nicht schlecht aus: 16CPU Kerne, 32GB Ram und 1TB HDD/SSD. Gegen diesen virtualisierten Server tritt ein dedizierter Hardwareserver mit vergleichbaren Werten an (Hardware Server Linux D410): 4 CPU Kerne, 8 Threads, 32GB RAM, 480GB SSD.

Stand 07/2018

Hier die Daten der beiden Server:

Bezeichnung	€/Monat	RAM	CPU Cores	CPU MHz	HDD	Inodes
Hardware Server Linux D410-81	63,00 €	32GB	4	3500	480GB	28.991.488
Strato vServer Linux V80-49	30,00 €	32GB	16	2000	1000GB	132.382.720

Beide Server wurden mit Debian 9 installiert. Als Benchmark wird Sysbench verwendet.

CPU Benchmark:

Befehl: sysbench –test=cpu –cpu-max-prime=10000 –num-threads=XX run

Gemessen wird hier die Zeit in Sekunden. (Kleinere Werte besser)

	Threads
Bezeichnung	1	2	4	8	16	32
Hardware Server Linux D410-81	7,3	3,8	1,9	1,1	1,1	1,1
Strato vSserver Linux V80-49	16,3	8	4,6	2,7	2,3	2,1

Hier geht der Hardwareserver klar als Sieger aus dem Rennen. Obwohl der vServer auf dem Papier 4-mal so viele CPU Kerne hat, ist der Hardwareserver bei allen Threadzahlen schneller als der vServer. Das könnte neben dem Virtualisierungsoverhead unter anderem daran liegen, dass der vServer CPU Takt auf 2000 MHz limitiert ist. Bei einem Thread ist die Hardware CPU mehr als doppelt so schnell wie die vServer CPU.

RAM Benchmark:

Befehl: sysbench –num-threads=xx –test=memory –memory-block-size=1M –memory-total-size=100G

Gemessen wird hier die Zeit in Sekunden. (Kleinere Werte besser)

	Threads
Bezeichnung	1	2	8	32
Hardware Server Linux D410-81	8,1	4,4	2,2	2,2
Strato vServer Linux V80-49	20,4	12,2	6,5	5,4

Beim RAM-Benchmark zeigt sich wieder die Überlegenheit des Hardwareservers. Beide Server haben 32GB RAM, doch der Hardwareserver benötig für das Beenden des Benchmarks, über alle Thread Anzahlen, weniger als die Hälfte der Zeit.

FILE-IO Benchmark:

Befehl: sysbench –test=fileio –file-total-size=8G –file-test-mode=rndrw –init-rng=on –max-time=300 –max-requests=0 –file-block-size=4K run

Gemessen wird hier Datenübertragungsrate in MB/s. (Größere Werte besser)

Bezeichnung	MB/s
Hardware Server Linux D410-81	34,23
Strato vServer Linux V80-49	12,79

Auch hier zeigte sich, dass die beim vServer beworbene “topmodernen Hochleistungs-Speicherplattform HP 3PAR – für allerhöchste Zugriffsstabilität, sowie ultraschnelle Lese- und Schreib-Geschwindigkeiten” nicht gegen lokalen SSD Speicher bestehen kann. Der Hardwareserver erreichte beim Sysbench Filie-IO ReadWrite Benchmark fast die dreifache Leistung gegenüber dem vServer.

MySQL Online-Transaction-Processing Benchmark:

Befehl: sysbench –test=oltp –oltp-table-size=10000000 –mysql-db=sysbench –mysql-user=sysbench –mysql-password=password –max-time=60 –max-requests=0 –num-threads=xx –oltp-reconnect-mode=random run

Gemessen wird hier absolute Anzahl der durchgeführten Datenbanktransaktionen. (Größere Werte besser)

Dieser Benchmark bildet am besten einen realistischen Workload ab bei dem CPU, RAM und FILE IO zusammenspielen müssen.

Hier kann man, wie bei den Einzelergebnissen der CPU, RAM und File-IO Benchmarks sehen, dass der Hardwareserver fast die dreifache Leistung gegenüber erreicht.

Fazit:

Obwohl der STRATO vServer auf dem Papier die gleiche oder sogar bessere Ausstattung gegenüber dem dedizierten Hardwareserver hat, kann er in keinem Benchmark gegen diesen bestehen. Beim aussagekräftigsten MySQL Benchmark erreicht der Hardwareserver fast die dreifache Leistung gegenüber dem vServer.

Kurz zusammengefasst: Hardware kann man nur durch noch mehr Hardware ersetzten. Selbst der größte vServer v80 kommt in Punkto Performance nicht an einen einfachen dedizierten Hardwareserver heran.

Tipp: Kostenloses Homebanking Programm/Onlinebanking Programm Jameica/Hibiscus

Nachdem ich mich jahrelang mit überfrachteten und schlecht bedienbaren Onlinebanking-Programmen wie Starmoney, Lexware, WISO Mein Geld herumgeärgert hatte, sprang mir heute die Meldung “Nutzungsperiode abgelaufen” beim Start von WISO Konto Online entgegen. Statt ein Abo für die Software abzuschließen, machte ich mich auf die Suche nach Alternativen. Dabei musste ich feststellen, dass es gerade bei den Onlinebanking-Programmen sehr wenig Auswahl gibt. Eine Suche nach “online banking software” bei Amazon brachte fast nur WISO und Lexware Software. Dann bemühte ich Google. Dabei sah ich, dass es sogar eine kostenlose Homebanking -Software gibt. Jameica/Hibiscus von Olaf Willuhn . Zuerst war ich skeptisch, aber nach dem Download und dem Start der Software lies sich mein Girokonto mit optischen chipTAN Verfahren so schnell und problemlos einrichten, dass sich meine Skepsis in Neugierde wandelte. Der Funktionsumfang des Programms deckt genau das ab was ich von einem Onlinebanking-Programm erwarte:

Einfaches Einrichten des Kontos
Schneller Abgleich der Umsätze
Ein Kategoriensystem um die einzelnen Umsätze Kategorien zuzuordnen
Ein flexibler Mechanismus um regelbasiert Umsätze automatisch bestimmten Kategorien zuzuordnen
Schnelle und effiziente Möglichkeit Überweisungen zu tätigen
Unterstützung des optischen chipTAN Verfahrens
Adressverwaltung von Überweisungsempfängern

Ich werde dem Programm auf jeden Fall eine Chance geben. Im Moment sieht es sehr vielversprechend aus. Gerade im Vergleich zu der WISO Onlinebanking-Software, die mich auch nach Jahren nicht überzeugen konnte.

Jedem der auf der Suche nach einem alternativen Onlinebanking-Programm ist, kann ich nur empfehlen sich Jameica/Hibiscus anzuschauen: http://www.willuhn.de/products/hibiscus/

Ansible: Verwenden einer Variable als Name einer Liste mit with_items

Nach dem Update von Ansible 1.7 auf Ansible 2.4 funktionierte eine Ansble Rolle nicht mehr. Bei dieser Rolle wird der Wert einer Variable als Namen einer Liste in einem with_items Konstrukt verwendet.

In Ansible 1.7 funktionierte folgender Syntax noch:

VARS main.yml
---
chooselist: list1

list1:
- { port: '443', src: 'any', proto: 'tcp'}
- { port: '80', src: 'any', proto: 'tcp'}

list2:
- { port: '22', src: 'any', proto: 'tcp'}
- { port: '53', src: 'any', proto: 'tcp'}

TASK:main.yml
---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ chooselist }}"

In Ansible 2.4 wird bei obigen Syntax ein Fehler ausgegeben: “The task includes an option with an undefined variable.”

Nach einiger Suche fand ich in folgenden Beitrag “SOLVED: ansible 2.0: with_items: “{{ variable }}_fixstring” resolve issue #14032” die Lösung.

Damit nun Variablen als Namen von Listen mit with_items verwendet werden können, muss man statt

with_items: "{{ chooselist }}"

folgenden Syntax mit dem vars Schlüsselwort verwenden:

with_items: "{{ vars[chooselist] }}"

Der komplette, in Ansible 2.4, funktionierende Task sie dann wie folgt aus aus:

---
- name: with_items_test
  debug: msg="{{ item.port }}|{{ item.src }}|{{ item.proto }})"
  with_items: "{{ vars[chooselist] }}"

Benchmark der neuen Hetzner Cloud VMs mit Apache Bench und Sysbench

Der Hosting-Anbieter Hetzner hat seit Kurzem ein flexibles und relativ preisgünstiges Hosting von virtuellen Servern im Angebot. Das Produkt nennt sich “Hetzner Cloud”. “Cloud” deshalb, weil man nicht direkt fertige virtuelle Maschinen bekommt, sondern eine Umgebung, in der man flexibel seine VM konfigurieren kann. Man kann neben zehn Kombinationen von CPU Cores, RAM, HDD, Speicherart und Speicherart das Datacenter auswählen und die Linux Distribution auswählen. Die Konfiguration der Cloud geschieht in einer ansprechenden Web-Oberfläche. Wenn benötigt, ist die Konfiguration der Cloud auch per API möglich. Was mich positiv überrascht hat, ist die Geschwindigkeit, mit der ein neuer Server ausgerollt wird. Es dauert keine Minute, bis ein neuer Server online per SSH erreichbar ist. Ebenso schnell ist ein Server auch wieder zurückgebaut.

Mit Preisen zwischen 2,96€/Monat und 35,58€/Monat liegt das Angebot in einem attraktiven Rahmen. Um die Leistungsfähigkeit der Hetzner Cloud einschätzen zu können, wurden von sechs verschiedenen Serverkonfigurationen jeweils eine VM erstellt und verschiedene Benchmarks darauf ausgeführt.

Um die Ergebnisse der Benchmarks einordnen zu können, wurden zusätzlich zu den Hetzner Cloud VMs ein Strato vServer und ein Hardwareserver getestet.

Hier die getesteten Server (Stand 02/2018):

Server	€/Monat	RAM	CPU Cores	CPU MHz	HDD	Inodes
Hetzner Cloud cx11	2,96 €	2GB	1	2100	20 GB	1.224.000,00
Hetzner Cloud cx21	5,83 €	4GB	2	2100	40GB	2.448.000,00
Hetzner Cloud cx31	10,59 €	8GB	2	2100	80GB	4.888.000,00
Hetzner Cloud cx41	18,92 €	16GB	4	2100	160GB	9.768.000,00
Hetzner Cloud cx51	35,58 €	32GB	8	2100	240GB	14.656.000,00
Hetzner Cloud cx41-ceph	18,92 €	16GB	4	2100	160GB	9.768.000,00
Strato vServer Linux V30-49	14,00 €	8GB	4	2000	500GB	6.000.000,00
Hardware Server Linux D400-68	54,00 €	16GB	8	3300	220GB	14.344.192,00

Die Hetzner Server cx11-cx51 unterscheiden sich nur in der unterschiedlichen CPU-, RAM- und HDD-Ausstattung. Die VMs basieren hier auf lokalen SSDs. Diese Konfigurationen sind auf Performance und weniger auf Hochverfügbarkeit ausgelegt. Im Gegensatz dazu bietet Hetzner alle Cloudserver auch noch als Konfiguration basierend auf dem verteilten Speichersystem CEPH an (cx41-ceph). Hier liegen die Dateien der VMs redundant im Netzwerk vor. Positiv fällt auf, dass die Inode Quota der Hetzner Cloud Server angemessen ist. Inodes braucht man z. B. bei einem rsnapshot Backup, bei dem jeder symbolische Link ein Inode verbraucht. Bei kleineren Strato vServern stößt man da schnell an Grenzen.

Auf den ersten Blick ist die Ausstattung der Server mit Festplattenspeicher schlechter als bei den Strato vServern. Dort hat ein Server für 14€/Monat 500GB Festplattenspeicherplatz. Bei Hetzner bekommt man dagegen für z. B. 18€ nur 160GB Speicherplatz. Das könnte für manche Anwendungen ein Problem sein, für die meisten kleineren Webserverprojekte etc. sollte dies aber keine Rolle spielen.

Alle Hetzner Server laufen mit Debian 9, PHP 7, Apache und MariaDB. Die Strato Server mit Debian 8, PHP 5, Apache und MySQL.

Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)

Mit ApacheBench werden von einem Remote Server Websites auf dem zu testenden Server aufgerufen. Für eine feste Zeitspanne – hier 30 Sekunden – wird ermittelt, wie viele Websites der Server ausliefern kann. Als Website dient bei den Hetzner Servern eine TYPO3 8.6 CMS mit dem Bootstrap Instroduction Package. Bei den Strato Servern dient als Website ein TYPO3 7.6 CMS.

Das Benchmark-Tool wird bei jedem zu testenden Server mit drei unterschiedlichen Anzahlen von gleichzeitigen Request pro Zeitpunkt (Concurrency Level) aufgerufen.

(ab -kc XXX -t 30 http:/WWW.SERVERNAME.TLD/)

	Concurrency Level 5	Concurrency Level 50	Concurrency Level 100
Strato vSserver	2451	3851	3696
cx11	3180	4590	4564
cx21	3509	4990	4603
cx31	4105	5531	5336
cx41	4202	10081	9417
Hardware	2702	10155	9609
cx41-ceph	4752	10888	10983
cx51	4453	14818	15379

Da ApacheBench einen Stresstest auf einen Webserver ausführt, kommt dieser Benchmark einem realen Workload sehr nahe. Alle Serverkomponenten spielen hier eine Rolle bei der Leistungsfähigkeit.

Was direkt auffällt, ist die sehr gute ApacheBench-Leistung der Hetzner Server, die ab dem Modell cx41 selbst mit einem dedizierten Hardwareserver, der wesentlich mehr kostet, mithalten können. Das cx51-Modell übertrifft sogar die Leistung des Hardwareservers. Ebenfalls fällt auf, dass der CEPH-basierte Cloudserver cx41-ceph sogar eine bessere Leistung hat als sein Pendant mit lokalem SSD Storage.

Hinten, weit abgeschlagen, liegt der Strato vServer, den sogar das kleinste Hetzner Modell cx11 übertrumpft – und das nur für einen Bruchteil der monatlichen Gebühr.

SysBench MySQL

Sysbench MySQL simuliert einen realen MySQL Workload mit Lese- und Schreiboperationen.

(sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=test –mysql-password=PASSWORD –max-time=60 –oltp-read-only=off –max-requests=0 –num-threads=[ANZAHL THREADS] run)

	1 thread	2 threads	8 threads	32 threads
cx11	730	1476	5516	8591
cx31	708	1521	6320	13358
cx21	712	1508	6246	14122
Strato vSserver	618	1557	5604	14189
cx41-ceph	521	1101	4256	14734
cx41	682	1468	6322	20869
cx51	703	1477	6300	25601
Hardware Server	892	1876	7522	29775

Was bei dem MySQL Sysbench Benchmark auffällt, ist, dass der Hardwareserver hier im Gegensatz zu dem Apache Benchmark leistungsmäßig an der Spitze steht. Die Anzahl der erreichten Transaktionen korreliert hier mit der Anzahl der CPU Cores. Bei zwei gleichzeitigen Threads liegen alle Server noch fast gleichauf. Bei höheren Anzahlen gleichzeitiger Threads sieht man hingegen die Auswirkung der CPU Core Anzahl immer deutlicher.

SysBench CPU Benchmark

Bei dem Sysbench CPU Benchmark wird Zeit gemessen, die benötigt wird, um eine bestimmte Anzahl (hier 10000) von Primzahlen zu verifizieren.

(sysbench cpu sysbench –test=cpu –cpu-max-prime=10000 –num-threads=XX run)

	1	2	4	8	16
Hardware Server	8,3	4,2	2,2	1,2	1,2
cx51	10,4	5,2	2,6	1,3	1,3
cx41-ceph	9,1	4,7	2,4	2,4	2,4
cx41	10,3	5,2	2,6	2,6	2,6
Strato vSserver	10,9	5,4	3,7	3,7	3,7
cx21	10,5	5,2	5,2	5,2	5,2
cx31	10,4	5,2	5,2	5,2	5,2
cx11	10,5	10,5	10,8	10,6	11,2

Wie zu erwarten, liegt hier der Hardwareserver mit seinen dedizierten CPU Kernen (und der höheren Taktfrequenz) bei dem Sysbench CPU Benchmark wieder an der Spitze. Das Verhältnis der Anzahl der CPU Cores zu der Ausführungszeit ist bei diesem Benchmark fast linear. Eine doppelte CPU Core Anzahl bedeutet eine halbierte Ausführungsdauer.

Fazit

Zusammenfassend betrachtet kann man sagen, dass die neuen Hetzner Cloud Server ein sehr gutes Bild abgeben – sowohl bei der IO-Leistung als auch bei der CPU-Leistung. Bei dem Apache Benchmark übertreffen die zwei größten Cloud Server Konfigurationen selbst den Hardwareserver. Dies hängt aber eventuell auch etwas mit der Leistungssteigerung von PHP 7 im Zusammenspiel mit TYPO3 8 zusammen. Auf den Strato Servern läuft noch Debian 8 mit TYPO3 7 und PHP5, da Strato Debian 9 für seine vServer immer noch nicht (02/2018) unterstützt.

Weiter kann man bei den durchgeführten Benchmarks keine Performance-Unterschiede zwischen den lokalen SSD Speichern und dem verteilten CEPH Speicher erkennen. Bei manchen Tests hatte der CEPH-basierte Server gegenüber seiner gleich konfigurierten Version mit lokalem SSD Speicher die Nase vorn.

Bleibt nur zu hoffen, dass die guten Benchmark-Werte nicht mit einem noch nicht voll ausgelasteten Virtualisierungs- und Speichersystem zu erklären sind. Sollten im Dauerbetrieb die Werte auf dem guten Niveau bleiben, dann wären die cx41 und cx51 Cloud Server eventuell eine Alternative zu einem wesentlich teureren Hardwareserver, bei gleichzeitig mehr Flexibilität und Featuren wie z. B. Snapshots.