Richtig/ sauber PHP coden
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
array
ausgabe
beispiel
benutzer
code
datum
erstellen
frage
machen
nutzer
paar
part
performance
problem
session
speichern
stehen
tabelle
umfrage
verwenden
-
du könntest sogar (wie es eig richtig ist)
echo($var);
schreiben
Beitrag zuletzt geändert: 23.6.2009 12:11:18 von jg54 -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Echo ist keine Funktion sondern ein Sprachkonstrukt und somit sind die Klammern überflüssig.
-
Mh, ich glaub meine Frage fliegt etwas raus, aber ich stelle sie trozdem mal:
Ich schreibe zurzeit etwas in PHP, weil ich mir son Paar Dinge vereinfachen will und benötige dazu zurzeit ne Menge Datenbankzugriffe. Nun arbeite ich zwar viel mit Arrays bzw. lasse die Daten bereits von MySQL nach bestimmten Kriterien sortieren, aber verwende auch gerne mal functions, die einen Query ausführen a lâ:
GetUserByID($id);
Nun müssen solche Querys mitunter mehrfach pro Seite ausgeführt werden und ich frage mal nach, wie sehr sich das in der Performance macht, wenn man anstatt z.b. eine Abfrage zu formulieren die 15 Strings zurückgibt, diese einzel rauszufischen und auszugeben, einfach 15 Queries macht.
Leider habe ich keine Hardware mehr, auf der ich einen Unterschied zwischen beiden Formen merken könnte, vielleicht kennt ja wer von euch ne Antwort, ob das wirklich viel Ausmacht, vorallem wenn aus Faulheit diese Querys dann auf 30 oder mehr wachsen... -
Na grundsätzlich erhöht doch jede Anfrage an den Datenbankserver die Ausführungsdauer des Scriptes.
Hast du ein konkretes Beispiel für die GetUserByID() Anweisungen? Eventuell kannst du die auch per Ajax nachladen lassen?! -
Nun, natürlich ist es langsamer. Wie langsam musst du testen.
Dafür gebe ich dir mal die MySQL-Funktion BENCHMARK() auf den Weg. Funktioniert wie folgt:
BENCHMARK(10000, SELECT * FROM bla WHERE id = blabla);
Dabei ist 10000 die Anzahl der Ausführungen. -
Nikic, das ist aber sehr syntetisch. Nach der ersten Ausführung ist der Query im MySQL Cache und von daher ist eine einzelne Abfrage immer schnell, auch wenn man sie 10.000 mal ausführt.
-
evil-devil schrieb:
Nikic, das ist aber sehr syntetisch. Nach der ersten Ausführung ist der Query im MySQL Cache und von daher ist eine einzelne Abfrage immer schnell, auch wenn man sie 10.000 mal ausführt.
Naja, dann ersetz halt das id = blablabla durch id = RAND()
Aber das manipuliert die Ergebnisse, da rand() langsam ist. Dann musst du das auch in deiner großen Abfrage via rand() machen ;) -
Ist meiner Meinung nach trotzdem zu syntetisch. Sobald er Indexes gesetzt hat würde das auch rennen ohne Ende. Wir brauchen ein Fallbeispiel, da wir hier sonst endlos (sinnfreie) Tipps geben könnten ;)
-
Also die Usernamen bzw hier Fragen sind natürlich Indexiert. Also per feste ID, Unique und eben auto-increment.
Es geht jetzt z.B. um ein Umfragescript, das 10 Fragen/Seite ausgibt. Dazu wird 10 * die function "foo($id)" genutzt, der in diesem Beispiel nun einfach ein "Select frage_txt where id = $id limit 1;" ausführt und das ganze ergebnis zurückgibt.
Nun könnte man aber ja auch eine mehrfache Abfrage machen, die alle IDs von 1 bis 10 liefert und diese dann zerpflückten, in einem Array speichern und dann wieder ausgeben.
Die Frage ist nun, was ist rein Sprachlich besser, da würde ich zum ersten tendieren, und was ist von reinen Performance Aspekten her besser?
Mein C3-Router/Testserver und selbst der gammel PIII lassen da haufenweise Queries in Millisekunden durchflutschen, sodass es scheinbar keinen Unterschied mehr macht, was man nun nimmt.
Solange eben das Datenbankobjekt global deklariert ist und aus der Function genutzt wird... -
Wieso fragst du nicht einfach nur die Fragen ab die auf Seite X stehen sollen? Oder wie weiß eine Frage das sie auf Seite 2 steht und nicht auf Seite 4?
Beitrag zuletzt geändert: 24.6.2009 0:12:17 von evil-devil -
evil-devil schrieb:
Wieso fragst du nicht einfach nur die Fragen ab die auf Seite X stehen sollen? Oder wie weiß eine Frage das sie auf Seite 2 steht und nicht auf Seite 4?
Ganz einfach: Ich habe 25 IDs und 25 Fragen und 10Fragen/Seite und auf der letzten 5. Die IDs werden nicht verändert, nur eben deren andere Inhalte, in dem Fall bleiben also auf ID1 bis 10 immer die Fragen, die auf die erste Seite kommen, in ID11 bis 20 die der zweiten usw usf.
Nur sind es eben, durch die Function die 10mal ausgeführt wird auch 10 Querys, die ausgeführt werden und ich wollte wissen, inwiefern denn die Methode, ein Query daraus zu machen und ein Array-Objekt zu übergeben, was dann wieder zerteilt und ausgegeben wird, besser sprich schneller ist...
Also quasie statt:
printheader()
printquestion(1)
printquestion(2)
[...]
Soetwas wie:
printheader()
$a = array()
$a = printquestion(1, 10)
for ($cnt =1 ..){
echo $a[$cnt]
}
Falls das jetzt irgendwie klar wird ^^
-
Ja, das war vorher schon klar. Aber das ändert nichts an dem schlechten Design.
Was du noch machen könntest wäre es per IN() Funktion abzufragen.
SELECT id, name, beschreibung, was_auch_immer FROM meine_fragen WHERE id IN (1,4,5,7,10)
Es wird auf jeden Fall schneller sein, wenn du nur eine anstatt 10 Anfragen stellst. Alternativ könntest du alle Fragen abholen und per den Krams herausselektieren lassen. Aber dann erzeugst du einen unnötigen Overhead.
Ich würde den Fragen eine Ordnung/Seite zuweisen und dann über selbige die Ausgabe steuern. -
Ich weiß nicht auf was diese Diskussion hinausläuft.
Natürlich ist es in einem Query schneller und natürlich ist es sprachlich besser.
Das einzige was fraglich sein könnte ist, ob es wirklich um so viel besser ist, dass es sich lohnnen würde es zu ändern.
Wenn du diese Umfrage nicht gerade großtechnisch mit 200 gleichzeitigen Abfragen über 24 Stunden hinweg duchführen willst, dann kann dir das eigentlich sehr egal sein.
Es ist villeicht stylistisch nicht unbedingt so schön, aber es merkt keiner und ich gehe davon aus, dass du kein Umfragesystem in einem Team von zwanzig Leuten programmierst, oder?
@evil-devil: Was zum Teufel soll daran synthetisch sein? Wenn man in zwei Abfragen genau die selben Hintergrundbedingungen hast, dann werden sie auch gleichwertig behandelt. Wenn du das Umfragescript nun in einem benchmark mit 10 Mio Abfragen durchführst oder du es auf nem Server mit nur einigen Abfragen pro Minuten läuft, ist doc hvöllig egal. Ja, es wird natürlich im Zwischenspeicher landen, im Praxiseinsatz jedoch auch. Also liefert das durchaus zuverlässige Vergleichswerte. Man kann damit natürlich die Geschwindigkeit nicht genau berechnen, aber es reicht normalerweise, wenn du nicht gerade die Abfragezeit auf die zwölfte Nachkommastelle genau haben möchtest! -
Warum mir das zu synthetisch ist? Weil der Test nur auf einem Benutzer basiert. Welche WebApp wird denn bitte von einem Nutzer zur Zeit beackert?
-
evil-devil schrieb:
Warum mir das zu synthetisch ist? Weil der Test nur auf einem Benutzer basiert. Welche WebApp wird denn bitte von einem Nutzer zur Zeit beackert?
Hm, nun, warum soll das so stark vom Benutzer abhängen? Ich weiß nicht wie diese Umfrage funktioniert, aber man wird doch wohl kaum eine eigene Tabelle für jeden Benutzer erstellen (DAS wäre ineffektiv).
Daher wird am Ende doch auf die SELBE Relation mit der SELBEN Abfrage zugegriffen. MySQL interessiert es absolut nicht, ob die Abfrage nun von 123.456.789.012 oder von 123.444.555.666 kommt, das interessiert PHP, MySQL jedoch nicht. -
Ja, wenn es denn bei einer Umfrage bleibt. Das wissen wir ja nicht ;)
Bin halt ein Performance Fetischist. -
Nene, nur ne kleine Umfrage, die ich binnen von nen paar Stunden eben selber zusammengebastelt hab.
(Mit Session-Login und so für nen bestimmten Teilnehmerkreis)
Aber mir gings da halt auch etwas ums Prinzip, da man Dinge, die man am Anfang lernt (Hab vorher so noch nicht wirklich was in PHP geschrieben in dem Umfang) so schnell ja auch nicht wieder ablegen kann.
aber man wird doch wohl kaum eine eigene Tabelle für jeden Benutzer erstellen (DAS wäre ineffektiv).
Doch, schon, die ist bereits vorher vorhanden, da die Benutzer schließlich eine Umfrage machen, daraus werden sie in Kategorien eingeteilt, dann Füllen sie ein Profil aus (resultierend aus der vorherigen Einschätzung) und am Ende werden dann die Umfragewerte gemittelt (wenn alle User das ausgefüllt haben) und die User nach Abweichung vom Durchschnitt nochmal sortiert, sowie die größten Abweichungen pro User auf einer Dynamisch erstellen Grafik mittels Piktogrammen dargestellt...
Dazu müssen die Daten aber persistent sein, also auch nach beendigung der Umfrage zur Verfgung stehen, denn der Mittelwert alleine ist nur die halbe Miete
-
erasmuz schrieb:
Nene, nur ne kleine Umfrage, die ich binnen von nen paar Stunden eben selber zusammengebastelt hab.
(Mit Session-Login und so für nen bestimmten Teilnehmerkreis)
Aber mir gings da halt auch etwas ums Prinzip, da man Dinge, die man am Anfang lernt (Hab vorher so noch nicht wirklich was in PHP geschrieben in dem Umfang) so schnell ja auch nicht wieder ablegen kann.
aber man wird doch wohl kaum eine eigene Tabelle für jeden Benutzer erstellen (DAS wäre ineffektiv).
Doch, schon, die ist bereits vorher vorhanden, da die Benutzer schließlich eine Umfrage machen, daraus werden sie in Kategorien eingeteilt, dann Füllen sie ein Profil aus (resultierend aus der vorherigen Einschätzung) und am Ende werden dann die Umfragewerte gemittelt (wenn alle User das ausgefüllt haben) und die User nach Abweichung vom Durchschnitt nochmal sortiert, sowie die größten Abweichungen pro User auf einer Dynamisch erstellen Grafik mittels Piktogrammen dargestellt...
Dazu müssen die Daten aber persistent sein, also auch nach beendigung der Umfrage zur Verfgung stehen, denn der Mittelwert alleine ist nur die halbe Miete
Hm, also, auf jeden Fall ist das die falsche herangehensweise. Obwohl mir gerade keine wirklich elegante Lösung einfällt das zu beheben.
Aber mein erster Einfall:
Also, User loggt sich ein, startet Umfrage. Fragen werden berechnet die benötigt werden und zum Beispiel in ein Session-Array geschrieben. Die Fragen haben einen eindeutigen Idetifikator und einen Wert (und was man noch sonst haben möchte, beispielweise den Fragetext).
Und erst wenn die Umfrage fertig ist trägt man die Daten in die Datenbank ein. Und zwar einfach mit User und dann die ganzen Ergenisse. Wenn eine Frage nicht gestellt wurde, dann NULL.
Oder habe ich es falsch verstanden, dass die Fragen erst auf bestimmter Datenbasis generiert werden. -
Tja, daran dachte ich auch schon, das ganze per SESSION Variabele zu speichern, das hat nur 2 Nachteile:
1. Muss die Variabele auch in einem Speicher abgelegt werden, ganz ohne Aktivität, sprich CPU/Speicher Beanspruchung geht das nicht.
2. Würde der User, wenn er die Seite vorzeitig verlässt, automatisch auch seine SessionID verlieren, was bedeutet, dass er im Zweifel die ganze Umfrage + Fragebogen nochmal komplett neu ausfüllen muss...
Oder habe ich es falsch verstanden, dass die Fragen erst auf bestimmter Datenbasis generiert werden.
Ja, die Fragen, nennen wir sie mal "Part II" werden erst dann generiert, wenn "Part I" abgeschlossen ist und aus "Part I" sowie dem bisherigen Durchschnitt, ein paar Fixwerten für bestimmte Fragen usw usf. ein Fragenprofil erstellt wurde...
Ich glaub das ganze ist einfach zu verrückt und untypisch... -
erasmuz schrieb:
Tja, daran dachte ich auch schon, das ganze per SESSION Variabele zu speichern, das hat nur 2 Nachteile:
1. Muss die Variabele auch in einem Speicher abgelegt werden, ganz ohne Aktivität, sprich CPU/Speicher Beanspruchung geht das nicht.
2. Würde der User, wenn er die Seite vorzeitig verlässt, automatisch auch seine SessionID verlieren, was bedeutet, dass er im Zweifel die ganze Umfrage + Fragebogen nochmal komplett neu ausfüllen muss...
Hm, ja...
1. Ja, Speicherplatz benötigt es, aber die Vorstelung eine Tabelle für einen User zu erstellen ist etwas grausig... Dann lieber den Festplattenplatz akzeptieren
2. Nun, wenn dus wirklich sehr ineffektiv haben willst, dann könnte man zwischen den Seiten die Session-Variable var_export()en oder serialize()en... aber das auch unschön. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
