QuicksearchDisclaimerThe individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.
|
S9Y TuningMonday, July 24. 2006Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Das tut nicht not - schalte einfach in Deinem MySQL den Query Cache ein. Dann beantwortet die Datenbank die Query mit einem vorbereiteten Result Set, sobald sie das 2. (und 3. und 4. und ...) mal vorbei kommt.
mein eindruck ist, dass s9y mit anwachsen der visitor-table immer langsamer wird. und das bereits nach drei wochen und etwa 10mb. ich sehe kein logrotate-like mechanismus, nur manuelles dumpen, plugin loeschen, plugin neu aufsetzen. - wie machst du das?
btw bin ich wegen query caching von mysql 3.xx auf 4.11 umgestiegen - bei der d)f machten die das on-the-fly, habe keinen rootserver. die daten schienen etwa 24h intakt zu sein. dann sah ich erste korrupte posts, die sich nicht mehr speichern liessen, alle kommentare ware weg, schliesslich gab's nur noch einen sql-error-message-splatterscreen. also war downgrading mit nem nicht mehr so aktuellen dump angesagt... (weiss nicht, ob ich da jetzt zeit und lust fuer stoeckchen habe
Ich kenne keine Visitor-Table in S9Y - das scheint eine Tabelle von einem Plugin zu sein. Kann es sein, daß dieser Tabelle wichtige Indices fehlen?
ja, serendipity_visitors wird vom event-plugin statistics benutzt. die statistiken gibts dann in der admin-sicht zum anklicken. eigentlich ganz nett, aber die extended visitor statistics, so eine art top der letzten eintraege im logfile und ganz nett, wenn man an das webserver-logfile nicht zeitnah rankommt, blaeht die table auf.
ein index ist vorhanden. http://www.juergen-luebeck.de/test/visitors_screenshot.jpg normalerweise wird da nur reingeschrieben, ich liege nicht auf der lauer
Das Statistikplugin habe ich bereits vor einiger Zeit rausgeworfen ... Ich bin mittlerweile am ueberlegen den Spiegel aufzutrennen mit manuellem Replikation zwischen den Platten um eine zusaetzliche Spindel zu erhalten.
Da faellt mir was ein ... interesse an einem counter via chCounter ? Kannst Du auf meinem System mitlaufen lassen. Nen zusammengefrickeltes
he, danke fuer den tipp mit chCounter! sieht besser aus als bbclone. wie waechst die datenbank des chCounter?
ich werde mal heute abend damit spielen und mich bei bedarf melden. (das statistik-plugin ist gekillt.)
Kommt sehr drauf an, wie oft du die Daten rauswirst, du kannst das System so einstellen, das bereits nach einem Tag die Daten rausfliegen,ohne das du Gesamtzahlen verlierst.
Wie Du siehst, ist da lediglich ein PRIMARY KEY auf ein auto_increment definiert. Je nach Art der Queries nutzt das gar nix.
Wenn zum Beispiel Queries auf day, time oder browser selektieren, können diese sehr lange dauern. Mich deucht dieses Plugin untermittelschlau.
Ist es auch.
Eine Durchsicht der Queries in dem Modul fand auf den ersten Blick diese Vorschläge für Änderungen: SELECT count(sessID) FROM s9y_visitors WHERE 'session_id())."' = sessID GROUP BY sessID", => alter table s9y_visitors add index (sessID) Was soll das Group By hier bewirken? SELECT timestamp FROM s9y_entries ORDER BY timestamp ASC limit 1 et al => select min(timestamp), max(timestamp), count(entries) from s9y_entries; statt drei einzelner queries => select isdraft, count(isdraft) as anzahl from s9y_entries group by isdraft; statt zwei einzelner queries => select author, count(author) as entries from s9y_entries group by author; order by ist hier sinnlos aber auch nicht schädlich In updatestats: SELECT COUNT(year) AS result FROM s9y_visitors_count WHERE year='$year' AND month='$month' AND day='$day'" => alter table s9y_visitory_count add primary key(year, month, day); -- in dieser Reihenfolge, siehe statistics_getdailystats queries update s9y_visitors count set hits = hits + 1; and insert into s9y_visitors_count (year, month, day, visits, hits) values (...., 1, 1); => insert into s9y_visitors_count (year, month, day, visits, hits) values (...., 1, 1) on duplicate key set hits = hits + 1; In updateVisitor: UPDATE s9y_visitors SET time = '$time', day = '$day' WHERE sessID = '...'; => alter table s9y_visitors add index(sess_id); in countVisitor: SELECT count(refs) AS referrer FROM s9y_refs WHERE refs = '$urlC' GROUP BY refs => alter table s9y_refs drop primary key, drop column id, add primary key(refs) => insert into s9y_refs (refs, count) values ("$urlC", 1) on duplicate key update set count = count + 1; Eigentlich will man hier mit md5(refs) arbeiten. Also => alter table s9y_refs change column refs refs varchar(32) not null; -- primary key => insert into s9y_refs (refs, count) values (".md5($urlC).", 1) on duplicate key update set count=count+1; Hier die Tables, wie sie vor den Änderungen definiert werden: CREATE TABLE s9y_visitors ( counter_id integer unsigned not null primary key auto_increment, sessID varchar(35) not null default '', day varchar(10) not null default '', time varchar(5) not null default '', ref varchar(255) default null, browser varchar(255) default null, ip varchar(15) default null ); CREATE TABLE s9y_visitors_count ( year int(4) not null, month int(2) not null, day int(2) not null, visits int(12) not null, hits int(12) not null ); CREATE TABLE s9y_refs ( id integer unsigned not null primary key auto_increment, refs varchar(255) not null default '', count int(11) not null default '0' );
Bei mir macht dieser Query mucken. Laeuft bis zu 10 Sekunden.
SELECT ep_sticky.value AS orderkey, e.id, e.title, e.timestamp, e.comments, e.exflag, e.authorid, e.trackbacks, e.isdraft, e.allow_comments, e.last_modified, a.realname AS author, a.email , e.body, e.extended FROM serendipity_entries AS e LEFT JOIN serendipity_authors a ON e.authorid = a.authorid LEFT JOIN serendipity_entrycat ec ON e.id = ec.entryid LEFT JOIN serendipity_category c ON ec.categoryid = c.categoryid LEFT OUTER JOIN serendipity_entryproperties ep_no_frontpage ON (e.id = ep_no_frontpage.entryid AND ep_no_frontpage.property = 'ep_no_frontpage') LEFT OUTER JOIN serendipity_entryproperties ep_access ON (e.id = ep_access.entryid AND ep_access.property = 'ep_access') LEFT JOIN serendipity_entryproperties ep_sticky ON (e.id = ep_sticky.entryid AND ep_sticky.property = 'ep_is_sticky') WHERE isdraft = 'false' AND e.timestamp
Hmm ... das Plugin "erweiterte Eigenschaften der Artikel" sollte man abschalten. Achja ... und die Groesse fuer temporaere Tables hochdrehen ...
Diese Query ist abgeschnitten ("AND e.timestamp" ... und wie weiter?)
Wie Isotopp bemerkte, ist die Query abgeschnitten. Abgesehen davon:
1. Gibt es für jede der Join-Bedingungen Indexe? Und werden sie auch verwendet? 2. Die Verwendung der Join-Bedingungen stört mich: ON (e.id = ep_access.entryid AND ep_access.property = 'ep_access') Sowas würde ich umschreiben in die Form: ON (e.id = ep_access.entryid) where ep_access.property = 'ep_access' Nun habe ich keine Ahnung, wie der MySQL Optimizer arbeitet, aber bei den meisten Datenbanken ist es eine schlechte Idee, Selektionskriterien in den Join-Bedingungen unterzubringen. Da geht die Index-Benutzung bzgl. des Joins schnell mal in die Hose. Bei DB2 wäre das z.B. klar kontraproduktiv. Faustregel: immer erst alles zusammenjoinen, dann mit Bedingungen die Sätze rausstreichen, die man nicht will. Meiner Erfahrung nach ist man damit fast immer schneller (und man gibt auch schlechten Optimizern eine Chance, bzw. auch die DB2s und Oracles verlaufen sich nicht, wenn die Statistik für die Tabellen und Indexe mal nicht aktuell ist).
Ich hab das gerade auf http://wiki.c0t0d0s0.org/index.php/Scratchpad#28.07.2006_10:00 gepackt. Dabei ist mir dann beim Aufbereiten aufgefallen was nicht stimmt, zwei Indices fehlten bei mir. Nu tuts vernuenftig. Ich lass aber die Scripterweiterung weiter mitlaufen, die mir die Langlaeufer anzeigt.
|
+1The LKSF bookThe book with the consolidated Less known Solaris Tutorials is available for download here
Web 2.0Contact
Networking xing.com My photos Buttons![]() This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Germany License
![]() ![]() ![]() Blog AdministrationDonateOkay, okay ... as several people have asked for it ... but you know my opinion.
|