Site langsam
heinetz
- browser
Hallo Forum,
ich beobachte bei einem PHP/MySQL-Projekt, die ich programmiert habe seit geraumer
Zeit ein merkwürdiges Verhalten:
Die Site 'hängt' hin und wieder und läd' sich nen Wolf. Wenn ich die
selbe Site dann in einem anderen Browser öffne, funktioniert alles
reibungslos.
Das hatte ich erstmal auf meine Programmierung geschoben, die sicher
nicht die performanteste ist. Nun stelle ich aber gerade fest, dass
exakt dieses Verhalten auch auftritt, wenn ich mit MySQL-Admin ein
Select-Statement absetze (, das ich als eigentlich nichts als besonders
einstufe:
SELECT
s.*,
c.*,
u.*,
u2.*
FROM structure
s
JOIN content\_offline
c ON s.site_id = c.site_id
JOIN meta\_user
u ON c.owner_id = u.id
JOIN meta\_user
u2 ON c.user_id = u.id
... und bei MySQL-Admin würde ich vermuten, dass das schon einigermassen
vernünftig programmiert ist.
Wie kann es also sein, dass die Ausgabe in dem einen Browser gerade "hängt"
und ich sie daraufhin mit einem anderen Browser flüssig abrufen kann?
beste gruesse,
heinetz
Grüße,
Wie kann es also sein, dass die Ausgabe in dem einen Browser gerade "hängt"
und ich sie daraufhin mit einem anderen Browser flüssig abrufen kann?
ohne es zu wissen vermute ich cache^^
MFG
bleicher
Hi,
Nun stelle ich aber gerade fest, dass
exakt dieses Verhalten auch auftritt, wenn ich mit MySQL-Admin ein
Select-Statement absetze (, das ich als eigentlich nichts als besonders
einstufe:
führe das Statement mit einem EXPLAIN an und analysiere die Mängel.
Wie kann es also sein, dass die Ausgabe in dem einen Browser gerade "hängt"
und ich sie daraufhin mit einem anderen Browser flüssig abrufen kann?
Auch Datenbankmanagementsysteme verstehen es, Informationen zu cachen.
Cheatah
Hi,
führe das Statement mit einem EXPLAIN an und analysiere die Mängel.
danke für den Tipp mit EXPLAIN. Das kannte ich noch nicht, kann ich
aber auch noch nicht auswerten. Mängel kann ich keine feststellen.
Auch Datenbankmanagementsysteme verstehen es, Informationen zu cachen.
Ich kenne nur den Browser-Cache und weiss daher nicht wie das Caching
von DB-Sytemen funktioniert. Ich mach mich schlau.
danke,
gruesse,
heinetz
Hi,
danke für den Tipp mit EXPLAIN. Das kannte ich noch nicht, kann ich
aber auch noch nicht auswerten. Mängel kann ich keine feststellen.
vielleicht können es andere, die hiermit mehr Erfahrung haben und den Output auswerten können.
Ich kenne nur den Browser-Cache und weiss daher nicht wie das Caching
von DB-Sytemen funktioniert. Ich mach mich schlau.
Ungeachtet dessen scheint es mir so zu sein, dass Dein Statement unter normal vorkommenden Umständen unperformant ist. Es ist somit optimierungswürdig.
Cheatah
Hi!
danke für den Tipp mit EXPLAIN. Das kannte ich noch nicht, kann ich aber auch noch nicht auswerten. Mängel kann ich keine feststellen.
Das Handbuch wäre eine gute erste Anlaufstelle das Wissensdefizit zu verringern: Optimizing Queries with EXPLAIN.
Lo!
Moin Moin!
Die Site 'hängt' hin und wieder und läd' sich nen Wolf. Wenn ich die
selbe Site dann in einem anderen Browser öffne, funktioniert alles
reibungslos.
Netzwerkprobleme?
Das hatte ich erstmal auf meine Programmierung geschoben, die sicher
nicht die performanteste ist. Nun stelle ich aber gerade fest, dass
exakt dieses Verhalten auch auftritt, wenn ich mit MySQL-Admin ein
Select-Statement absetze (, das ich als eigentlich nichts als besonders
einstufe:SELECT
s.*,
c.*,
u.*,
u2.*
FROMstructure
s
JOINcontent\_offline
c ON s.site_id = c.site_id
JOINmeta\_user
u ON c.owner_id = u.id
JOINmeta\_user
u2 ON c.user_id = u.id
Ein Join über vier Tabellen (3 + ein self join). Je nach dem, wie voll die Tabellen sind, und wie gut oder schlecht Indexe angelegt sind, kann man damit auch richtig fette Datenbanken in die Knie zwingen.
Du solltest mindestens auf allen Spalten, die in den Join-Bedingungen vorkommen, Indexe haben.
Dann ziehst Du gnadenlos sämtliche Tabellenspalten aus der DB, in aller Regel brauchst Du die nicht alle. Alles, was Du nicht selektierst, spart Arbeit. Schmeiß also die Sterne weg und schreib rein, was Du wirklich haben willst.
Und bist Du sicher, dass Du für den letzten Join wirklich u.id und nicht u2.id benutzen willst? Mit u statt u2 dürfte die Ergebnismenge vermutlich unerwartet groß werden.
... und bei MySQL-Admin würde ich vermuten, dass das schon einigermassen
vernünftig programmiert ist.
*PRUST*
Alexander