Drupal EXTREM LANGSAM
Eingetragen von karmalo (6)am 23.07.2009 - 00:00 Uhr in
Hallo,
ich bin Drupal Anfänger und bin dabei eine Community mit Drupal zu starten.
Allerdings ist Drupal EXTREM langsam bei mir. Ich habe mit Devel einen Performance Test gemacht und der sieht schrecklich aus:
Executed 855 queries in 9826.78 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 13627.73 ms.
ms
#
where
query
4959.49
1
execute
SELECT comments.cid AS cid, comments.subject AS comments_subject, comments.nid AS comments_nid, comments.timestamp AS comments_timestamp FROM comments comments LEFT JOIN node node_comments ON comments.nid = node_comments.nid WHERE node_comments.status <> 0 OR (node_comments.uid = 1 AND 1 <> 0) OR 1 = 1 ORDER BY comments_timestamp DESC LIMIT 0, 10
3586.52
1
execute
SELECT COUNT(*) FROM (SELECT comments.cid AS cid FROM comments comments LEFT JOIN node node_comments ON comments.nid = node_comments.nid WHERE node_comments.status <> 0 OR (node_comments.uid = 1 AND 1 <> 0) OR 1 = 1 ) count_alias
102.32
1
pager_query
SELECT COUNT(*) FROM activity_targets activity_targets INNER JOIN activity activity ON activity.aid = activity_targets.aid WHERE activity_targets.target_uid = -1
97.99
2
render_textarea
SELECT name FROM filter_formats WHERE format = 1
55.26
1
avatar_blocks_newest_members
SELECT uid,name,picture FROM users WHERE uid > 0 AND access > 0 ORDER BY created DESC LIMIT 0, 10
41.06
1
cache_get
SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '1:53b1615c8c6b025deac4335f09932b49'
39.09
1
taxonomy_node_get_terms
SELECT t.* FROM term_node r INNER JOIN term_data t ON r.tid = t.tid INNER JOIN vocabulary v ON t.vid = v.vid WHERE r.vid = 11 ORDER BY v.weight, t.weight, t.name
38.95
8
aggregator_block
SELECT cid, title FROM aggregator_category ORDER BY title
35.03
1
pager_query
SELECT activity.*, activity_targets.target_uid, activity_targets.target_role FROM activity_targets activity_targets INNER JOIN activity activity ON activity.aid = activity_targets.aid WHERE activity_targets.target_uid = -1 ORDER BY activity.created DESC LIMIT 0, 6
34.78
1
forum_nodeapi
SELECT tid AS forum_tid FROM forum WHERE vid = 8287
34.51
1
node_load
SELECT n.nid, n.type, n.language, n.uid, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, n.tnid, n.translate, r.vid, r.uid AS revision_uid, r.title, r.body, r.teaser, r.log, r.timestamp AS revision_timestamp, r.format, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 8283
26.38
1
execute
SELECT DISTINCT(node.nid) AS nid, node.sticky AS node_sticky, node.created AS node_created FROM node node WHERE (node.status <> 0 OR (node.uid = 1 AND 1 <> 0) OR 1 = 1) AND (node.vid IN ( SELECT tn.vid FROM term_node tn WHERE tn.tid = 4 )) ORDER BY node_sticky DESC, node_created DESC LIMIT 0, 4
26.35
1
execute
SELECT DISTINCT(node.nid) AS nid, node.sticky AS node_sticky, node.created AS node_created FROM node node WHERE (node.status <> 0 OR (node.uid = 1 AND 1 <> 0) OR 1 = 1) AND (node.vid IN ( SELECT tn.vid FROM term_node tn WHERE tn.tid = 5 )) ORDER BY node_sticky DESC, node_created DESC LIMIT 0, 10
23.95
1
locale
SELECT s.lid, t.translation, s.version FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'de' WHERE s.source = 'Display the pane as a system block; this is more restrictive than the default.' AND s.textgroup = 'default'
23.92
1
cache_get
SELECT data, created, headers, expire, serialized FROM cache_menu WHERE cid = 'links:devel:page-cid:home:1'
22.33
1
locale
SELECT s.lid, t.translation, s.version FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'de' WHERE s.source = 'Configure this block\'s \'block settings\' in administer >> site building >> blocks' AND s.textgroup = 'default'
21.36
7
cache_get
SELECT data, created, headers, expire, serialized FROM cache_views WHERE cid = 'views_content_all:de'
20.91
1
og_access_nodeapi
SELECT og_public FROM og_access_post WHERE nid = 69
20.35
8
aggregator_block
SELECT fid, title FROM aggregator_feed ORDER BY fidWoran könnte das liege? Ich bin der einzige User auf der Seite im Moment und trotzdem so extrem langsam??
Danke im Voraus.
- Anmelden oder Registrieren um Kommentare zu schreiben
Wo wird deine Seite denn
am 23.07.2009 - 00:47 Uhr
Wo wird deine Seite denn gehostet?
Im Statusbericht alles grün?
hast du externe
am 23.07.2009 - 02:33 Uhr
hast du externe einbindungen? also calls zu anderen seiten auf die du warten musst? sowas wie adsense zb? manchmal kann das seiten extrem langsam machen, weil die dritt-seiten aufrufe langsam sind ... oder bist du bei 1blu? dann nichts wie weg. da habe ich mit cms schon rekorde gebrochen beim warten bis sich die seite aufbaut!
digidog schrieb hast du
am 23.07.2009 - 08:15 Uhr
hast du externe einbindungen? also calls zu anderen seiten auf die du warten musst? sowas wie adsense zb? manchmal kann das seiten extrem langsam machen, weil die dritt-seiten aufrufe langsam sind ...
Denk mal nach, wenn 855 SQL Queries knapp 10 Sekunden dauern, hat das wohl kaum etwas mit dem Ladeverhalten externer Skripte im Browser zu tun ;-)
Ich schlage auch vor, dass der Poster mal Details über sein Hosting verlauten lässt, denn zunächst einmal liegt hier datenbankserverseitig ein Hase im Pfeffer. (Huch, bei dem Gedanken bekomme ich Appetit..)
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Alexander Langer schriebDenk
am 23.07.2009 - 11:44 Uhr
Holla ... immer langsam ... ;-)
habe mir die Aufrufe nicht genau angeschaut. hast du mal die uhrzeit gecheckt wann ich das geschrieben habe? :-) Außerdem muss das Eine das Andere nicht zwangsläufig ausschließen. Wenn du wegen nem gebrochenen Bein zum Arzt gehst, wird er aber dennoch auch nicht ignorieren dass du außerdem aus den Nase blutest.
Na abba im Ernst: Host hatte ich ja auch schon erwähnt. Und oft haperts da gerade bei Datenbanken wenn man den Anbieter noch nicht kennt und preisvorteilhafte Entscheidungen trifft. Also ich lass aus eigener bitterer Erfahrung (ja wir waren alle mal jung und brauchten das Geld) von allem was ne "1" im Hosting Firmennamen hat die Finger von .. :-D ;-D
PS: Sag Bescheid wenn du den Hasen in die Röhre schiebst, ich bring guten Wein mit ... :D :D
--
http://www.digidog.de
" ... wer, wie, was, warum. wer nicht fragt bleibt dumm ..." Zitat - Sesamstrasse
Ich gehe mal einfach davon
am 23.07.2009 - 12:27 Uhr
Ich gehe mal einfach davon aus, dass derjenige, der auf einen Post antwortet, diesen auch gelesen hat. Und für diesen groben Überblick reicht das Lesen von Absatz 3 im Eingangspost, dazu muss man die dahinter stehenden SQL Statements nicht auswendig gelernt haben ;)
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Alexander Langer
am 23.07.2009 - 12:56 Uhr
Ich gehe mal einfach davon aus, dass derjenige, der auf einen Post antwortet, diesen auch gelesen hat. Und für diesen groben Überblick reicht das Lesen von Absatz 3 im Eingangspost, dazu muss man die dahinter stehenden SQL Statements nicht auswendig gelernt haben ;)
Alex es ging mir nur um das "denk mal nach" ... das fand ich etwas zu dreist. und unabhängig von den daten aus dem erstpost und davon dass ich hosts ebenfalls erwähnte kann so etwas wie external calls ja trotzdem mit reinspielen, ansonsten:
s.o. http://www.drupalcenter.de/node/20255#comment-71296 (z.B. 2.Satz und folgende)
sonst würde ich mich wiederholen. So, und um das jetzt mal zu beenden: Ja!, du hast den "Längeren" ... :-) und nu lass bitte gut sein. Das ist mir zu zeitaufwändig und unsinnig.
OFFTOPIC ENDE (topic abonnement abgebrochen)
--
" ... wer, wie, was, warum. wer nicht fragt bleibt dumm ..." Zitat - Sesamstrasse
Nun, wenn du in etwas
am 23.07.2009 - 13:04 Uhr
Nun, wenn du in etwas Geschriebenes einen Tonfall reininterpretierst, den es aufgrund des Mediums nicht haben kann, musst du gewissermaßen mit deiner eigenen Dünnhäutigkeit umzugehen lernen.
No offense taken.
Und wenn jemand eine Seitenausführungszeit >13 Sekunden hat, er uns keinerlei andere Angaben macht, ist es erstmal schlichtweg überhaupt nicht zweckdienlich mit irgendwelchen evtl. vmtl. mglw. Front-End-Performance-Issues daherzukommen, da glasklar ist, dass zunächst mal serverseitig was völlig schief hängt.
Um wie du mit Analogien zu arbeiten:
Wenn der Wagen nicht anspringt, hilft mir ein "Haben deine Reifen noch Profil?" nicht weiter.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
ok, ....
am 23.07.2009 - 14:10 Uhr
ok: also da du offensichtlich schwer mit mir beschäftig bist, möchte ich Dich nicht ignorieren. Aber es wäre schön wenn diese persönliche Belästigung bald ein Ende nimmt - ich habe noch drei Außerhaustermine und hänge in der Zeit, denn selbst wenn ich das Abo versuche hier zu entfernen kriege ich immer noch nervige Hinweise auf neue Kommentare per mail:
ok - Ich korrigiere Dich mal kurz (Korrekturen magst du ja):
1. Wenn das Auto nicht anspringt, liegt es sicherlich nicht an den Reifen, richtig, aber ich würde ihn trotzdem darauf hinweisen wenn er einen Platten hat.
2. zweckmäßigkeit ist enorm subjektiv, und da ich nicht nur auf einen platten REifen hingewiesen habe auch zweitrangig.
3. Wie viele deiner hier getroffenen "glasklaren" Ansagen, ist das meiste davon mit sehr viel Vorsicht zu genießen: z.B. Wenn jemand freundlich darauf hinweist, dass er den (wohlgemerkt!) Text! der Anrede nicht mag ("Denk mal nach"), denjenigen zurechtzuweisen (und damit das vorherige noch zu toppen) mit dem Argument "er würde einen Tonfall hören" (was nicht der fall war), und dann noch ratschläge in sachen dünnhäutigkeit zu erteilen: Ich halte das nicht für den richtigen Weg, Alex. Menschen machen Fehler, aber ich versuche so lang wie möglich den Respekt gegenüber diesem Menschen zu wahren. Aber das ist hier deine Spielwiese. Ich möchte dich (im Gegensatz zu dir mir gegenüber) dahingehend nicht weiter belehren, das steht mir nicht zu.
Ich bitte um Löschung meines Accounts bei Drupalcenter.de
Vielen Dank und mit freundlichen Grüßen
Britta
digidog schrieb Ich bitte
am 23.07.2009 - 17:17 Uhr
Ich bitte um Löschung meines Accounts bei Drupalcenter.de
Done!
--
"Jeder Mensch ist lieb." Peter Ludolf
mein host
am 23.07.2009 - 19:47 Uhr
Hallo,
also ich bin bei All-inkl.com
ich habe dort auch ein PHP-Nuke System drauf mit rund 8000 User und 2000-3000 User täglich, welches EXTREM SCHNELL läuft.
Was für angaben benötigt ihr noch?
Gruß
Karmalo
Deaktiviere mal das Update
am 23.07.2009 - 19:59 Uhr
Deaktiviere mal das Update Status Modul und schau mal, ob es dann besser läuft.
--
"Jeder Mensch ist lieb." Peter Ludolf
bv schrieb digidog
am 23.07.2009 - 20:24 Uhr
Ich bitte um Löschung meines Accounts bei Drupalcenter.de
Done!
--
"Jeder Mensch ist lieb." Peter Ludolf
Hm? Fand ich jetzt ehrlich gesagt etwas überhastet und eigentlich auch nicht wirklich nötig. (In der Entstehung)
Gerade bei Performance-Problemen habe ich schon manche Überraschung erlebt. Manchmal liegt es tatsächlich am platten Reifen, der den Drupal Motor nicht anspringen lässt. Oder vielleicht so eben, aber dann eben keine Geschwindigkeit aufnehmen kann. Was dann ja definitiv am platten Reifen liegt.
Gruß Meinolf
md schrieb bv
am 23.07.2009 - 20:33 Uhr
Ich bitte um Löschung meines Accounts bei Drupalcenter.de
Done!
--
"Jeder Mensch ist lieb." Peter Ludolf
Hm? Fand ich jetzt ehrlich gesagt etwas überhastet und eigentlich auch nicht wirklich nötig. (In der Entstehung)
Hmm, ja wahrscheinlich hast Du recht, Meinolf. Ich muss gestehen, ich habe mir den Thread gar nicht komplett durchgelesen, sondern in erster Linie ihren Wunsch hier gelesen und das dann quasi als Anweisung aufgenommen. Natürlich ist digidog herzlich dazu aufgerufen hier jederzeit wieder einen neuen Account zu erstellen! :)
--
"Jeder Mensch ist lieb." Peter Ludolf
Bug?
am 23.07.2009 - 21:23 Uhr
digodog hat jetzt exakt meine userpoints. Das dürfte wohl ein Bug sein. Die Frage ist wo? Es gibt doch immer wieder 'Überraschungen'.
vg
--
md - DrupalCenter.de
mdwp*
md schrieb Gerade bei
am 23.07.2009 - 21:45 Uhr
Gerade bei Performance-Problemen habe ich schon manche Überraschung erlebt. Manchmal liegt es tatsächlich am platten Reifen, der den Drupal Motor nicht anspringen lässt. Oder vielleicht so eben, aber dann eben keine Geschwindigkeit aufnehmen kann. Was dann ja definitiv am platten Reifen liegt.
Soweit waren wir noch gar nicht und der Datenbank und PHP ist es mal völlig egal ob die Websiete 20.000 Bilder, Javascripts, etc. von externen Seiten einbaut. Wenn der Server rund 10 Sekunden für die Queries und nochmal 3-4 für PHP benötigt, ist die Lösung dafür nicht im Browser des Users zu finden. Das muss man mir nicht glauben, man kann auch gern in der High Performance Group auf g.d.o stöbern oder gleich mal Khalid oder Robert anmailen ;-)
Shared Hosting ist bei solchen Problemen zusätzlich suboptimal, weil man stark eingeschränkt ist sowohl in der Diagnose (Was macht der Server gerade?) als auch in der Problemlösung (Diverse relavante Einstellungen an Apache, MySQL, PHP, etc.). Entsprechend eingeschränkt ist man auch beim Anraten von Tipps.
Interessant wäre ggf. noch ob die Drupal Installation in einem eigenen Account bei All-Inkl. läuft. Könnte dann womöglich auf ein Performance-Problem des Servers, mglw. durch einen anderen Kunden hervorgerufen, hindeuten. Könnte auch ein alter Account sein, der entsprechend auf einer alten Hard- und Software läuft. Da müsste man sich mal direkt mit All-Inkl. kurzschließen. Passenderweise würde man versuchen das mit denen zu timen, damit die auch dann nachsehen, während man gerade über Devel nachschaut was geht. Ggf. reicht es denen die Timestamps der Tests zu geben, wo es lahm war, denn wenn die ein Performance-Monitoring haben, brauchen sie nur schauen was zur entsprechenden Zeit abging.
Auf nem (virtuellen) Root-Server würde ich auf Seiten MySQL zunächst auf nicht aktivierten Query Cache tippen (habe ich dieses Jahr schon auf brandneuen Installationen großer Hoster als default gesehen) und PHP-seitig auf nicht vorhandenen Bytecode Cache (vorzugsweise APC, denn eAccelerator neigt zu Segfaults wie sie das DC anfangs auch eien Weile hatte).
Und selbst wenn beides okay ist und der vServer eigentlich genug Dampf haben sollte, habe ich ihn in einer leeren Drupal-Testumgebung schon lahmen sehen, weil die eingesetzte Virtualisierungslösung (wohlgemerkt bei einem bekannten großen Hoster) es schaffte die Maschine bei 0 Last zu halten und dabei auch genau 0 Performance zu liefern.
Ist also alles nicht so einfach ;-)
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Na zum Beispiel, ob beide
am 23.07.2009 - 23:40 Uhr
Na zum Beispiel, ob beide auf dem gleichen Server liegen. Oder welches Paket gebucht wurde.
Kann gut sein, dass der Server ein klein wenig überlastet ist.
Hallo,
also ich bin bei All-inkl.com
ich habe dort auch ein PHP-Nuke System drauf mit rund 8000 User und 2000-3000 User täglich, welches EXTREM SCHNELL läuft.
Was für angaben benötigt ihr noch?
Alexander Langer
am 23.07.2009 - 23:55 Uhr
Gerade bei Performance-Problemen habe ich schon manche Überraschung erlebt. Manchmal liegt es tatsächlich am platten Reifen, der den Drupal Motor nicht anspringen lässt. Oder vielleicht so eben, aber dann eben keine Geschwindigkeit aufnehmen kann. Was dann ja definitiv am platten Reifen liegt.
Soweit waren wir noch gar nicht und der Datenbank und PHP ist es mal völlig egal ob die Websiete 20.000 Bilder, Javascripts, etc. von externen Seiten einbaut. Wenn der Server rund 10 Sekunden für die Queries und nochmal 3-4 für PHP benötigt, ist die Lösung dafür nicht im Browser des Users zu finden. Das muss man mir nicht glauben, man kann auch gern in der High Performance Group auf g.d.o stöbern oder gleich mal Khalid oder Robert anmailen ;-)
...
Ist also alles nicht so einfach ;-)
webseiter.de
Darum ging es mir auch nicht. Und ja, das ist alles nicht so einfach und manchmal noch viel komplizierter. Manchmal auch viel trivialer.
Aber wie gesagt, darum ging es mir auch nicht in erster Linie.
Und bei Khalid - http://2bits.com - hat ein Kunde von mir mal nachgefragt. Die nehmen gleich mal 4k+ für die Analyse. Nicht falsch verstehen: das kann durchaus ok sein. Aber vermittel das mal den Forumsmitglieder hier. Die wollen ein CMS und das soll laufen.
vg
--
md - DrupalCenter.de
mdwp*
Die Tipps von Khalid auf
am 24.07.2009 - 12:27 Uhr
Die Tipps von Khalid auf 2bits.com und in g.d.o sind umsonst ;)
Wie du selbst schon sagtst, die Leute wollen ein System was läuft. Dafür muss man ggf. auch mal was tun, denn von allein passiert da nüscht.
Im Allgemeinen habt ihr ja recht. Manchmal ist es trivial und an ganz anderer Stelle aufgehängt. Aber was bringt die Erwähnung von Gemeinplätzen bei dieser konkreten Problemstellung mit den gegebenen Daten?
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Suspekt
am 24.07.2009 - 14:00 Uhr
Sieht das hier:
OR (node_comments.uid = 1 AND 1 <> 0) OR 1 = 1nicht sehr sehr merkwürdig aus?
vg
--
md - DrupalCenter.de
mdwp*
Ist nicht optimiert, aber
am 24.07.2009 - 15:54 Uhr
Ist nicht optimiert, aber das erledigt der Query Analyzer von MySQL selbständig und das Ergebnis (die optimierte Query) landet im Query Cache - so dieser aktiviert ist. Autom. erzeugtes SQL ist nunmal nüscht für Ästethen :)
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Hallo, wenn das nicht
am 24.07.2009 - 19:19 Uhr
Hallo,
wenn das nicht optimiert ist, wie könnte ich es optimieren?
Alexander Langer
am 24.07.2009 - 22:42 Uhr
Ist nicht optimiert, aber das erledigt der Query Analyzer von MySQL selbständig und das Ergebnis (die optimierte Query) landet im Query Cache - so dieser aktiviert ist. Autom. erzeugtes SQL ist nunmal nüscht für Ästethen :)
Es ging mir nicht um Ästethik. Sonder um 'or 1 = 1'. Das sieht doch fast nach ner versuchten SQL Injection aus oder einem bösen Fehler in einem Modul, aber das ist doch nicht normaler Bestandteil einer SQL Query.
vg
--
md - DrupalCenter.de
mdwp*
Ich bin kein Hacker, kann
am 24.07.2009 - 23:07 Uhr
Ich bin kein Hacker, kann mir aber nicht vorestellen was man davon hätte solchen Code zu injizieren. Sieht wie gesagt für mich nach gewöhnlichem autom. durch diverse parameter erzeugten SQL Code aus. "OR 1 = 1" sorgt in der Konsequez ohne Klammerung dafür, dass die Query komplett alle Einträge über die verwendeten und ggf. gejointen Indexe liefert. Wenn das logisch falsch wäre, müsste dem Autor dies in seinen Views auffallen, noch eher als das Performanceproblem - welches der Teil der Query nicht erklärt, denn eine Bedingung die immer wahr ist, ist denkbar einfach optimiert.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Bin auch kein Hacker, aber
am 24.07.2009 - 23:52 Uhr
Bin auch kein Hacker, aber SQL Injections die z.B. ein Site Login knacken wollen, machen sowas häufig. Drupal hat ja einen Schutz vor solchen Angriffen, wenn man die Drupal DB-Funktionen richtig anwendet.
Wie auch immer, so eine Query hab ich in Drupal noch nicht gesehen (man mag mich da gerne korrigieren) und der Sinn erschliesst sich mir auch nicht.
Ob das ein Grund für die lange Ausführungszeit sein kann, kann ich ad hoc nicht beurteilen. Würde es aber auf einer eigenen Site mit Sicherheit in Betracht ziehen und untersuchen. Woher kommt die Query, macht ein Modul ein SQL rewrite usw. usf.
vg
--
md - DrupalCenter.de
mdwp*
gibt es eine möglichkeit
am 25.07.2009 - 02:40 Uhr
gibt es eine möglichkeit diesen query bzw. den dazugehörigen modul zu identifizieren?