ich möchte aber auch nicht die hörerzahl pro stream limitieren.
Doch, das möchtest Du. Du möchtest das sogar ganz dringend. Du wirst auch gleich sehen, warum:
wie kriege ich die zahl der slots raus, uplinkbandbreite durch streambandbreite?
Radio Eriwan sagt: im Prinzip ja. Die Bandbreite des Uplink ist eine feste Größe, über die Du rein physikalisch nicht hinauskannst. Insofern ist, zumindest in der Theorie, Uplinkbandbreite / Streambandbreite die *maximale* physisch unterstützte Anzahl Slots. Wenn Du mehrere Streams auf demselben Server hast, so teilen sich diese die Bandbreite natürlich. Das verkompliziert zwar die Rechnung ein bißchen, aber nicht wesentlich: Uplinkbandbreite / (Slots(Stream1) * Bandbreite(Stream1) + Slots(Stream2) * Bandbreite(Stream2) + ...). Andersherum, und damit komme ich wieder auf das, was ich Eingangs sagte, solltest Du die Slots sämtlicher Streams auf dem Server so limitieren, daß die Uplinkbandbreite nicht überschritten wird.
Jetzt kommt noch ein sehr wichtiger Punkt: ich schrieb oben etwas von "theoretischer" Maximalzahl. Die Netzwerkanbindung Deines Servers wird i.d.R. nicht ausschließlich von Streams genutzt. Da sind gewöhnlich immer einige kleinere Dienste, die die ebenfalls Bandbreite brauchen. Zusätzlich kann - je nach Betriebssystem - der Kernel Schwierigkeiten (im Sinne von Ressourcenprobleme) bekommen, wenn die Netzwerkverbindung im Vollastbetrieb arbeiten muß. Drittens, und das ist vielleicht das entscheidende Problem, ist der "Uplink" Deines Servers *nur* das Stückchen Kabel zwischen Deinem Server und dem nächsten Router. Solange Du das RZ nicht selbst betreibst (und auch dann nur bis zum Übergabepunkt), weißt Du nicht, wie "dick" die Routen von dort bis zum Kunden (Hörer) sind - es können überall Flaschenhälse auftreten. Last not least hast Du auch noch "unbekannte" Konkurrenz: andere Server, die im selben Netzwerksegment liegen, auf den Routen "draußen" Konkurrenzverkehr aus anderen RZ - im Prinzip niemals vorhersehbar.
Wie weit Du tatsächlich technisch gehen kannst, läßt sich vermutlich nicht einmal empirisch eindeutig belegen, da ja die Hörer zu allem Unglück auch noch verschiedensten Parametern unterworfen sind. Selbst wenn nur ein einzige Slot belegt ist, kann es immer noch passieren, daß der buffert, wenn es irgendwo auf dem Weg einen Engpaß gibt. Eine letzte Sicherheit gibt es also nicht. Ich empfehle - auch aus eigener Erfahrung - daß man zur Berechnung der maximalen Streamanzahl nicht 100% Uplinkbandbreite heranziehen sollte, sondern eher ca. 80% - das hat sich als grobe Faustformel ganz gut bewährt.
das wäre ungünstig für meinen fall, da ich viele streams mit verschiedenen bandbreiten hab.
Das sollte an sich kein größeres Problem darstellen. Der Loadbalancer sollte ja generell nur über Streams derselben Bandbreite balancieren, d.h., daß Du im Prinzip für jede angebotene Bandbreite eine eigene Loadbalancer-Instanz laufen läßt. Jede dieser Loadbalancer-Instanzen kennt dann halt n Streams, von denen jeder m Slots hat. Das wiederum heißt, daß Du für jeden Stream sein "Gewicht" ausrechnen kannst (als Anteil seiner Slots an der Gesamtanzahl verfügbarer Slots). Zusammen mit der momentanen Auslastung läßt sich so recht leicht der nächste Kandidat für einen neuen Request ermitteln. Voraussetzung dafür ist natürlich, daß der Load Balancer permanent (mindestens in bestimmten Intervallen) über die aktuelle Auslastung bescheid weiß. Sollte ein Stream komplett wegfallen (zum Beispiel wegen Neustart), dann sollte der Loadbalancer die Gewichte neu berechnen - das gleiche gilt natürlich, wenn ein vorher ausgefallener Stream wieder- oder ein neuer dazu kommt.
Ist alles keine Hexerei, aber hinreichend komplex
LG
McCavity
