Leistungsprobleme bei Verwendung von SSD für ein Entwickler-Notebook (WAMP / LAMP-Stack)?


7

Ich bin ein Webanwendungsentwickler, der mein Notebook als eigenständige Entwicklungsumgebung (WAMP-Stack) verwendet. Ich habe gerade von einem Core2 Duo Vista 32-Bit-Notebook mit 2 GB RAM und SATA-Festplatte auf ein i5-2520M Windows 7 64-Bit mit 4 GB RAM und 128 GB SSD (Corsair P3 128) umgestellt.

Meine anfängliche Erfahrung war das, was ich erwartet hatte, schneller Start, schnelles Laden aller Anwendungen (Eclipse dauert jetzt 5 Sekunden im Gegensatz zu 30 Sekunden auf meinem alten Notebook), insgesamt eine großartige Erfahrung. Dann begann ich meinen Entwicklungsstapel aufzubauen, sowohl als LAMP (unter Verwendung von VirtualBox mit einem Debian-Gast) als auch als WAMP (Windows-nativer Apache + MySQL + PHP). Ich wollte diese beiden vergleichen.

Das hat immer noch gut geklappt, dann habe ich angefangen, meine Projekte in diese Stapel zu ziehen. Und hier kam die böse Überraschung, dass eines dieser Projekte viel schlechtere Reaktionszeiten verursachte als auf meinem alten Notebook (das galt sowohl für die VirtualBox als auch für den WAMP-Stack). Apache-, PHP- und MySQL-Konfigurationen waren in allen Umgebungen praktisch identisch. Ich habe angefangen, viel Benchmarking und Profiling durchzuführen, und hier ist, was ich gefunden habe:

  1. Alle allgemeinen Benchmarks (Leistungstest 7.0, HDTune Pro, wPrime2 und einige mehr) gaben dem neuen Notebook einen großen Vorteil. Hier ist nichts überraschend. Disc-spezifische Tests zeigten, dass die Lese- / Schreibvorgänge für die SSD einen Spitzenwert von 380 M / 160 M erreichten und alle Blockoperationen unterschiedlicher Größe ebenfalls sehr gut abschnitten.

  2. Startete das Apache Performance Benchmarking mit Apache Benchmark für eine kleine statische HTML-Datei (10 gleichzeitige Threads, 500 Iterationen).

    • Altes Notizbuch: min 47ms, median 111ms, max 156ms
    • Neuer WAMP-Stapel: min. 71 ms, Median 135 ms, max. 296 ms
    • Neuer LAMP-Stack (in VirtualBox): min 6 ms, median 46 ms, max 175 ms


    Genau hier verstehe ich nicht, warum der native WAMP-Stack so schlecht lief, aber zumindest die LAMP-Umgebung brachte die erwartete Geschwindigkeit.

  3. Apache-Leistungsmessung für nicht zwischengespeicherten PHP-Inhalt. Das PHP führt eine Schleife von 1000 aus und generiert sha1 (uniqid ()) inisde. Wiederum wurden 10 gleichzeitige Threads und 500 Iterationen für den Benchmark verwendet.

    • Altes Notizbuch: min 0ms, median 39ms, max 218ms
    • Neuer WAMP-Stapel: min 20 ms, median 61 ms, max 186 ms
    • Neuer LAMP-Stack (in VirtualBox): min. 124 ms, Median 704 ms, max. 2463 ms


    Was zum Teufel? Die neue LAMP zeigte eine miserable Leistung, und selbst die neue native WAMP wurde vom alten Notebook übertroffen.

  4. PHP + MySQL Test. Der Test besteht aus dem Herstellen einer Verbindung zu einer Datenbank und dem Lesen eines einzelnen Datensatzes aus einer Tabelle mit INNER JOIN für drei weitere (indizierte) Tabellen, die 100 Mal innerhalb einer Schleife wiederholt werden. Datenbanken waren identisch. 10 gleichzeitige Threads, 100 Iterationen wurden für den Benchmark verwendet.

    • Altes Notizbuch: min 1201 ms, Median 1734 ms, max 3728 ms
    • Neuer WAMP-Stapel: min 367 ms, median 675 ms, max 1893 ms
    • Neuer LAMP-Stack (in VirtualBox): min. 1410 ms, median 3659 ms, max. 5045 ms


    Und der gleiche Test mit Parallelität auf 1 (statt 10):

    • Altes Notizbuch: min 1201 ms, median 1261 ms, max 1357 ms
    • Neuer WAMP-Stapel: min 399 ms, median 483 ms, max 539 ms
    • Neuer LAMP-Stack (in VirtualBox): min. 285 ms, median 348 ms, max. 444 ms


    Streng genommen könnte ich mit dem Ergebnis des zweiten Tests zufrieden sein, da ich eine in sich geschlossene Entwicklungsumgebung (= geringe Parallelität) verwende. Obwohl ich keine Ahnung habe, warum die VirtualBox-Umgebung bei höherer Parallelität so schlecht abschneidet.

  5. Schließlich habe ich einen Test mit vielen PHP-Dateien durchgeführt. Die Anwendung, die ich am Anfang erwähnt habe und die so schlecht lief, hat einen schweren Bootstrap, lädt beim Initialisieren Hunderte kleiner Bibliotheks- und Konfigurationsdateien. Dieser Test enthält also nichts anderes als etwa 100 Dateien. Parallelität auf 1, 100 Iterationen festgelegt:

    • Altes Notizbuch: min 140ms, median 168ms, max 406ms
    • Neuer WAMP-Stapel: min. 434 ms, median 488 ms, max. 604 ms
    • Neuer LAMP-Stack (in VirtualBox): min. 413 ms, median 1040 ms, max. 1921 ms


    Selbst wenn ich bedenke, dass VirtualBox diese Dateien über freigegebene Ordner erreicht hat und dies die Dinge etwas verlangsamt, sehe ich immer noch nicht, wie das alte Notebook beide neuen Konfigurationen so stark übertreffen kann. Und ich denke, dies ist die eigentliche Wurzel der langsamen Leistung, da die Anwendung noch mehr Includes verwendet und der gesamte Bootstrap innerhalb einer Seitenanforderung mehrmals auftritt (z. B. für jeden AJAX-Aufruf).

Zusammenfassend bin ich hier mit einem brandneuen Hochleistungs-Notebook, das in 20 Sekunden dieselbe Seite lädt wie mein altes Notebook in 5-7 Sekunden. Unnötig zu erwähnen, dass ich momentan kein sehr glücklicher Mensch bin.

Warum habe ich diese schlechten Leistungswerte? Welche Möglichkeiten habe ich, um diese Situation zu beheben?

Es scheint, als hätte ich endlich die Wurzel des Problems gefunden. Anscheinend können SSDs Leistungseinbußen erleiden, wenn sie in Laptops mit Intel HM55- oder PM55-Chipsätzen verwendet werden. Bitte sehen Sie meine vollständige Antwort unten.


"Apache-Konfiguration ... praktisch identisch" - glaube ich nicht.
ta.speot.is

@ todda.speot.is Ich wollte hier nicht 3 vollständige Konfigurationsdateien posten, der Beitrag ist so lang wie er ist. Haben Sie einen bestimmten Vorschlag, welche Konfigurationswerte ich überprüfen soll?
András Szepesházi

1
Es wäre wahrscheinlich hilfreich, sich den Ressourcenmonitor anzusehen, während die problematischen Tests ausgeführt werden. Hier erfahren Sie, welche Ressourcen (CPU, Speicher, SSD, Netzwerk) beansprucht werden.
Sblair

@sblair Ich habe hier einen Screenshot davon hochgeladen (zusammen mit dem Ausführen von top in der Linux-Box): my.jetscreenshot.com/7098/20110621-ky0m-95kb.png Dies ist ein Snapshot während der Anfrage, keine der Ressourcen scheint dies zu tun sei mir wirklich ausgereizt.
András Szepesházi

@Andras Ok, stellen Sie einfach sicher, dass während der Tests in keiner der Registerkarten (insbesondere bei der Festplattenantwortzeit) Spitzen auftreten. Wenn dies der Fall ist, stimme ich @todda und @MainMa zu: Eine Konfigurationsdatei kann unterschiedlich sein, oder die Versionen von Apache, MySQL oder PHP können unterschiedlich sein. Welche Core 2-CPU befindet sich im alten Laptop?
Sblair

Antworten:


2

Mit anderen Worten, Benchmarks auf Festplattenebene liefern hervorragende Ergebnisse für Ihre SSD, während die Festplatte in der Praxis höllisch langsam ist. Etwas verlangsamt also die Dinge und macht den Zugriff auf Dateien viel langsamer als erwartet.

Es kann einige Gründe geben:

  • Das wahrscheinlichste: Es gibt ein Antivirus. Einige sind wirklich Benchmark-Killer, und Sie können kaum vorhersagen, wie sie sich ohne Tests auf die Leistung auswirken.

  • Etwas anderes macht den Zugriff auf Dateien langsam. Jedes Mal, wenn Sie scheinbar viele Vorgänge mit kleinen Datenmengen testen. Aber wie sind die Leistungen beim Lesen oder Schreiben einer 10-GB-Datei?

  • Die Konfiguration des Betriebssystems kann unterschiedlich sein. Beispielsweise verwendet das Betriebssystem den Cache für kleine Dateien auf dem Computer mit der Festplatte, jedoch nicht auf dem Computer mit einer SSD. In diesem Fall sind Benchmarks für den ersten Computer falsch, da Sie die Geschwindigkeit der Festplatte nicht wirklich testen.

  • Die festplattenbezogene Konfiguration kann unterschiedlich sein. Optionen wie die für die Schreib-Caching-Richtlinie (unter Windows) können die Leistung beeinträchtigen.

  • Die SSD funktioniert möglicherweise nicht richtig.


Danke für diese Punkte. Antivirus ausgeschaltet, hat überhaupt nicht geholfen. Ich habe kleine Operationen getestet, da die Anwendung, mit der ich Probleme habe, ausschließlich kleine Operationen verwendet. Das Lesen und Schreiben großer Dateien funktioniert wie erwartet. Auch bei den HD Tune Pro-Benchmarks wurden keine Probleme (in Bezug auf Gesundheit oder Leistung) mit der SSD festgestellt.
András Szepesházi

1

Nach einer langen Woche, in der ich mit Einstellungen für eine bessere Leistung zu kämpfen hatte, fand ich endlich einige Verbesserungen, die die erwarteten Ergebnisse lieferten. (Dies ist ein Fujitsu LIFEBOOK S751-Notebook mit Intel HM65-Chipsatz und BIOS basierend auf Phoenix TrustedCore Notebook.)

Im BIOS gab es unter Erweiterte / Verschiedene Einstellungen, Abschnitt Hardware-Energieverwaltung, zwei Konfigurationsoptionen für

  • CPU-Energieeinsparung im Leerlauf (AC)
  • CPU-Energieeinsparung im Leerlauf (Batterie)

Der erste wurde auf "Energieeinsparung" eingestellt, der zweite auf "Lange Batterielebensdauer". Ich habe beide auf normal gesetzt, und siehe da, ich habe bei all meinen Testfällen eine um ein Vielfaches bessere Antwortzeit erhalten.

Anscheinend sind auch andere auf dieses Problem gestoßen : http://forum.notebookreview.com/solid-state-drives-ssds-flash-storage/513313-laptops-w-intel-series-5-chipset-can-not- take-full-nutzen-fast-ssds.html

Zitat aus diesem Thread:

Laut Benchmarks, die von mehreren Mitgliedern durchgeführt wurden, scheinen Laptops mit Intel HM55 und PM55 schnelle SSDs nicht voll ausnutzen zu können. Diese Chipsätze sind in modernen Notebooks sehr verbreitet. Der Leistungstreffer ist besonders bei der zufälligen 4K-Lese- und Schreibleistung sichtbar. Die Probleme scheinen durch eine aggressive Implementierung von Energiesparfunktionen verursacht zu werden ...

Natürlich dreht sich der Lüfter jetzt alle 5 Sekunden oder so weiter, was ziemlich ärgerlich ist, aber zumindest kann ich meinen Job machen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.