| Author |
Message |
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
 Posted:
2009-07-03, 05:06 "notices" und Geschwindigkeitsproblem |
  |
Was genau sind diese "Notices" bei der Wiederherstellung?
Quote: 76 min. 39 sec, 316 pages , 498 notice
Noch eine Frage:
Wir portieren gerade ein Kundenprojekt auf einen neuen Server und der ist jetzt schon über ne Stunde am rödeln und erst bei bei 12% die DB ist gerade mal 760MB.
Ich hatte mir vor einiger Zeit mal die Videos mal angeschaut und irgendwie hatte ich das Gefühl, dass das Ganze dort wesentlich schneller geht. Der Server ist neu eingerichtet (4GB RAM Doppel-CPU-Maschine) und es läuft im Prinzip noch nix drauf, deswegen glaube ich nicht, dass es an der Performance liegt.
In den Einstellungen habe ich diese automatische Erkennung benutzt (was auch immer die macht) und den Speed auf 500 hochgesetzt.
Liegt das daran, dass die Dateien gezippt sind? Sollte ich das besser deaktivieren?
Mit bigdump.php hatte ich eine 1200 MB DB in einer halben Stunde oben (allerdings mit Stress bei den Umlauten).
Gruß, Dave
|
|
     |
|
Anzeigen
|
|
Posted:
Anzeigen |
|
|
| |
|
DSB
Developer
Age: 40
Joined: 30 Apr 2004
Posts: 15831
Location: Reichenberg bei Würzburg
|
|
Posted:
2009-07-03, 10:03 Re: "notices" und Geschwindigkeitsproblem |
|
« Dave » wrote: Was genau sind diese "Notices" bei der Wiederherstellung?
Notice = Hinweis
Hinweise, wie z.B. duplicate entries, werden in das error-log des Dumpers geschrieben. Dies kannst Du Dir auch während des laufenden Prozesses in einer zweiten Instanz des Dumpers ansehen.
Quote: Ich hatte mir vor einiger Zeit mal die Videos mal angeschaut und irgendwie hatte ich das Gefühl, dass das Ganze dort wesentlich schneller geht.
Das waren auch weniger Daten. Je mehr Daten umso länger dauert es natürlich. Bei 760 MB am Stück wäre es jetzt schneller gegangen, wenn Du beim Sichern Multipart benutzt hättest udn zum Beispiel 10 MB-Parts vom Dumper hättest erstellen lassen.
Bei einer großen Datei dauert das Setzen des Dateizeigers an die aktuelle Stelle immer länger, je weiter hinten der Zeiger ist.
Quote: In den Einstellungen habe ich diese automatische Erkennung benutzt (was auch immer die macht) und den Speed auf 500 hochgesetzt.
Wenn Du das Vieo gesehen hast, solltest Du wissen, was die Einstellung "automatisch erkennen" macht und auch wie sich die Geschwindigkeitsparameter auswirken.
Quote: Mit bigdump.php hatte ich eine 1200 MB DB in einer halben Stunde oben (allerdings mit Stress bei den Umlauten).
bigdump hat einen wesentlich einfacheren Parser und ist dadurch schneller.
MySQLDumper fängt viel mehr Fälle ab und ist dafür sicherer und einfacher in der Anwendung. Der Preis dafür ist, dass er etwas langesamer ist.
_________________
Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
 |
|
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
|
Posted:
2009-07-03, 13:37 (No subject) |
|
Quote: MySQLDumper fängt viel mehr Fälle ab und ist dafür sicherer und einfacher in der Anwendung.
Vielleicht könnte man das ja als Parameter einstellbar machen  . Der einzige Nachteil den bigdump hat ist, dass man damit keine Dumps erstellen kann.
Quote: Der Preis dafür ist, dass er etwas langesamer ist.
Der Preis ist zu hoch... Das liegt bei großen Dateien etwa bei Faktor 20. Das hat mich heute eine Menge Zeit und nerven gekostet... Ich bin in Neuseeland (weiß übrigens durchaus, was "Notice" auf deutsch heißt ) und der Server in Deutschland da bricht immer mal wieder die Verbindung ab und ich musste das Script neustarten.
Die 50MB-DB hat letztlich zwei Stunden gebraucht (bigdump macht das in einer halben Minute) bei der 750MB-DB habe ich es irgendwann mit MSD frustriert aufgegeben.
Die Logik, dass es mit Multipart schneller geht, war für mich nicht ersichtlich, abgesehen davon hilft mir das bei einem bestehenden Backup recht wenig.
Wie schon an anderer Stelle gesagt: MSD ist echt ein echt geiles Script, was mich ziemlich begeistert hat (und es nach wie vor tut), es hat auch echt das Zeug zu einem Tool, nach dem sich professionelle Anwender die Finger lecken, aber so leid es mir tut, Usability-mäßig ist das nicht so der große Renner.
Denn gerade bei professionellen Projekten ist eben Geschwindigkeit der entscheidende Faktor. 750MB ist ja für 'ne DB nicht gerade sooo übermäßig groß.
Ich würde da echt gerne bei helfen, könnte mir auch vorstellen da Zeit zu investieren, nur kommt man mit der Einstellung, dass sich die User dem Script anpassen müssen eben nicht weiter.
Gruß, Dave
|
|
| |
|
DSB
Developer
Age: 40
Joined: 30 Apr 2004
Posts: 15831
Location: Reichenberg bei Würzburg
|
|
Posted:
2009-07-03, 14:47 (No subject) |
|
« Dave » wrote: Der einzige Nachteil den bigdump hat ist, dass man damit keine Dumps erstellen kann.
Vergleiche den Code beim Importieren von bigdump und MySQLDumper (beides ist ja Open Source) und Du wirst eine ganze Menge weiterer Unterschiede feststellen.
Quote: Der Preis ist zu hoch...
Das mag Deine Ansicht sein. Die Masse der User, die MSD erfolgreich einsetzen, lieben ihn gerade wegen der einfachen Bedienung und vor allem weil Backup und Restore problemlos funktionieren. Wenn der Super-Gau eintritt und man ein Backup einspielen muss (was man übrigens auch per Konsolen mysqldump tun kann; MSD erstellt valide Backups), kommt es darauf an, dass das Backup zuverlässig eingespielt wird und man die Kontrolle über den Prozess behält.
Wenn es per bigdump nicht funktioniert (und das Backup muss entsprechende Voraussetzungen erfüllen, damit das klappt), dann vergeht wesentlich mehr Zeit mit der Fehlersuche. Für den Otto-Normal-Verbraucher, der im Fehlerfall aufgeschmissen ist, da er sich mit SQL nicht auskennt, ist es in dem Fall einfacher MySQLDumper zu nutzen.
Verstehe mich nicht falsch, ich will bigdump keinesfalls schlecht reden. Es gibt viele Wege um nach Rom zu kommen und jedes Skript hat seinen Anwendungszweck und seine Daseinsberechtigung.
Quote: Die Logik, dass es mit Multipart schneller geht, war für mich nicht ersichtlich, abgesehen davon hilft mir das bei einem bestehenden Backup recht wenig.
Ich habe mir die Mühe gemacht, Dir eine technische Erklärung zu geben, die schlüssig ist. Wenn ich jetzt Deine Antwort lese, ärgere ich mich, dass ich überhaupt Zeit in eine Antwort investiert habe.
Du könntest zum einen auf die Idee kommen ein erneutes Backup mit Multipart vom Quellserver zu ziehen oder das Backup zuerst in einen lokalen Testserver einzuspielen und anschließend ein neues Backup mit MP machen.
Quote: Usability-mäßig ist das nicht so der große Renner.
Das kann ich nicht bestätigen - im Gegenteil.
Quote: nur kommt man mit der Einstellung, dass sich die User dem Script anpassen müssen eben nicht weiter.
Woher nimmst Du die Vermutung, dass ich diese Einstellung habe?
Wenn Du Dir das Changelog im SVN anguckst wirst Du sehen, dass ich alleine in den letzten 4 Wochen fast meine gesamte Freizeit in die Weiterentwicklug des Dumpers gesteckt habe - und das nicht, weil ich selbst Erweiterungen brauche!
Dabei habe ich nahezu alle Anregungen aus dem Forum umgesetzt und immer auf jede Wortmeldung hier im Forum reagiert. Deine Ausasge ist für mich ein Schlag ins Gesicht! Wenn es Dein Ziel war mich zu demotivieren, dann möchte ich Dich beglückwünschen. Das hast Du richtig gut geschafft. 
_________________
Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
| |
|
Dave
uses MSD regulary
Joined: 01 May 2009
Posts: 24
|
|
Posted:
2009-07-04, 08:51 (No subject) |
|
Es geht mir hier einfach wo wie bei fast jedem Open Source Projekt, bei dem man Probleme meldet: Dass die Entwickler hier mit einer gewissen Arroganz rangehen.
Wenn die Benutzer das Produkt nicht soooo supertoll finden, wie der Entwickler, liegt das dann meistens an den dummen Benutzern die sich einfach erdreisten, andere Anforderungen zu haben...
Da ist die Sache mit dem Save-Button ein gutes Beispiel für. Ich denke 99% aller Webentwickler (und Webnutzer) werden Dir bestätigen können, dass ein Save-Button UNTER das Formular gehört und nichts in einem Menü zu suchen hat.
Wenn ich Dir dann den Tipp gebe, das entsprechend zu ändern (zumal es einer anderen Person hier im Forum ähnlich erging) dann mache ich das nicht weil mir das Produkt egal ist und ich es bescheuert finde, sondern weil ich es gut finde und gerne weiternutzen will.
Und ich kenne einige echt gute Open Source Projekte die genau an DEM Punkt gescheitert sind. Sie haben Dinge am Benutzer vorbei-entwickelt. Sie haben dafür immer einen riesen Katalog an Gründen (nach dem Motto "hey das doch praktisch wenn man im Menü einen Save Button hat"), aber es war nicht das was die Benutzer gebraucht haben.
MSD hat das Zeug zu einem Tool nach dem sich jeder Web-Entwickler die Finger lecken wird, zu einem Tool von dem Du als Entwickler evtl sogar leben kannst. Aber dazu fehlen nunmal einige essentielle Dinge - essentielle Dinge für die ICH jedenfalls bereit wäre zu zahlen.
Als Agentur braucht man Dumps eben NICHT nur für den Worstcase, sondern sie gehören zur täglichen Arbeit dazu, wenn man Projekte vom Testserver ins Livesystem umziehen muss. Und das Problem sind nunmal nicht Datenbanken mit 20MB sondern Datenbanken >1000MB. Und da 12 Stunden zu warten kostet Zeit und Geld.
Es hängt davon ab wo Du hin willst. Willst Du ein Tool haben mit dem der Hobbyschrauber ein Backup von seinem Forum mit einer Handvoll User machen kann, das er wieder einspielen kann, wenn er sich den Server zerschossen hat, oder willst Du ein Tool, das auch professionellen Ansprüchen genügt...
Niemand erwartet, dass Du, sobald jemand ein Problem meldet am gleichen Abend hinsetzt und das fixt. Aber es ist auch extrem frustrierend, wenn man nur als Antwort kriegt, dass man im Prinzip zu blöd für dieses wunderbare Tool ist, weil man es nicht so eingesetzt hat wie der Entwickler sich das gedacht hat.
Das ist nämlich AUCH demotivierend. Dass ich hier Verbesserungsvorschläge poste mache ich nämlich AUCH in meiner Freizeit.
Gruß, Dave
|
|
| |
|
DSB
Developer
Age: 40
Joined: 30 Apr 2004
Posts: 15831
Location: Reichenberg bei Würzburg
|
|
Posted:
2009-07-04, 09:21 (No subject) |
|
Ok, jetzt kommen wir uns langsam näher.
Jetzt vermischen wir die beiden Threads zwar etwas, aber egal. Ich will das hier mal auf den Punkt bringen.
Grundsätzlich bin ich sowohl für jedes Feedback dankbar und überdenke jeden, wirklich jeden Verbesserungsvorschlag sehr genau. Gerade MySQLDumper lebt vom unmittelbaren Gespräch mit dem Anwender und ich kenne kaum ein Projekt, wo es so schnell Feedback vom Entwickler gibt und wo so viele Anregungen in das Projekt mit eingeflossen sind.
Du hast Dich über 2 Dinge ausgelassen;:
1. die Einrichtung eines neuen Konfigurationsprofils
Ja, da gebe ich Dir Recht - das könnte man noch optimieren. Dieses Feature ist aber erst seit Version 1.23 integriert und so läst sich Dein Vorschlag - bei Anlage eines neuen Profils noch einmal den Installationsassistenten aufzurufen - nicht ohne erheblichen Aufwand umsetzen, da der Installationsassistent vom Konzept mehrerer Konfigurationsdateien nichts "weiß".
Ich befinde mich gerade kurz vor der Veröffentlichung der Version 1.24 release candidate, habe dafür in den letzten Wochen unendlich viele Bugs gefixt und zum Teil strukturelle Anpassungen vorgenommen. Zu diesem Zeitpunkt will ich eine so große Veränderung nicht vornehmen, da das den Release-Termin ziemlich nach hinten schieben würde. Das hätte ich vielleicht dazu sagen sollen.
2. die Positionierung des "Speichern"-Buttons
Ich habe Dir meine Meinung dazu gesagt und Du bist anderer Meinung. Allerdings hast Du Deinen Verbesserungsvorschlag ziemlich provokativ verpackt. Das Du anschließend aus dieser Kleinigkeit ableitest, dass dieses Projekt nicht auf den Anwender einginge, entspricht einfach nicht den Tatsachen und hat mich schlichtweg ziemlich geärgert.
Nachdem ich nun eine Nacht darüber geschlafen habe, würde ich es sachlich betrachtet für einen sinnvollen Kompromiss halten, wenn unter jedem Konfigurationsabschnitt zusätzlich im Formular ein "speichern"-Button platziert wäre. Dann müssten alle Bedürfnisse befriedigt sein.
Quote: Dass die Entwickler hier mit einer gewissen Arroganz rangehen.
Wenn die Benutzer das Produkt nicht soooo supertoll finden, wie der Entwickler, liegt das dann meistens an den dummen Benutzern die sich einfach erdreisten, andere Anforderungen zu haben...
Das kann ich selbst natürlich nicht objektiv beurteilen. Ich bin jedoch stets bemüht auf einer sachlichen Ebene zu agieren.
Übrigens gehe ich gerade der Frage nach, wie man den Wiederherstellungsprozess noch beschleunigen kann und versuche momentan langsame Schwachstellen zu identifizieren. Du siehst also, dass auch dieser Einwand von Dir als Anwender von mir geprüft wird.
_________________
Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
| |
|
DSB
Developer
Age: 40
Joined: 30 Apr 2004
Posts: 15831
Location: Reichenberg bei Würzburg
|
|
Posted:
2009-07-04, 15:52 (No subject) |
|
Kraft meiner Arroganz habe ich den, von mir selbst für gut befundenen Kompromiss mit Revisioin 491 umgesetzt.
Unter jeder Abteilung findet sich nun zusätzlich ein "speichern"-Button.
zusätzlich habe ich die Buttons "Zurücksetzen", "Installationl" und "alle Parameter" entfernt, da diese mehr verwirren als helfen.
Wiederherstellung und Sicherung habe ich in den Revisionen davor etwas beschleunigen können. Die automatische Geschwindigkeitsanpassung rechnet nun bis zum Erreichen der Hälfte der maximalen Ausführungszeit beinahe 100% dazu und erst danach in 10%-Schritten weiter.
Dadurch kommt der Dumper eher "in die Hufe" und ist schneller am Maximallimit, ohne die gewohnte Sicherheit zu verlieren.
_________________
Gruß / Greetings, DSB
Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.
|
|
| |
|
|
|
CrackerTracker © 2004 - 2012 CBACK.de
Powered by Orion based on phpBB
© 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours
phpBB SEO
|
