wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
Und zum vergleich die interne SSD Bitte....
tocotronaut
Aktives Mitglied
- Dabei seit
- 14.01.2006
- Beiträge
- 34.445
- Reaktionspunkte
- 13.481
Die interne SSD ist dank Serial-ATA Revision 3.0 auf 600 MB/s begrenzt... Mehr schafft die Schnittstelle nicht.
Die SSD macht ca. 420 MB/s
Die SSD macht ca. 420 MB/s
wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
tocotronaut, wenn ich deine Daten so sehe...ist diese Aussage von Kaito mal ganz Falsch !! Und leicht daneben.
Über die Ramdisk ist eine Webseite deutlich schneller geladen und aufgebaut.
Diese Aussage ist von Kaito ebenfalls falsch !!
In der Version, wo nach beenden der Ramdisk alles auf Platte geschrieben wird ist auch da die Schonung deutlich vorhanden..da nur einmal am tag der Vorgang passiert.
Klar, RAM ist ja auch rund ne Magnitude schneller.
Über die Ramdisk ist eine Webseite deutlich schneller geladen und aufgebaut.
Diese Aussage ist von Kaito ebenfalls falsch !!
Da über die RamDisk, keinerlei schreib und lese Zugriff erfolgt, wird die SSD im Vollem Umfang geschont...weil zum Surfen im Netz nur die RamDisk genutzt wird.
In der Version, wo nach beenden der Ramdisk alles auf Platte geschrieben wird ist auch da die Schonung deutlich vorhanden..da nur einmal am tag der Vorgang passiert.
Kaito
Aktives Mitglied
- Dabei seit
- 31.12.2005
- Beiträge
- 7.093
- Reaktionspunkte
- 1.844
Ich bin mir nicht sicher ob es über die Zeit hinweg nun lustiger oder trauriger wird.
Seine Werte sind doch rund das 10 fache? Beim Schreiben sogar exakt, je nachdem woher der SSD Wert kommt. Das ist doch genau das, was ich sagte?
Dabei sollte man aber noch beachten, dass es nicht meine Schuld ist, wenn Apple nicht gerade "den schnellen" RAM verbaut und ein Notebook halt auch nur selten 4 Slots hat. Wie schonmal gesagt, verlinkt und selbst geprüft: da geht mehr.
Woraus besteht denn diese Schonung? Lesezugriffe auf eine SSD sind doch absolut unproblematisch, Schreibzugriffe sind es, die du nicht haben willst. Bei einem Cache, vor allem wenn du ihn nicht stark in der Größe limitierst, überwiegen die Lesezugriffe deutlich und die Schreibzugriffe sind in der Minderheit. Ich weiß nicht welchen Browser du benutzt, aber in Firefox gibt es about:cache, wo dir alle Einträge des Caches gelistet werden. Wenn du dir hier die Zahl der Spalte "Fetch" anschaust, hast du die Anzahl an Lesezugriffen pro einem Schreibvorgang. Bei mir stehen hier dreistellige Werte, sogar ein paar vierstellige.
Hast du eigentlich mal Tests gemacht, bevor du hier mit großer Schonung und vor allem
Da es mich selbst interessierte, war ich mal so frei. Sollte es irgendein Problem mit dem Testaufbau, dessen Durchführung, oder meiner Interpretation geben, bitte ich um Aufklärung. Bin kein Webdeveloper.
Zwei Seiten: "" und "[noparse]https://www.google.de" (Bildersuche, Suchwort "cache", Safe Search deaktiviert).
In den folgenden Konfigurationen: leerer Cache, Cache auf RAM Disk, Cache auf HDD.
Durchgeführt mit: Firefox 27.0.1 (Selfmanaged Cache ohne Begrenzung, 12 max pers. connections/server, 64 max pers. connections/proxy, 512 max connections) auf 10.9.1.
Vor jedem Test wurde der Cache gelöscht, im Falle der Tests mit nicht-leerem Cache ging ein initialer Aufruf der Seite voraus (um diesen zu füllen).
Vorweg der about:cache Auszug der "Cache auf RAM Disk" Tests:
Man beachte den Pfad des Caches.
Man sieht in der "Size" Spalte sehr schön, dass für jedes angefragte Element Daten vom Server übertragen wurden. Unten rechts ist eine Zusammenfassung: die insgesamt Anzahl an Anfragen an den Server, die insg. Menge übertragener Daten sowie die akkumulierte Zeit. Wichtig ist anzumerken: der Bildaufbau findet bei modernen Browsern schon vor dem Ablauf dieser Zeit statt, nachträglich erhaltene Elemente werden dabei auch erst später in die Darstellung eingefügt. Daher "springt" eine Seite, bzw. deren Inhalt, beim Aufbau oft ein wenig.
Auch wichtig: die Hauptanfrage (ganz oben), die notwendig ist, damit der Browser überhaupt erst "weiß", welche Elemente er überhaupt laden muss, benötigt den eindeutigen Großteil dieser Zeit. Dieser ist durch den Cache so nicht ersetzbar, sofern die Seite nicht statisch ist (das dürfte heutzutage kaum wo der Fall sein). Erst danach werden die Elemente geholt, die in diesem Test im Cache sein könnten, allerdings benötigt dies zum einen kaum Zeit, zum anderen findet das sehr parallel statt.
Diesmal sind die Daten schon im Cache. Wir sehen eindeutig: die lange "Hauptanfrage" bleibt so bestehen, die kleinen Fitzeldaten sind nun aus dem Cache geholt worden (ersichtlich am fehlenden Wert in der Spalte "Size"). Dies ließe sich auch durch den Statuscode in der Netconsole sehen, falls du es mal simpel bei dir selbst anschauen möchtest.
Was wir außerdem sehen (und das ist wichtig): die Zeit ist praktisch identisch. Nicht nur für die Fitzelteilchen, sondern auch die insg. Zeit. Das liegt daran, dass die "Hauptanfrage" relativ stark schwankt und im Vergleich zu dieser die kleine Anfragen einfach keine Relevanz haben.
Ich spare mir bei den letzten drei Bildern die Kommentare, denn sie sind die selben wie auch bei denen darüber. Der Grund für diesen weiteren Testlauf mit Google lag in den Cachedaten von MU, welche sehr klein sind. Darum noch der selbe Test mit google images, wodurch deutlich mehr übertragene Daten aus dem Cache kommen und dieser entsprechend eine größere Relevanz bekommt. Das sieht man an den Zahlen: die gecachte Datenmenge im Google Test ist rund 5x so groß wie die aus dem MU Test, das Ergebnis ist aber das gleiche.
Weshalb ist das so?
Wenn du dir nochmal die Bilder ansiehst, dann bemerkst du in den Zeitbalken eine graue und weiße Komponente*. Die graue Komponente ist die Zeit, die dein Browser mit Warten auf eine Antwort vom Server verbringt, während die weiße der tatsächlichen Datenübertragung entspricht. Du siehst auch bei all den Daten, die aus dem Cache genommen werden, eine starke graue Komponente, während die weiße (bei Nutzung des Caches) praktisch entfällt. Der graue Teil wirkt einfach zeitbestimmend. Du beschleunigst mit der RAM Disk die "weiße Komponente", die aber nur einen kleinen Teil in der Dauer zum Seitenaufbau einnimmt. Dieser ist so klein, dass er von den starken Schwankungen der "Hauptanfrage" gefressen wird.
Das heißt nicht, dass es keine Beispiele gibt, in denen die weiße Komponente überwiegt. Es gibt sie. Wenn ich z.B. in einem vB Forum auf einem langsamen Server, in dem ich bin, mir auf einer Seite alle 5000 Vorschlagsbenutzerbilder auf einmal anzeigen lasse, dann merkt man den Unterschied zwischen "Cache" und "kein Cache". Nur, wie oft passiert das? Ich persönlich kenne neben dieser einen Situation nur noch eine weitere, ähnliche. Dies sind gewiss keine Allerweltssituationen und ich behaupte, beim "normalen Surfen" triffst du auch auf keine.
* In Wirklichkeit gibt es mehr, diese sind aber so klein, dass hier nicht sichtbar.
Ganz falsch und leicht daneben? Beides gleichzeitig? Meinst du weil ich 750MB/s sagte und er 600MB/s? Das ist einfach: SATA III heißt in Wirklichkeit "SATA 6Gb/s" und 6Gb/s sind 750MB/s. Dass das eine, in der Realität, nicht erreichbare Geschwindigkeit ist, sagte ich aber auch. Ich kenne die "SATA 6Gb/s" Echtwelt-Performance nicht. Bei Sata II (3Gb/s = 375MB/s) lag sie etwas mehr als 100MB/s darunter.
Seine Werte sind doch rund das 10 fache? Beim Schreiben sogar exakt, je nachdem woher der SSD Wert kommt. Das ist doch genau das, was ich sagte?
Dabei sollte man aber noch beachten, dass es nicht meine Schuld ist, wenn Apple nicht gerade "den schnellen" RAM verbaut und ein Notebook halt auch nur selten 4 Slots hat. Wie schonmal gesagt, verlinkt und selbst geprüft: da geht mehr.
"In der Version, wo nach beenden der Ramdisk alles auf Platte geschrieben wird ist" ...dein gepriesenes Browseerlebnis langsamer, btw. jedes mal ein "Kaltstart".
Woraus besteht denn diese Schonung? Lesezugriffe auf eine SSD sind doch absolut unproblematisch, Schreibzugriffe sind es, die du nicht haben willst. Bei einem Cache, vor allem wenn du ihn nicht stark in der Größe limitierst, überwiegen die Lesezugriffe deutlich und die Schreibzugriffe sind in der Minderheit. Ich weiß nicht welchen Browser du benutzt, aber in Firefox gibt es about:cache, wo dir alle Einträge des Caches gelistet werden. Wenn du dir hier die Zahl der Spalte "Fetch" anschaust, hast du die Anzahl an Lesezugriffen pro einem Schreibvorgang. Bei mir stehen hier dreistellige Werte, sogar ein paar vierstellige.
Hast du eigentlich mal Tests gemacht, bevor du hier mit großer Schonung und vor allem
flanierst?
Da es mich selbst interessierte, war ich mal so frei. Sollte es irgendein Problem mit dem Testaufbau, dessen Durchführung, oder meiner Interpretation geben, bitte ich um Aufklärung. Bin kein Webdeveloper.
Zwei Seiten: "" und "[noparse]https://www.google.de" (Bildersuche, Suchwort "cache", Safe Search deaktiviert).
In den folgenden Konfigurationen: leerer Cache, Cache auf RAM Disk, Cache auf HDD.
Durchgeführt mit: Firefox 27.0.1 (Selfmanaged Cache ohne Begrenzung, 12 max pers. connections/server, 64 max pers. connections/proxy, 512 max connections) auf 10.9.1.
Vor jedem Test wurde der Cache gelöscht, im Falle der Tests mit nicht-leerem Cache ging ein initialer Aufruf der Seite voraus (um diesen zu füllen).
Vorweg der about:cache Auszug der "Cache auf RAM Disk" Tests:
Man beachte den Pfad des Caches.
Man sieht in der "Size" Spalte sehr schön, dass für jedes angefragte Element Daten vom Server übertragen wurden. Unten rechts ist eine Zusammenfassung: die insgesamt Anzahl an Anfragen an den Server, die insg. Menge übertragener Daten sowie die akkumulierte Zeit. Wichtig ist anzumerken: der Bildaufbau findet bei modernen Browsern schon vor dem Ablauf dieser Zeit statt, nachträglich erhaltene Elemente werden dabei auch erst später in die Darstellung eingefügt. Daher "springt" eine Seite, bzw. deren Inhalt, beim Aufbau oft ein wenig.
Auch wichtig: die Hauptanfrage (ganz oben), die notwendig ist, damit der Browser überhaupt erst "weiß", welche Elemente er überhaupt laden muss, benötigt den eindeutigen Großteil dieser Zeit. Dieser ist durch den Cache so nicht ersetzbar, sofern die Seite nicht statisch ist (das dürfte heutzutage kaum wo der Fall sein). Erst danach werden die Elemente geholt, die in diesem Test im Cache sein könnten, allerdings benötigt dies zum einen kaum Zeit, zum anderen findet das sehr parallel statt.
Diesmal sind die Daten schon im Cache. Wir sehen eindeutig: die lange "Hauptanfrage" bleibt so bestehen, die kleinen Fitzeldaten sind nun aus dem Cache geholt worden (ersichtlich am fehlenden Wert in der Spalte "Size"). Dies ließe sich auch durch den Statuscode in der Netconsole sehen, falls du es mal simpel bei dir selbst anschauen möchtest.
Was wir außerdem sehen (und das ist wichtig): die Zeit ist praktisch identisch. Nicht nur für die Fitzelteilchen, sondern auch die insg. Zeit. Das liegt daran, dass die "Hauptanfrage" relativ stark schwankt und im Vergleich zu dieser die kleine Anfragen einfach keine Relevanz haben.
Ich spare mir bei den letzten drei Bildern die Kommentare, denn sie sind die selben wie auch bei denen darüber. Der Grund für diesen weiteren Testlauf mit Google lag in den Cachedaten von MU, welche sehr klein sind. Darum noch der selbe Test mit google images, wodurch deutlich mehr übertragene Daten aus dem Cache kommen und dieser entsprechend eine größere Relevanz bekommt. Das sieht man an den Zahlen: die gecachte Datenmenge im Google Test ist rund 5x so groß wie die aus dem MU Test, das Ergebnis ist aber das gleiche.
Weshalb ist das so?
Wenn du dir nochmal die Bilder ansiehst, dann bemerkst du in den Zeitbalken eine graue und weiße Komponente*. Die graue Komponente ist die Zeit, die dein Browser mit Warten auf eine Antwort vom Server verbringt, während die weiße der tatsächlichen Datenübertragung entspricht. Du siehst auch bei all den Daten, die aus dem Cache genommen werden, eine starke graue Komponente, während die weiße (bei Nutzung des Caches) praktisch entfällt. Der graue Teil wirkt einfach zeitbestimmend. Du beschleunigst mit der RAM Disk die "weiße Komponente", die aber nur einen kleinen Teil in der Dauer zum Seitenaufbau einnimmt. Dieser ist so klein, dass er von den starken Schwankungen der "Hauptanfrage" gefressen wird.
Das heißt nicht, dass es keine Beispiele gibt, in denen die weiße Komponente überwiegt. Es gibt sie. Wenn ich z.B. in einem vB Forum auf einem langsamen Server, in dem ich bin, mir auf einer Seite alle 5000 Vorschlagsbenutzerbilder auf einmal anzeigen lasse, dann merkt man den Unterschied zwischen "Cache" und "kein Cache". Nur, wie oft passiert das? Ich persönlich kenne neben dieser einen Situation nur noch eine weitere, ähnliche. Dies sind gewiss keine Allerweltssituationen und ich behaupte, beim "normalen Surfen" triffst du auch auf keine.
* In Wirklichkeit gibt es mehr, diese sind aber so klein, dass hier nicht sichtbar.
cifera
Aktives Mitglied
- Dabei seit
- 22.05.2009
- Beiträge
- 5.104
- Reaktionspunkte
- 488
Zu SATA muss man wissen, dass die Daten mit der 10b8b-Kodierung kodiert sind, es werden also auf 10 Bit 8 Bit Nutzdaten übertragen. Daraus ergibt sich der 20% Overhead und macht aus 6 GBit/s glatte 600 MB/s.
Kaito
Aktives Mitglied
- Dabei seit
- 31.12.2005
- Beiträge
- 7.093
- Reaktionspunkte
- 1.844
Man kann sich hier scheinbar nur im ersten Post eines Threads bedanken, daher: danke für die Info.
wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
ich lagere den cache der Broswer jetzt seid über 3 Jahren aus, seid ich SSD`s benutze (erst unter linux Ubuntu und seid letzten Sommer auch unter OSX).
Allerdings hatte ich das bisher nur mit fireFox und Iron hin bekommen.
Und Geschwindigkeit, probiert es einfach aus, dann werdet ihr den Unterschied bemerken. Die Rechen Beispiele die ihr liefert, sind eher graue Theorie wo man sich in etwa Orientieren kann mehr aber auch nicht.
Allerdings hatte ich das bisher nur mit fireFox und Iron hin bekommen.
Und Geschwindigkeit, probiert es einfach aus, dann werdet ihr den Unterschied bemerken. Die Rechen Beispiele die ihr liefert, sind eher graue Theorie wo man sich in etwa Orientieren kann mehr aber auch nicht.
Kaito
Aktives Mitglied
- Dabei seit
- 31.12.2005
- Beiträge
- 7.093
- Reaktionspunkte
- 1.844
Der der Test war doch eben nicht "gerechnet", sondern die normale Nutzung von Macuser.de und Google Images (als eine Seite mit schwerem "Dateninhalt"). Naja, wie dem auch sei.
Mein FF Cache befindet sich übrigens in ~/Library/Application Support/Firefox/Profiles/..., sofern das bei dir auch so ist, willst du ggf. das von dir verlinkte Skript abändern, dann dieses verlegt den FF Cache dann nicht in die RAM Disk sondern belässt ihn lokal.
Mein FF Cache befindet sich übrigens in ~/Library/Application Support/Firefox/Profiles/..., sofern das bei dir auch so ist, willst du ggf. das von dir verlinkte Skript abändern, dann dieses verlegt den FF Cache dann nicht in die RAM Disk sondern belässt ihn lokal.
WirbelFCM
Aktives Mitglied
- Dabei seit
- 24.01.2008
- Beiträge
- 7.337
- Reaktionspunkte
- 819
Dann war keine Ram-Disk, sondern eine RAD-Disk
Jap! Das waren noch Zeiten am A500 mit 1MB RAM, wenn man immer zwischen RAM-und RAD-Disk jedes einzelne Byte abgewogen hat, damit das System noch genug RAM zum Arbeiten hatte
Ein A500 mit der Workbench auf der RAD: startete in etwa 5-7 Sekunden, da könnte sich so manches System heute mal 'ne Scheibe abschneiden
wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
Der firefox cache liegt bei mir schon lange in der Ramdisk, geändert über
About:config
browser.cache.disk.parent_directory (dort den string ändern) /Volumes/Ram/firefox
Bei mir heisst das im Skript, nicht RamDisk, sondern nur Ram. Für den Iron Browser habe ich ein Apple Skript, was ebenfalls den Cache zum Volume Ram legt.
WirbelFCM
Aktives Mitglied
- Dabei seit
- 24.01.2008
- Beiträge
- 7.337
- Reaktionspunkte
- 819
Das funktioniert bei mir genau so wenig wie der "Umweg" mit einem Alias - FF erkennt das entsprechende Verzecihnis einfach nicht an und moniert ein fehlendes "Profil"
Kaito
Aktives Mitglied
- Dabei seit
- 31.12.2005
- Beiträge
- 7.093
- Reaktionspunkte
- 1.844
Du sollst auch nicht dein ganzes Profil verschieben, sondern nur den Cache darin. Die obige Einstellung gibt nur den Pfad zum Cache, nicht zum Profil, vor. Für meine Tests hatte ich auch diese Einstellung genutzt und das tat soweit. Am besten bei jeder Änderung hieran den FF neu starten.
Übrigens besitzt FF eine "interne" Funktion, den Cache im RAM zu haben, ganz ohne die Erstellung einer RAM Disk. Diese ist allerdings schon etwas älter und hat bei mir nicht funktioniert, darum nannte ich es nicht.
Die obige Einstellung gibt nur den Pfad zum Cache, nicht zum Profil, vor. Für meine Tests hatte ich auch diese Einstellung genutzt und das tat soweit. Am besten bei jeder Änderung hieran den FF neu starten.Übrigens besitzt FF eine "interne" Funktion, den Cache im RAM zu haben, ganz ohne die Erstellung einer RAM Disk. Diese ist allerdings schon etwas älter und hat bei mir nicht funktioniert, darum nannte ich es nicht.
WirbelFCM
Aktives Mitglied
- Dabei seit
- 24.01.2008
- Beiträge
- 7.337
- Reaktionspunkte
- 819
Hmmmm....
Ich bin ja jedenfalls mal gespannt, wenn der erste findige Mac-User auf die Idee kommt, ein FusionDrive aus RAMdrive und SSD basteln zu wollen
Ich bin ja jedenfalls mal gespannt, wenn der erste findige Mac-User auf die Idee kommt, ein FusionDrive aus RAMdrive und SSD basteln zu wollen
darkdiver
Aktives Mitglied
- Dabei seit
- 25.10.2007
- Beiträge
- 255
- Reaktionspunkte
- 30
wir sind uns aber schon darin einig, dass der RAM schneller ist als eine SSD oder?
wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
Sonst wäre ich nicht auf die Idee gekommen, die an zu legen.
Difool
MU Team
- Dabei seit
- 18.03.2004
- Beiträge
- 20.429
- Reaktionspunkte
- 15.786
Richtig übrigens – ist ja der Tutorial-Bereich, und in diesem ist eine Diskussion, wenn, als hilfreiches Begleitwerk gedacht.Man kann sich hier scheinbar nur im ersten Post eines Threads bedanken, daher: danke für die Info.
Ansonsten sollen hier ja die Tutorials selbst im Fokus stehen – und die beginnen halt im Startbeitrag.
S
Schnapfel
Aktives Mitglied
- Dabei seit
- 30.05.2008
- Beiträge
- 2.055
- Reaktionspunkte
- 147
Als StarCraft 2 noch nicht so groß war habe ich das komplett in die Ramdisk gepackt. Ohne Campaign Ordner waren das nur 6 GB, under iMac hat 16 GB. Leider geht das jetzt nicht mehr. StarCraft will jetzt immer komplett sein, sonst läd es fehlende Teile online nach.
XSkater
Aktives Mitglied
Thread Starter
- Dabei seit
- 15.03.2012
- Beiträge
- 1.876
- Reaktionspunkte
- 150
Hmmmm....
Ich bin ja jedenfalls mal gespannt, wenn der erste findige Mac-User auf die Idee kommt, ein FusionDrive aus RAMdrive und SSD basteln zu wollen
Hehe. :d
wiefra3
Aktives Mitglied
- Dabei seit
- 11.04.2004
- Beiträge
- 1.472
- Reaktionspunkte
- 495
Wenn der Imac 32 GB hat sollte das reichen ?Als StarCraft 2 noch nicht so groß war habe ich das komplett in die Ramdisk gepackt. Ohne Campaign Ordner waren das nur 6 GB, under iMac hat 16 GB. Leider geht das jetzt nicht mehr. StarCraft will jetzt immer komplett sein, sonst läd es fehlende Teile online nach.
S
Schnapfel
Aktives Mitglied
- Dabei seit
- 30.05.2008
- Beiträge
- 2.055
- Reaktionspunkte
- 147
Ja, schon, aber was mache ich, wenn Blizzard das Spiel noch mehr aufbläht?