Mongoose: Tool zum Testen der Speicherleistung

Guten tag habr Es wird ein Tool zum Testen der Leistung von Speichersystemen (Datenspeichersystemen) sein, die ursprünglich von EMC für interne Zwecke entwickelt wurden, aber die Fähigkeit haben, reibungslos zu wachsen. By the way, wörtlich „gestern“ Mungo bekam den Status des Opensource - Projekt . Und das heißt, es ist Zeit, ein bisschen über ihn zu reden. Also, was ist dieses Biest?

Bild

Hauptmerkmale


  1. Verteilter Modus Dies
    ist eine Möglichkeit zum gleichzeitigen Ausführen von Ladetasks von vielen Netzwerkknoten mit zentraler Steuerung und Erfassung von Metriken. Vereinfachte Darstellung aus der Dokumentation:

    Ermöglicht es Ihnen, die Belastung des verteilten Speichers erheblich zu erhöhen und die Anforderungen einer großen Anzahl von Benutzern zu emulieren.

  2. Berichterstattung
    • Ausgabedateien mit Listen verarbeiteter Objekte (Dateien, ...), die am Eingang wieder verwendet werden können
    • Verfügbarkeit von hochauflösenden Zeitstempeln (μs) für jede einzelne Operation

  3. CRUD ( C Reate / R ead / U pdate / D elete) - erhältlich Typen von E / A - Operationen für die Last Schaffung
  4. Unterstützung für verschiedene Arten von Speicher:
    • Amazon S3 REST API
    • EMC Atmos REST API
    • OpenStack Swift REST API
    • Dateisystem (lokal, NFS-Mount, ...)

  5. Unterstützte Objekttypen:
    • Container (bei FS sind sie Verzeichnisse, bei S3 Bucket)
    • Daten (Dateien beim Arbeiten mit dem Dateisystem)

  6. Überprüfung der Daten während des Lesevorgangs
  7. Beliebige Datengenerierung (inkomprimierbares einheitliches Rauschen, Text oder identische Bytes)
  8. Skriptsprache
  9. "Stub" : Ein HTTP-Server, der die Funktionen eines Cloud-Speichersystems implementiert, das keine Daten speichert, diese aber beim Lesen zurückgeben kann. In der Tat ein Speicher-Mock zum Testen der Funktionalität und Leistung des Mungos selbst. Es zieht ihn an, sowohl ein Distributed Stub als auch ein FS-Fahrer zu werden.
  10. Web-GUI
  11. Und es gibt noch viele andere wundervolle Dinge, deren Auflistung zu viel Platz beanspruchen wird.

Bekannte Analoga


  • Apache JMeter Das
    Analogon ist sehr bedingt und hat so wenig mit dem Mungo gemein, dass ein Vergleich fast unmöglich ist.
  • COSBench (Intel)
    Näher an der Funktionalität als JMeter.
    Vorteile: hat eine längere Entwicklungshistorie und aktivere Entwickler, unterstützt eine größere Auswahl an Speichersystemen.

    Nachteile: In einigen funktionalen Punkten schlechter (z. B. Erzeugung beliebiger Daten) und in der Leistung schlechter (löst nicht das sogenannte "S10K" -Problem).


Ein paar Worte zur hohen Belastung


Da ein Leistungstest-Tool eine hohe E / A-Last erzeugen sollte, muss dieses Tool selbst sehr produktiv sein und Umgebungsressourcen sehr effizient verwenden.
  1. Lösen des C10K- Problems
    In früheren Versionen des Mungos wurden Threads an die entsprechenden Verbindungen gebunden. Es wurde schnell klar, dass dieser Ansatz fehlerhaft war. Bei der Arbeit mit großen Objekten mit einer großen Anzahl von Threads waren die Leistungsindikatoren besonders schlecht. Nach der Anwendung ereignisgesteuerter asynchroner E / A waren die Ergebnisse jedoch beeindruckend. Das Tool hat die Funktionsfähigkeit auch bei 1 Million gleichzeitig geöffneten Verbindungen unter Beweis gestellt, und dies auch ohne die Verwendung des verteilten Modus , mit dem Sie diese Zahl multiplizieren können.



  2. Zero Copy wo immer möglich
  3. Automatische Konfiguration der E / A-Puffergrößen basierend auf bekannten Größen der übertragenen Daten. Kleine Objekte sind kleiner als der Puffer, große Objekte sind größer als der Puffer. Schreiben - mehr Ausgabepuffer, Lesen - mehr Eingabepuffer. Die Puffer befinden sich tatsächlich im direkten Speicher, um eine Nullkopie bereitzustellen.

Wie es in der Praxis aussieht


Nachdem Sie den Tarball mit der neuesten Version heruntergeladen und entpackt haben, beginnt der Mungo einfach zu blamieren:
java -jar mongoose-/mongoose.jar

Dies führt dazu, dass der Mungo standardmäßig versucht, alles zu tun:
  • Führen Sie die Erstellung neuer Objekte (create) für immer aus (bis der Benutzer sie unterbricht)
  • S3 API verwenden (d. H. HTTP-Anforderungen generieren)
  • 1 Verbindung zur Standardadresse verwenden (127.0.0.1:9020)

Um in diesem Fall etwas anderes als Fehler zu sehen, können Sie versuchen, einen "Stub" auf demselben Computer auszuführen (der als Speicher-Mock dient):
java -jar mongoose-/mongoose.jar wsmock


Für diejenigen, die die GUI verwenden möchten, müssen Sie den folgenden Befehl ausführen:
java -jar mongoose-/mongoose.jar webui

Rufen Sie den Browser unter 127.0.0.1:8080 auf.


Ein weiteres wichtiges Feature ist die benutzerdefinierte Skripterstellung. Das Skript ist im JSON-Format geschrieben und kann beim Start wie folgt angegeben werden
java -jar mongoose-/mongoose.jar -f .json

Eines der einfachsten Szenarien lautet wie folgt:
{
    "type": "load"
}

Dieses Skript wird standardmäßig von Mungo verwendet, wenn keine andere Skriptdatei explizit angegeben ist. Ein etwas komplexeres Beispielskript:
{
   "type" : "for",
   "value" : "threads",
   "in" : [
      1, 10, 100, 1000, 10000, 100000
   ],
   "config" : {
      "load" : {
         "threads" : "${threads}"
      }
   },
   "jobs" : [
      {
            "type" : "load"
      }
   ]
}


Weitere Informationen zur Verwendung finden Sie im Abschnitt Dokumentation auf der Mungo-Website .

Was weiter?


Zum Zeitpunkt des Schreibens ist die neueste stabile Version 2.4.1. Derzeit läuft die aktive Entwicklung von Version 3, in der eine neue Architektur (Monitor - Generator - Treiber - Monitor) angewendet wird, die neue Möglichkeiten für den verteilten Betriebsmodus und Skripte vom Typ "Weighted Load" eröffnet.



Zukünftige Pläne umfassen auch Folgendes:
  • Erweiterte Web-GUI
  • Implementierung von unvollständigen (Teil-) Datenleseoperationen
  • Erweiterung der Palette der unterstützten Speichertypen (Google Cloud Storage, EMC Centera, ...)
  • DBMS-Unterstützung (?)

Jetzt auch beliebt: