PDA

View Full Version : Was hällt TS-Server aus?


WebTeufel
20-10-2005, 10:35
Moin

meine Frage ist ob der TS einen Limit hat wo es Probeleme machen könnte.
Also LImit in dem Sinne, wieviele Sub-Server man erstellen kann/darf unter einem laufendem Haupt-Server, sage ich mal so...


Hat da einer Erfahrungen oder sonstige Werte?

Peter
20-10-2005, 10:59
Unter linux sollte man nicht mehr als 80 Virtuelle Server pro Instanz anlegen.
Ausserdem denke ich ab 2000 user oder so ist es sinnvoller einen neuen Server anzulegen (allein schon wegen der Uebersicht).

Bastian
20-10-2005, 12:29
Übrigens sollte man bereits bei 700 Usern nicht auf die Idee kommen einen Server der im Public-Modus läuft auf den Clan-Modus umzustellen, wie es ein Mann Namens Peter mal auf einem der Public Server getan hat.

Es KÖNNTE zu Problemen kommen wenn der Server ca. 700 Clients einander vorstellen muss. :p

WebTeufel
20-10-2005, 22:21
Übrigens sollte man bereits bei 700 Usern nicht auf die Idee kommen einen Server der im Public-Modus läuft auf den Clan-Modus umzustellen, wie es ein Mann Namens Peter mal auf einem der Public Server getan hat.

Es KÖNNTE zu Problemen kommen wenn der Server ca. 700 Clients einander vorstellen muss. :p

lol

na dann

und mit 80 Servern, wo hat du die zahl her?

Germeshausen.de
20-10-2005, 23:08
Erfahrungswert.

R. Ludwig
21-10-2005, 07:14
ich rate unbedingt von dem einsatz mit mysql ab. die anbindung ueber dbexpress fuehrt sehr oft zu massiven problemen die nur sehr schwer auf die mysql schnitstelle zurueckzufuehren sind.

St4Lk3R
22-10-2005, 11:12
wie meinen Sie das denn, Herr Ludwig?

Mein Webprojekt hostet kostenlos Teamspeak²-Server und bei uns laufen z.Zt. 1100 Server auf 2 Rootserver verteilt. Alle diese Server benutzen MySQL, da sich das leichter backuppen lässt... Wir haben immer 50 Subserver auf einer Serverinstanz, d.h. 11 Serverinstanzen pro rootserver. allerdings fällt uns auf, dass immer wieder mal eine der Serverinstanzen abschmiert... liegt das einfach daran dass der rootserver an der leistungsgrenze ist oder hängt das mit dieser MySQL-Schnittstelle zusammen???

marcelrx
22-10-2005, 11:44
wie meinen Sie das denn, Herr Ludwig?

Mein Webprojekt hostet kostenlos Teamspeak²-Server und bei uns laufen z.Zt. 1100 Server auf 2 Rootserver verteilt. Alle diese Server benutzen MySQL, da sich das leichter backuppen lässt... Wir haben immer 50 Subserver auf einer Serverinstanz, d.h. 11 Serverinstanzen pro rootserver. allerdings fällt uns auf, dass immer wieder mal eine der Serverinstanzen abschmiert... liegt das einfach daran dass der rootserver an der leistungsgrenze ist oder hängt das mit dieser MySQL-Schnittstelle zusammen???

1. Warum läst sich de MySQL DB einfach backupen als die server.dbs. Hmm.
2. Wenn der Server schon an der Leistungsgrenze ist und es Probleme gibt dann brauchst dich auch nicht Wundern.

Germeshausen.de
22-10-2005, 12:26
Also 11 Instanzen pro System mit jeweils 50 Subservern ist sicherlich ein weig zuviel des Guten. Ich würde an eurer Stelle einen dritten Root hinzunehmen und jeweils 4 Instanzen umziehen. So das jeder nicht mehr als 8 Instanzen hat. Und selbst das scheint mir noch zu knackig für das System. Mich würde mal interessieren, wieviele Prozesse jeweils auf dem System laufen. Schau mal mit dem Befehl top nach. Würde mich nicht wundern, wenn das System die Menge nicht verarbeiten kann.
MySQL ist für TS2 noch nicht richtig interessant. Man nenne mir mal bitte einen vernünftigen Grund, warum MySQL dem sqlite vorzuziehen ist. Ich weiß auch nicht, wer der Ansicht ist, dass sqlite nicht leistungsfähig ist. Man sollte bedenken, dass es sich hier bei TeamSpeak nicht um irgendwelche Foren mit tausenden von Besuchern und ebensoviele Beiträge handelt die täglich verarbeitet werden, sondern um ein Voice-Chat System und da sind die Kapazitäten von sqlite bei weitem nicht ausgereizt.

Brain
22-10-2005, 13:11
Mein DB-Prof im Grundstudium hat gesagt: Solange ihr keine 10 Millionen von Datensätzen habt tuts auch ein Flatfile. Wenn man bedenkt, daß Datenbankanfragen bei einem Voice-Chat-Programm wohl sehr selten sind (Join/Leave/Änderungen an den Channels) sollte man sehr gut ohne MySQL auskommen. Immerhin darf man nicht vergessen, das "richtige" Datenbanken auch mit einem gewissen Overhead daherkommen, der sich erst dann relativiert wenn richtig viele Daten richtig oft abgefragt werden. Insofern könnte es vielleicht sein, daß gerade weil man MySQL benutzt die Systemperformanz leidet.

Bastian
22-10-2005, 14:41
Eben. Man bedenke dass MySQL ständig laufende Server-Prozesse benötigt, mal ganz abgesehen davon dass viele Leute ihre Server auf einem System betreiben, das gar keinen MySQL-Server zur Verfügung stellt.

Die SQlite-Lösung ist jedenfalls viel einsteigerfreundlicher und für normale Einsatzgebiete eines TS-Servers völlig ausreichend. IMHO gibt es nur einen Grund auf MySQL zurückzugreifen, und das ist wenn man die TS-Server mit einer Forum-Datenbank u.ä. koppeln will.

Dafür ist SQlite dann denkbar ungeeignet da so ziemlich jedes umfangreichere Web-Portal MySQL verwendet. Wenn man es richtig anstellt kann man sogar die Rechtesysteme von Forum und Server verbinden. Wer Admin im Forum bekommt, bekommt automatisch Admin auf dem Server.

Jaja. Es gibt immer Vor- und Nachteile. :)

Brain
22-10-2005, 17:19
IMHO gibt es nur einen Grund auf MySQL zurückzugreifen, und das ist wenn man die TS-Server mit einer Forum-Datenbank u.ä. koppeln will.
Das braucht man eigentlich noch nicht mal. PHP unterstützt auch sqlite, seit einiger Zeit sogar schon von Haus aus ohne daß man das noch extra einbinden muß.
Wenn du keinen Bock hast TS2 auf MySQL umzustellen (schon alleine wegen der Clientlibrarypfuscherei würde ich das nicht machen, da rollen sich mir die Fußnägel hoch) dann mußt du lediglich die MySQL-Tabelle in deinem Forensystem, in der die Benutzer gespeichert sind um eine Zeile namens "ts2id" erweitern. Dort trägst du dann die id ein, die TS2 in der sqlite-Datei in der Benutzertabelle speichert.
Auf die Art und Weise hast du eine Zuordnung zwischen Teamspeak-Benutzern und Forumbenutzern. Was natürlich nicht direkt geht sind gekoppelte Abfragen, das ist natürlich der Nachteil dieser Aktion.