preformance Problem

[ghostgambler]

Original geschrieben von web4free
Mir hat mal Jemand gesagt bei PHP würde es in Summe schon viel ausmachen, wenn Du statt " ein ' verwendest. Wußte ich halt nicht, hat mir damals auch noch nie jemand gesagt. Ich habs dann auf der PHP.net auch gelesen warum das so ist. Man lernt ja nie aus und erweitert so seinen Horizont.

Äh ... nein, so pauschal kann man das auch nicht sagen.
Zwischen " können Variablen stehen und die werden automatisch ausgegeben:

$test = "blubb";
echo "hier ist $test";
/*
Ergibt
hier ist blubb
und ist langsamer als
*/
echo 'hier ist $test';
/*
Ergibt
hier ist $test
*/

/*
Das wiederum aber ist von der Ausführung her zeitlich identisch
*/
echo "test";
echo 'test';

/*
genauso wie
*/
echo "bla" . $test;
echo 'bla' . $test; 

Bei MYSQ ist das genau so??? Jetzt kratz mir da aber mal wer den Buckel!
Das hätte ich aber nicht gedacht! OK, das ließe sich ja relativ leicht machen, weils ja eh pro Importeur - sind nur 6 - je 2 Zeilen zum Anpassen wäre.

Teilt diese Meinung sonst noch wer??

Äh ... asp2php sprach davon die Anführungszeichen wegzulassen nicht die einfachen durch doppelte zu ersetzen!

[web4free]

Original geschrieben von asp2php
Ähm... was hat denn das nun mit PHP zu tun ... ich denke, du brauchst 'ne Pause ... weit wann akzeptiert MySQL Stringliteral zwischen " (Gänsefüsschen) gepackt?

Nein so wars nicht gemeint. Es ist bei PHP der Parser der ' schneller verarbeitet als ".
Und bei MYSQ dürfte es scheinbar auch so sein.
So meinte ich es.

Das heißt ich könnte zumindest überall dort wo Zahlen stehen dieses ' weglassen.

Danke!!!!

[asp2php]

Original geschrieben von web4free
Das heißt ich könnte zumindest überall dort wo Zahlen stehen dieses ' weglassen.

Danke!!!!

Du könntest nicht nur, du sollst ... nein ... du musst, um die Performance zu verbessern. Arbeite gewissenhaft und übergebe Daten in richtigen Format an die DBMS, dann ist der Rest nur eine Frage des DBMS-Tunings und nicht mehr der Querys

[web4free]

Hier herrscht ja jetzt reges Interesse an dem Threat

So kurz zu Euch allen:

Dass ich in bei den Inserts und Updates bei Zahlen die ' weglassen soll hab ich schon kapiert! Da mach ich schon keine " - war vielleicht unklar ausgedrückt.

In PHP mit den Variablen kenn ich - das war mir eh klar!

Was mir eben nicht klar war ist das mit den ' in MYSQL.

Den Link wegen dem 'enum' werde ich mir gleich nach dem Essen reinziehen.

[asp2php]

Original geschrieben von web4free
Hier herrscht ja jetzt reges Interesse an dem Threat

Ja klar Selten so ein interessantes Thema wie hier gesehen. Wir haben sonst nur 08/15 Fragen, die sich täglich wiederholen

[TobiaZ]

OffTopic:

---

Na komm, leute die Ints als Strings behandeln haben wir auch fast jeden Tag. :P

---

[Wyveres]

Original geschrieben von TobiaZ

OffTopic:

---

Na komm, leute die Ints als Strings behandeln haben wir auch fast jeden Tag. :P

---

OffTopic:

---

Stimmt schon aber die haben dann aber auch 08/15 Frage und Aufgabestellungen.

das Hier ist mal was anderes.

---

@ghostgambler

OK gutes Argument! aber auf Dauer würde sich diese arbeitsweise in der DB last niederschlagen.

wenn man davon ausgeht das da irgendwann mal 100.000 datensätze und mehr drin stehen dann ist das in meinen augen eine riesige Mänge an Unnützen Daten

da sich mir der Sinn versperrt bleibt ungefähr 70.000 mal und mehr Volkswagen oder Toyota oder Ferrari in die DB zu schreiben.

es Bläht irgendwann die Tabelle extrem auf.
zudem kommt hinzu das es irgendwann sein könnte das er was an der Tabelle ändern muss. nix esenzielles nur irgend ein spaltenwert. und dadurch dummerweise aus irgendeinem Grund alle Daten Nirvana sind.
aber das ist Hypotetisch.

Am ende muss web4free selber entscheiden ober Normalisieren will oder nicht. Ich bin immernoch der meinung das es wenn richtig angestellt die Performance steigern wird.

(falls ich mich irren sollte beweist mir das Gegenteil)

[prego]

Ich hätte noch einen Tipp - allerdings nicht nachgeprüft.

Du hast ja sicherlich momentan MyISAM als Tabellentyp - ich habe bei manchen meiner Tabellen schon sehr große Performance Schübe durch das Umstellen auf InnoDB erreicht - vor allem bei vielen Usern auf der Kiste.
Der CommandScheduler von InnoDB kommt um einiges besser mit gleichzeitigen Lese- und Schreib-Operationen klar als MyIsam.

Das Lock kannste imo dann auch weg lassen.

Nichts desto trotz solltest du aber die Tabelle ordentlich Normalisieren und manche Sachen auslagern - allein schon der Ordnung halber. Wenn du aber dann für jede Abfrage wieder joinen musst hilfts dann auch nicht mehr viel, weil die Datenmenge dann wieder die selbe ist.

Vielleicht kannst du auch mit "vernünftiger" Primary Key Nutzung den Insert/Update vorgang optimieren. Stichwort INSERT ON DUPLICATE KEY UPDATE.

[web4free]

und da dachte ich schon, dass ich so ausgereift war in der Sache.
Pustekuchen.
Aber scheinbar isses Gesetz der Regel, dass solange sich nur ein paar Datensätze hinter einen Projekt verstecken das nicht so auffällt.

Bis letzte Woche hatten wir grad mal 50.000 Inserate in der Datenbank.
Dann hat sich ein neuen Importeur gemeldet der uns 100.000 zusätzliche Fahrzeuge bescheren wollte.
In summe sind das jeden Tag um 02:30h zwischen 800 und 900 ZIP-Files (KFZ-Händler) die ich von denen bekomme.
Im Durchschnitt hat jeder Händler zwischen 200 und 3.000 Fahrzeuge die so geinsertet bzw. upgedatet werden müssen.

Bis zum besagten Tag wo die Schnittstelle fertig war ist alles ganz normal gelaufen - und jetzt bekomme ich die Krise.
Habe aber gerade auch den Auftrag bekommen den lang ersehnten 2. Server zu bestellen, der dann das Abarbeiten der ZIP-Files und das Aufbereiten der Datensätze übernehmen soll
Dann bleibt nur noch der Batzen INSERT und UPDATE auf dem Hauptrechner und den werde ich jetzt nochmals modifizieren und die Werte richtig übergeben.

Statusbericht folgt auf alle Fälle.
Ich bin ja nur so dankbar, dass ich es dieses mal geschafft habe mit der richtigen Frage viele Hinweise zu bekommen um damit auch meine Nerven zu entlasten (und nicht nur die DB)

[Wyveres]

wer vernünftige Fragen stellt und sie auch noch gut Formuliert bekommt auch die richtigen tips und Hilfestellungen.



frei nach dem motto!

[COLOR=red]"geht nicht!"[/COLOR] ist keine korrekte Fehlerbeschreibung

[ghostgambler]

Es gibt Datenbank-Server die haben kein Problem damit ein paar mehr MB an Plattenplatz locker zu machen, die aber sehr wohl eine schwache CPU/schwachen RAM haben, wo es mehr Sinn macht die Daten zu denormalisieren um sich JOINs zu sparen

zudem kommt hinzu das es irgendwann sein könnte das er was an der Tabelle ändern muss. nix esenzielles nur irgend ein spaltenwert. und dadurch dummerweise aus irgendeinem Grund alle Daten Nirvana sind.
aber das ist Hypotetisch.

Hat auch absolut keine Bewandtnis als Argument bezüglich pro oder contra Normalisierung oO

Am ende muss web4free selber entscheiden ober Normalisieren will oder nicht. Ich bin immernoch der meinung das es wenn richtig angestellt die Performance steigern wird.

(falls ich mich irren sollte beweist mir das Gegenteil)

Mach halt eine Tabelle, deren Werte in 5 anderen Tabellen kleben und frag dann mit einem SELECT+4fachen JOIN alle Daten ab und vergleich das mit einem normalen SELECT ... der SELECT ist definitiv schneller


Guck mal ein bisschen bei DataWarehousing rum, da wird dieser Vorteil noch essentieller, siehe z.B.

http://www.dwoptimize.com/2007/05/lo...rallelism.html
We can do this by loading the 3 files into 3 separate tables and join the 3 tables together in the data profiling SQL query. If this join needs to happen several times for running multiple iterations of the data profiling report or for downstream data warehousing processes, it will be beneficial to store the data pre-joined in a single denormalized table structure.

[web4free]

Also dazu hab ich mir in so manchen Forum schon meine Gedanken gemacht.
Klar manches klingt ja babyleicht ist aber für den Betroffenen ein unüberwindbares Hindernis.
Was da dann aber für Schlagabtäusche von statten gehen graut jeder Sau (Sorry).

Und manches mal denke ich mir auch, man hätte von Beginn weg schon besser helfen können wenn man nicht gleich einfach nur eine URL zum Anschauen hinschreibt.

Aber es ist nun mal auch so dass "wie man in den Wald hineinruft, so schallt es wieder heraus"....

und jetzt muß ich was Arbeiten, damit meine DB ein bisschen Urlaub bekommt!

[ghostgambler]

Original geschrieben von prego
Ich hätte noch einen Tipp - allerdings nicht nachgeprüft.

Du hast ja sicherlich momentan MyISAM als Tabellentyp - ich habe bei manchen meiner Tabellen schon sehr große Performance Schübe durch das Umstellen auf InnoDB erreicht - vor allem bei vielen Usern auf der Kiste.
Der CommandScheduler von InnoDB kommt um einiges besser mit gleichzeitigen Lese- und Schreib-Operationen klar als MyIsam.

Naja, also innodb kann bei falscher Konfig auch sehr nach hinten los gehen...

Und an der Aufgabe uns für die alten Webserver eine adäquate innodb-Konfig zu erstellen sind selbst die Profis auf einer Tagung in München gescheitert, myisam hat die Last aber bis zuletzt gut bewältigt

[prego]

Hmm ghostgambler... da hast du sicher recht - innoDB ordentlich mit allen Werten zu confen ist nicht ohne.

Allerdings habe ich hier, natürlich mit InnoConfigTuning, einiges an Performance rausgeholt.

Es wird bei jedem zugriff eines Users ein Update in eine Tabelle gemacht - die selbe Tabelle wird aber auch bei jedem Zugriff gelesen, weil es die User-Tabelle ist. Zugegeben - der Ansatz ist nicht der bestet und last-activity von einem User zu speichern, aber es funktioniert tadellos.
Mit MyIsam konnte ich das ganze abhacken bei mehr als 200Leuten gleichzeitig auf der DB - die Selects haben sich nen Loch innen Bauch gewartet bis die Updates fertig waren.
Mit InnoDB und Kontrolle der queries/indieces und sloqQueryLog/Explain und natürlich entsprechender Config läuft das ganze ohne Problem mit mtwl über 50000 Usern am Tag.

[ghostgambler]

äh ja ... bei jedem Seitenaufruf ein Update ist sehr sehr aua oO;