Archiv des Autors: mediamill

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.

Folgende Benchmarks wurden durchgeführt:

IO-Test mit dd

Schreiben eines 1 GB Files mit dd:
(
dd if=/dev/urandom of=/tmp/benchfile bs=1024K count=1024)

Sekunden MB/s
cx11

6,6

162

cx21

7,7

139

cx31

7,7

138

cx41

7,7

139

cx51

7,7

138

cx41-ceph

6,9

154

Strato vSserver

70,1

15

Hardware

79

13

 

Bei diesem Test zeigte sich, dass der Datendurchsatz bei den Hetzner Servern um eine Zehnerpotenz besser ist. Ob hier neben der eigentlichen IO-Leistung noch andere Effekte eine Rolle spielen, kann ich nicht sagen. Die Strato Server, sei es VM oder Hardware, brauchen zehn Mal so lange, um den Test fertigzustellen. Alle Hetzner Server liegen bei diesem Test gleich auf, da hier die Anzahl der CPU Cores keine Auswirkungen auf das Ergebnis hat. Ebenfalls ist zwischen den Hetzner Cloudservern mit lokalem SSD Speicherplatz und verteiltem CEPH Speicher kein Unterschied zu erkennen.

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.

Spotty – Spotify Unterstütung für Logitech Sqeezebox Radio

Nachdem Spotify den Support für Logitech Sqeezebox Radio am 20.07.2017 eingestellt hat, war ich kurz davor meinen Spotify Account zu kündigen. Lediglich die umfangreichen Spotify-Playlists hielten mich vor übereilten Aktionen ab. Nach einer Netzrecherche gab es doch noch Hoffnung Spotify auf der Squeezebox hören zu können.

Hier die offizielle Meldung von der Spotify FAQ Seite.

Why can’t I use the Spotify app on my speaker?

LOGITECH
The Spotify integration will be completely removed from the Squeezebox and UE Smart Radiospeakers on July 20th, 2017.

Doch dank eines Entwicklers aus der Squeezebox Community gibt es doch noch eine Möglichkeit Spotify auf der Squeezebox zu hören. Das Plugin heißt Spotty und stammt von Michael Herger.

Um Spotty auf die Squeezebox zu bringen sind folgende Schritte notwendig:

  • Aktualisieren des Squeezebox Server auf die aktuellste Version
  • Installation der Visual C++ Redistributable für Visual Studio 2015 32bit auf dem Squeezebox Server (Prerequirement für die Installation von Spotty)
  • Hinzufügen des Plugin-Repositories für Spotty
    • Aufrufen der Erweiterten Einstellungen in der Squeezebox Systemsteuerung
  • Hinzufügen von http://www.herger.net/slim-plugins/repo.xml als zusätzliche Plugin Repository.
  • Aktivieren des Spotty Plugins in der Pluginliste

Konfiguration des Spotty Plugin (Eingabe der Spotify Credentials)

Danach ist Spotty Auf der Squeezebox unter Eigene Anwendungen zu finden

Spotty - Spotify Plugin für Logitech Squeezebox

Das Plugin funktioniert nach ersten Tests besser als das Originalplugin.

Bleibt nur zu hoffen dass Spotify und Logitech diese letzte Möglichkeit Spotify auf der Squeezebox zu hören nicht auch noch unterbinden. Dann haben mich Spotify und Logitech definitiv das letzte mal gesehen.

Auf seiner Seite hat Michael Herberger einen Link mit dem man ihm eine Donation via Paypal zukommen lassen kann. Ich finde es mehr als fair wenn man das Plugin verwendet dem Autor eine Anerkennung in Form einer Donation zukommen zu lassen.

Test Strato V-Server Version Linux V20

(Stand 30.10.2016)

Die Ausstattung des neuen Linux V20 vServers:

2 vCores (Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz – Effektiver Takt 1998.828 MHz)
4 GB Maxx-RAM 2 GB RAM garantiert
300 GB HDD

Als Vergleich zum Einordnen der Ergebnisse dient ein kleiner Strato-Hardwareserver:

4 CPU Cores (Quad-Core AMD Opteron(tm) Processor 1385 2700.000 MHz)
4 GB RAM
1 TB 7200 rpm HDD (Raid 1)

Nach einigen negativen Erfahrungen mit Strato vServer und ernüchternden Benchmark-Werten von Strato vServer wollte ich mir die neuen Strato V20 VServer anschauen, um herauszufinden, ob sich in Sachen Performance und Stabilität etwas getan hat.

Dazu wurden einige Benchmarks sowohl mit dem neuen vServer V20 als auch mit dem Hardwareserver durchgeführt:

SysBench MySQL

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

Anzahl Threads #Transactions vServer V20 Linux #Transactions Hardwareserver
2 2805 (46.73 per sec.) 1271 (21.16 per sec.)
4 4842 (80.65 per sec.) 2596 (43.23 per sec.)
8 8777 (145.83 per sec.) 4984 (82.98 per sec.)
16 13704 (228.29 per sec.) 11297 (188.14 per sec.)
32 18073 (300.73 per sec.) 18978 (315.95 per sec.)
64 19828 (330.07 per sec.) 28705 (478.04 per sec.)
128 20271 (337.04 per sec.) 33187 (532.58 per sec.)

SysBench CPU

sysbench –test=cpu –cpu-max-prime=10000 –num-threads=[Anzahl THREADS] run

Anzahl Threads Dauer(s) vServer V20 Linux Dauer(s) Hardwareserver
1 11.0606s 13.1548s
2 7.6546s 6.5501s
4 7.6804s 3.3243s
8 7.6758s 3.2985s
16 15.1823s 3.3063s

IO Test mit dd

Schreiben eines 1 GB Files mit dd

dd if=/dev/urandom of=/tmp/benchfile bs=1024K count=1024

Anzahl Threads Dauer vServer V20 Linux Dauer Hardwareserver
2 70,5767s (15,2 MB/s) 90,5309s (11,9 MB/s)

Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)

ab -kc [Concurrency Level] -t 30 http://www.WEBSEITE.de/

Concurrency Level #Requests vServer V20 Linux #Requests Hardwareserver
5 1952 2838
10 1968 2778
25 1796 2722

Anscheinend hat Strato nicht nur die Probleme mit den vServern in den Griff bekommen, sondern auch an der Performanceschraube gedreht.

Was auffällt, sind die relativ guten SysBench CPU Werte bei kleiner Threadanzahl im Vergleich zu dem Hardwareserver. Auch scheint jetzt endlich die schon lange beworbene “SSD-Power” bei den Kunden angekommen zu sein. Das zeigen vor allem die im Vergleich zu dem Hardwareserver besseren SysBench MySQL Werte bei niedrigeren Thread-Anzahlen. Auch bei dem IO Test mit dd zeigt der vServer V20 jetzt bessere Werte als der Hardwareserver.

Die Apache Benchmark Werte zeigen endgültig, dass die Strato vServer um Größenordnungen leistungsfähiger geworden sind im Vergleich zu 2015.

Die insgesamt wesentlich höheren Werte bei Apache Bench im Vergleich zum letzten vServer Apache Benchmark kommen von dem nun eingeschalteten PHP opcode Cache, der gerade bei TYPO3 einiges an Performance bringt.

Der einzige Wermutstropfen, der den Einsatzzweck des V20 vServer schmälert, ist die geringe Inode Quota von 800000. Selbst die älteren vServer hatten wenigstens 1000000 Inodes. Bei dem billigsten netcup vServer, der weniger als die Hälfte des kleinsten Strato vServers kostet, bekommt man immerhin 2511552 Inodes, also das 2,5-fache. Wer viele Inodes benötigt, kommt um einen Hardwareserver nicht herum.

Die Ergebnisse noch einmal zusammengefasst:

+ Sehr gute SysBench CPU Leistung

+ Sehr gute SysBench MySQL Werte

+ Gute Apache Bench Werte

+ Großzügiger Festplattenplatz

– Sehr geringe INODE Quota im Vergleich zu Hardwareservern

Webserver Benchmark: Strato Rootserver vs. Strato vServer

Hier ein Benchmark mit dem Linux-Programm ab (Apache HTTP server benchmarking tool). Zielsysteme waren zwei Strato Root Server Linux Hardwareserver und ein Strato Virtual Server Linux. Getestet wurde von einem externen Hardwareserver. Die Dauer der Testläufe betrug jeweils 60 Sekunden. Die gleichzeitigen Requests wurden von 1 bis 250 vaiiert. Aufgerufen wurde die Startseite einer komplexen TYPO3 6.2 Webseite. Die Leistungsunterschiede zwischen den einzelnen Servern zeigen, dass sich “Blech” nur durch noch mehr “Blech” ersetzten lässt. Kleine Strato vServer eignen sich nur für Test- oder Hobbyzwecke. Die beworbene “SSD-Power” bringt für kleine Strato vServer keinen Leistungsschub. Heruntergebremst wird der Strato vServer durch die auf 560 MHz heruntergetakteten vCores.

Hier die Ausstattungen der getesteten Server:

Root Server Linux Medium (bkm-v1411.1.39) 02.2016
Quad-Core AMD Opteron(tm) Processor 1385
4×2.70GHz
bogomips: 5400.07
4 GB Ram
Root Server Linux Small (bkm-v1411.1.29) – 12.2014
Dual-Core AMD Opteron(tm) Processor 1214 HE
2×2.20GHz
bogomips: 2000.00
4 GB Ram
Virtual Server Linux Level 1 Site (Wandel.1406.ERG) – 07.2009
2 vCores
559MHz
2 GB

Webserver Benchmark von Strato Rootserver vs. Strato vServer

Benchmarkergebnisse