Ich weiß, das ist eine schreckliche, verallgemeinerte Frage ohne gute Antwort und ich entschuldige mich schon jetzt dafür, aber ich frage mich, ob jemand den Versuch einer sehr groben Schätzung wagen könnte.
Nehmen wir an, Sie verfügen über einen dedizierten MySQL-Server, der auf moderner Hardware im Wert von etwa 1.000 US-Dollar läuft.
Nehmen wir an, der durchschnittliche Benutzer führt 20 Lese- und 5 Schreibanforderungen pro Minute durch – alles einfache Abfragen, keine Verknüpfungen; meist nach dem Motto „Wählen Sie diese Zeile nach UUID aus“ aus einer indizierten Tabelle mit ca. 10.000.000 Zeilen.
Wie viele gleichzeitige Benutzer können Sie ungefähr von einem solchen Server erwarten, bevor Sie ihn „überfordern“?
Antwort1
Wie Sie bemerkt haben, handelt es sich hierbei um eine sehr grobe Schätzung.
Die große Frage ist, wofür Sie die 1000 $ ausgeben. Vorausgesetzt, Sie geben sich etwas mehr Speicher und weniger Prozessorleistung mit einer durchschnittlichen Festplatte, würde ich sagen, dass eine vernünftig codierte Anwendung (wobei vernünftig bedeutet, hauptsächlich die von Ihrer Sprache bereitgestellten Abstraktionsbibliotheken zu verwenden) mit diesen Parametern etwa 500 gleichzeitige Benutzer verarbeiten kann. Ich hätte mehr geschätzt, wenn da nicht die Größe des Zeilensatzes gewesen wäre (denn je mehr Zeilen direkt in den RAM passen, desto weniger müssen Sie selbst für sofortige Schreibvorgänge auf die Festplatte zugreifen).
Die Art der Daten in den Zeilen und die Menge an RAM, die Sie sich leisten können, werden in diesem Szenario definitiv die größten Faktoren sein. Wenn Sie mit weniger Schreibvorgängen auskommen und die Größe der indizierten Tabelle verringern könnten, würden Sie meiner Meinung nach mit 1.000 Benutzern gleichzeitig auskommen.
Sie werden auf die beiden folgenden Probleme stoßen:
Die Datenmenge, die Sie im RAM zwischenspeichern können, und damit die RAM-Menge, die Sie zusätzlich zum für die Ausführung der grundlegenden Betriebssystem- und Datenbankservervorgänge erforderlichen Minimum haben, bestimmt, was Sie sich leisten können. Mehr RAM, weniger Betriebssystemanforderungen und eine geringere nutzbare Datenmenge, die für Abfragen und Schreibvorgänge im RAM gespeichert werden sollte, machen den Unterschied zwischen einer akzeptablen Leistung und sehr viel Überlastung aus.
Das Design Ihrer App ist hier absolut entscheidend. Ein Schreibvorgang, der auf 500 bis 1.000 Benutzer verteilt ist, hat enorme Auswirkungen. Wenn Ihre Aufrufe nicht einfach und effizient sind, werden Sie schnell ein Zugunglück verursachen. Meine Schätzung basiert auf einer Reihe von MySQL-Apps, die ich im Einsatz gesehen habe, und auf ein wenig Wissen darüber, wie sie funktionieren. Wenn die App grundlegende Probleme hat, erreichen Sie möglicherweise nicht einmal 40 Benutzer. Wenn Sie sie effizient codieren und die Hardwarebeschränkungen berücksichtigen, können Sie möglicherweise problemlos über 2.000 skalieren.
Antwort2
Das kann ich beantworten. Ich bin gerade von der Fahrt zurückgekommen und werde wieder mitfahren.
Für 650 bis 800 US-Dollar bekommt man einen mittelschnellen Quad-Core AMD mit 8 GB RAM und einem 1 TB SATA2-Laufwerk. Für 170 US-Dollar bekommt man ein zweites, relativ schnelles 1 TB-Laufwerk. Bedenken Sie, dass es sich hierbei um handelsübliche Hardware aus den meisten Elektronik-/Büro-/Best-Buy-Läden handelt. Sie können woanders mehr bekommen, aber das ist auch nicht schlecht für das Geld. Für wenig mehr bekommen Sie einen schnelleren Quad-Core.
Was die App betrifft, gehe ich davon aus, dass Sie Linux/BSD/Unix als Betriebssystem verwenden und vermeide die MS-vs-Unix-Debatte. Folgendes habe ich herausgefunden:
Wir haben keine Probleme, bei einer unserer Anwendungen 200+ aktive Benutzer/Sitzungen anzugeben, ohne mit der Wimper zu zucken, egal wie schwach die App ist. Tatsächlich ist es uns seit einiger Zeit nicht mehr gelungen, eine Anwendung auf einem Quad-Core-Server, den wir betreiben, zum Absturz zu bringen oder sie zum Stillstand zu bringen... aber wir haben damals in den Single-Core-200-MHz-Tagen einige Lektionen gelernt.
Beispielsweise verkauft unsere Schwesterfirma eine ganze Reihe mysql-basierter Kommunikationsüberwachungssysteme mit über 1300 Benutzern pro Maschine und durchschnittlich mehreren hundert gleichzeitigen Sitzungen pro Stunde. Protokollierung und Berichterstellung erfolgen in Echtzeit (es kommt zu einigen Puffervorgängen) und sie laufen auf 3-GHz-Dual-Core-Maschinen auf [keuch] langsamen PATA-Laufwerken ... Tatsächlich 133-MHz-PATA-Laufwerken. Die längste Benutzeroberflächenverzögerung aller Zeiten betrug etwa 2 Sekunden. Sie haben MSSQL vor einem Jahrzehnt für MySQL aufgegeben und sofort Ergebnisse erzielt.
Bedenken Sie, dass auf diesen Maschinen Webanwendungen und Datenbanken laufen … rechnen Sie also nach. Es funktioniert einfach. Außerdem habe ich eine Reihe von Oracle-/MS-/xxxx-Anwendungen durch diese ersetzt und bin nie auch nur annähernd in die Puste gekommen. Lassen Sie mich außerdem aus der Sicht eines DBA auf das eingehen, was der andere Typ gesagt hat … Hier sind 6 Tipps aus der Praxis.
- Schreibvorgänge beeinträchtigen die Leistung, insbesondere wenn das Konzept einer Sperrstrafe für Ihre Programmierer fremd ist.
- Alles an einer einzigen, riesigen Tabelle zu erledigen, wird Ihr Leben kosten.
- Übermäßige Normalisierung ist nicht Ihr Freund. Wenn Ihre Programmierer die 3. Normalform vollständig verwenden, wird Ihre App schlecht laufen. Denormalisierte Daten benötigen mehr Platz, ermöglichen aber, mit einfachen Abfragen großartige Dinge zu erreichen.
- Eine große Tabelle gerät bei häufigem Schreiben ins Stocken. Siehe 1.
- Wenn Sie Ihre App so schreiben, dass sie eine (oder mehrere) Tabellen zur Datenanzeige und eine andere Tabelle für Schreibvorgänge verwendet, die bei ausreichender Systemauslastung mit den Lesetabellen synchronisiert werden kann, können Sie sich alles Mögliche erlauben. Wir verwenden eine kleine Anzahl von Tabellen zum Puffern von Schreibvorgängen und können eine erstaunliche Anzahl von Transaktionen bewältigen, da niemand in Mitleidenschaft gezogen wird.
- Verwenden Sie Indizes. Wenn Sie wissen, welche Teile der Abfragen ohnehin als Schlüssel verwendet werden.
- Optimieren Sie die Datenbankinstallation basierend auf dem Speicher. Lesen Sie die MySQL-Dokumente online. Ehrlich gesagt, wenn Sie weniger als 1000 aktive Sitzungen haben, können Sie oft einfach die Anzahl der Verbindungen erhöhen und loslegen. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
Sie können dummes SQL in Aktion sehen, indem Sie sich die meisten WordPress-/usw.-Plugins ansehen. Die meisten werden von Leuten geschrieben, die kein SQL verstehen, und sie bringen einen Server mit nur einer Handvoll Benutzern im Handumdrehen in die Knie.
Antwort3
884 $ Server, 8 GB RAM, Dual Quadcore Xeon, 300 GB 7200 U/min SATA-Laufwerk, 40 % Leerlauf, 5 % Iowait
Uptime: 780727 Threads: 276 Questions: 1884267879 Slow queries: 3964303 Opens: 60474
Flush tables: 1 Open tables: 440 Queries per second avg: 2413.478
bei der Bereitstellung von 220 MB/Sek.