An den Grenzen des Squeezecenter oder Was geht wirklich?!

[Tausendsasser]

Hallo liebe Gemeinde,

ich haben da mal eine Frage die mich sehr bewegt -

Was kann der Squeezecenter Server handeln?!

Also ich (bzw. mein Arbeitgeber) möchten ca. 200 bis 250 TSD einzelne MP3 Dateien von einem Squeezecenter verwalten und hosten lassen (keine Sorge - handelt sich nicht um Musik - gewerbliche Gesprächsmitschnitte und Diktate die mein Arbeitgeber über Jahre selbst erzeugt hat).

Zum ersten würde mich brennend interessieren, was für Datenmengen so von Euch mit dem Squeezecenter gehändelt werden?! Wie liegen die Daten bei EUch so vor ein Verzeichnis mit entsprechenden Unterverzeichnissen?!

Unsere Wunschvorstellung wäre es alle Daten auf einen NAS Kistchen zu schieben und auf diesem auch das Squeezecenter laufen zu lassen?!

Unser erster Versuch haben wir mit einem Thecus N5200 (war einfach zur Hand ) machen können. Das war eher unperformant um es mal vorsichtig zu formulieren. Scan der 1,2 TB Daten hat geschlagene sechs Stunden gedauert. Naja am Ende konnte man sich mit dem Squeezesoft Client nicht mehr mit dem N5200 verbinden und das Ding reagierte auch nicht mehr.
Okay ist nicht wirklich ein Wunder - der kleine bringt auch nur einen 500 Mhz Celeron mit.

Aber Theoretisch möchte ich mich vom NAS Gedanken noch nicht verabschieden. Wenn ich an den QNAP TS-809 Pro denke - dann bekommt man da einen Core2Duo mit 2 GB Ram und je nach dem auch viel Platz. Das finde ich irgendwie eleganter als ein Barebone mit einer externen USB Platte. (> Sofern wir den Kostenaspekt mal außen vor lassen).

Ich habe natürlich auch schon mit dem wirklichen netten und hilfsbereiten Logitech Support teleniert.
Logotech sagte mir, dass ich mich mit diesem Szenario außerhalb des angesprochenen Heimanwenders bewege. (Ist uns auch klar!) Aber das es beim Squeezcenter auf der anderen Seite keine Begrenzungen für die Zahl der Dateien geben sollte!

Also was meint Ihr?! Worauf kommt es an?!

Rechenleistung!? Wie viel wird nötig sein?!
RAM?!
Ist der Gedanke so etwas auf einem NAS abzubilden Schwachsinn?!
Welchen anderen Aufbau würdet Ihr empfehlen?!
Kann das Squeezecenter so eine Datenflut handeln oder nicht?!

Ich freue mich schon auf Eure Meinung!

Vielen Dank vorab und beste Grüße -

Tausendsasser!

[mherger]

> Ist der Gedanke so etwas auf einem NAS abzubilden Schwachsinn?!

Nein. Denn NAS bedeutet nicht low-Performance: http://tinyurl.com/bd8ol5 -
ist auch ein NAS :-). Bei diesen Datenmengen lohnt es sich sicherlich
nicht, bei der Server-Hardware ein paar hundert Euro sparen zu wollen.
Wichtig sind sicherlich Disk-I/O und CPU (wobei hier mehr als 2 Cores
nicht mehr wichtig sind).

> Kann das Squeezecenter so eine Datenflut handeln oder nicht?!

Da habe ich zugegebenermassen keine Ahnung. Die grössten Zahlen, die ich
bisher kannte, bewegen sich etwa in der Hälfte der von dir genannten. Ich
weiss von ein paar Usern, die mit SC 130-150'000 Lieder verwalten. Mehr
aber nicht.

Wie oft ergänzt ihr denn Dateien? Ich meine, wenn ein Scan mal die eine
oder andere Stunde dauert, so ist das ja eigentlich egal, wenn dies nicht
alle paar Tage stattfinden soll. Auch würde ich darauf achten, dass die
Daten sinnvoll in einer Ordner-Hierarchie mit nicht zu vielen
Dateien/Ordnern pro Ebene abgelegt sind. In einem solchen Fall können neue
Dateien einfach über "Musikverzeichnis durchsuchen" neu eingelesen werden..
Einfach die Ordner-Hierarchie zu den neuen Dateien manuell schnell
abklappern.

Würde mich Wunder nehmen, wie sich eure Sammlung auf einem aktuellen
Dual-Core System verhalten würde.

--

Michael

[jo-wie]

Also diese Frage würde ich auch nochmal im englischen Squeezecenter Forum stellen, da dort einfach mehr Leute aktiv sind, die eventuell in diese Regionen vorstossen.

Ich würde auch erstmal möglichst auf einem PC testen, um einfach ein Gefühl für die Erfordernisse bei den Datenmengen zu bekommen. Du solltest auch die mySQL Konfigurationsparameter anpassen, weil die eher auf Resourcenschonung getrimmt sind. Moonbase hatte da was gepostet:

http://forums.slimdevices.com/showthread.php?t=60682

RAM Speicher Ausbau ist wichtig.

Ach ja, 6 Stunden Scanzeit (nicht re-scan) sind doch flott für eine NAS. Du musst doch nicht immer einen kompletten Scan ausführen.

[Tausendsasser]

Also vielen Dank für Eure Meinungen! Ich bin wohl bewusst, das ich mich mit dieser Anfrage eher in einem Graubereich bewege - da so eine Datenmenge im ambitionierten Privatbereich praktisch nicht vorkommt.
Wenn wir mal den NAS Gedanken bei Seite legen (um die Bedenken in Bezug auf IO, RAM und Gesamtperformance der Plattform zu vernachlässigen) - denke ich bleibt der Haken beim SC. Ich weiß wirklich nicht, ob es Sinn macht diese Frage mit dieser Plattform weiter zu verfolgen.

Also ich werde Eurem Rat mal nachkommen und mal versuchen meine Frage auf englisch unters Volk zu bringen.

Vielen Dank für den Support!

[mherger]

> denke ich bleibt der Haken beim SC. Ich weiß wirklich nicht, ob es Sinn
> macht diese Frage mit dieser Plattform weiter zu verfolgen.

Warum nicht?

--

Michael

[Moonbase]

Warum nicht? (Schließe mich an.)

Die wesentlichen Dinge sind Geschwindigkeit der Datenbank (bei SC derzeit mySQL, diese Datenbank ist locker performant genug, wenn Du ihr etwas mehr "Raum" als in der Standardeinstellung gibst) und die Geschwindigkeit der Handhabung langer Listen (besonders große Playlisten in Verbindung mit dem SqueezeBox Controller sind etwas lahm).

Ich habe mal spaßeshalber SC an einem Broadcasting-Archiv mit knapp 500.000 Titeln installiert (frag' bitte nicht nach den Zeiten für den "initial Scan"… aber den muss man nur einmal machen) und gegenüber meinen derzeit ca. 26.000 Titeln zuhause keine Verlangsamung bemerkt – außer (das übliche Problem) bei der Darstellung/Übertragung langer Alben-/Titel-/Play-Listen an WebUI bzw. Controller.

Das ist allerdings ein allgemeines Problem – ich denke nicht, dass man versuchen wird, durch eine Liste von x-tausend Titeln scrollen zu wollen. Bei geschickter Rubrizierung wird man vermutlich auch in Deiner Anwendung auf eher ein paar -zig kommen, oder? Dann dürfte das gut gehen.

Mal als Vergleich: Ich durfte mal bei einem Radiokollegen mit der gleichen Datenbank (mySQL) und einer Delphi-Software unter Windows (SAM Broadcaster) die Zugriffsgeschwindigkeit an einem Archiv mit ca. 1,5 Mio. (!) Titeln erleben: Suchbegriff eingetippt, Antwortzeiten unter 0,5 Sekunden!

(Mein) Fazit: Wenn Du nicht endlose Listen in einer Ansicht brauchst (also Dein Archiv gut grund-rubriziert/unterteilt ist) und Du mit einer u.U. mehrtägigen initialen Einscanzeit leben kannst, probier es einfach mal. SC allein (zuerst ohne Hardwarekauf) reicht ja zum Probieren.

In dem von Dir geschilderten Anwendungsfall würde ich allerdings nicht am falschen Ende sparen (PC-Hardware ist günstig!) und – mal so aus dem Bauch – etwa wie folgt konfigurieren:

• Dual- oder Quad-Core CPU > 2GHz
• 4–8 GB RAM
• Schnelle SATA II-Platte(n) [ggf. in Shuttles für Backup]
• OS und Daten auf getrennten Platten
• Linux-System (fast egal welches, nimm das, das Du gut kennst)
• Standard-mySQL (statt dem "mitinstallierten") in "large"- oder "huge"-Konfiguration, optimiert für InnoDB

[jo-wie]

Ich habe mal spaßeshalber SC an einem Broadcasting-Archiv mit knapp 500.000 Titeln installiert (frag' bitte nicht nach den Zeiten für den "initial Scan"…

Wow, wieder eine Größenordnung mehr kennengelernt. Und ich muss doch mal böse fragen: wie lange hat's gedauert? Interessiert mich doch. Und worauf lief das SC?

• Dual- oder Quad-Core CPU > 2GHz
• 4–8 GB RAM
• Schnelle SATA II-Platte(n) [ggf. in Shuttles für Backup]
• OS und Daten auf getrennten Platten
• Linux-System (fast egal welches, nimm das, das Du gut kennst)
• Standard-mySQL (statt dem "mitinstallierten") in "large"- oder "huge"-Konfiguration, optimiert für InnoDB

Siehst du wirklich bei der CPU einen Bedarf am Quad Processor? Eher doch Speicher und Plattensubsystem, oder?

Wie verhält es sich mit SC auf einem 64Bit OS bei dem Speicherausbau? Erfahrung? (Jaja, fänd ja garantiert was, bin nur grad veschnupft und etwas suchfaul =D )

Grüße,

jo-wie

[Moonbase]

[…] Und ich muss doch mal böse fragen: wie lange hat's gedauert? […] Und worauf lief das SC?

Gute 5 Tage … allerdings mit sub-optimaler Hardware und Scan über Netzwerk. (Konnte und wollte auf den Produktions-Servern dort nichts installieren.) Habe der Faulheit halber ein bereits eingerichtetes Windows-Rechnerlein genommen (XP, 1.8GHz P4, 1GB RAM). War mal so ein in einer Bierlaune geborener Crashtest – hinstellen, laufen lassen und schauen, ob’s kracht ;-) Mit Linux (und lokalen Platten) geht sowas deutlich schneller.

[Übrigens haben sich seitdem ein paar der Kollegen ein SB-System für zuhause gekauft – mit SC/SB sitzt der Musikredakteur nun daheim im Sessel und bereitet die Sendung mit Hilfe des Controllers vor :-)]

Siehst du wirklich bei der CPU einen Bedarf am Quad Processor? Eher doch Speicher und Plattensubsystem, oder?

Dual auf jeden Fall (der Scan kann seit einiger Zeit auf der 2. CPU laufen), Quad eigentlich nur, wenn außerdem MusicIP verwendet werden soll. Allerdings könnte vielleicht ein Quad mit Linux was bringen – bin da aber unsicher, ob Linux eine Verteilung macht, wenn "nur" ein bisschen Perl läuft. Der Quad könnte auch interessant werden, wenn viele Transcoding-Prozesse laufen müssen (Versorgung von "dünn angebundenen" Außenstellen etwa).

Ansonsten hast Du natürlich Recht: Speicher, Speicher, Speicher (auch für mySQL!). Schnelle Platten sind ein Bonus (für’s OS, den Scan und mySQL – für’s reine Streamen ist das nicht so wichtig, da ist die Datenrate recht gering). Auf einer schnellen CPU hacke ich deswegen so rum, weil der komplexe Perl-Code doch relativ viel CPU-Zeit "frisst".

Wie verhält es sich mit SC auf einem 64Bit OS bei dem Speicherausbau? Erfahrung?

Leider (bisher) null Experimente in Richtung 64bit-OS.

[mherger]

>> […] Und ich muss doch mal böse fragen: wie lange hat's gedauert? […] Und
>> worauf lief das SC?
>
> Gute 5 Tage

Wow!

> … allerdings mit sub-optimaler Hardware und Scan über
> Netzwerk.

Gratuliere! Du hast Nerven :-)

> Windows-Rechnerlein genommen (XP, 1.8GHz P4, 1GB RAM). War mal so ein
> in einer Bierlaune geborener Crashtest – hinstellen, laufen lassen und
> schauen, ob’s kracht ;-) Mit Linux (und lokalen Platten) geht sowas
> -deutlich- schneller.

Das ist ein für uns sehr interessanter Crashtest.

> Dual auf jeden Fall (der Scan kann auf der 2. CPU laufen), Quad
> eigentlich nur, wenn außerdem MusicIP verwendet werden soll. Allerdings
> -könnte- vielleicht ein Quad mit Linux was bringen – bin da aber
> unsicher, ob Linux eine Verteilung macht, wenn "nur" ein bisschen Perl
> läuft. Der Quad -könnte- auch interessant werden, wenn viele
> Transcoding-Prozesse laufen müssen (Versorgung von "dünn angebundenen"
> Außenstellen etwa).

SC selber kann von zusätzlichen Cores tatsächlich nicht profitieren, auch
auf Linux nicht. Aber die von dir genannten Ausnahmen (Transcoding,
MusicIP) und z.B. iTunes Integration aber tatsächlich.

--

Michael

[Moonbase]

[…] Du hast Nerven :-)

Naja, nicht wirklich … Eigentlich bin ich der ungeduldigste Mensch der Welt ;-) … Hinstellen, starten, mit den Kollegen ein Bier trinken gehen und eine Woche später wiederkommen war aber eine gute Strategie :-)

Das ist ein für uns sehr interessanter Crashtest.

Wenn mir jemand einen gescheiten Job anbietet, kann ich den gerne auch mal mit anderer (=geeigneterer) Konfiguration wiederholen … ;-)