Pisearch - empfohlene Änderung
Pisearch - empfohlene Änderung
Leute die Pisearch benutzen sollten nachfolgende Zeile
VON
$sql="SELECT c.content_id,c.type,c.show_in_menu,c.menu_text,p.content FROM ".cms_db_prefix()."content c INNER JOIN ".cms_db_prefix()."content_props p ON p.content_id = c.content_id WHERE (c.content_id = p.content_id AND c.active = 1 AND c.type='content' %expage%)";
AUF
$sql="SELECT c.content_id,c.menu_text,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
ändern - durch Verzicht auf JOIN läuft die Abfrage schneller.
VON
$sql="SELECT c.content_id,c.type,c.show_in_menu,c.menu_text,p.content FROM ".cms_db_prefix()."content c INNER JOIN ".cms_db_prefix()."content_props p ON p.content_id = c.content_id WHERE (c.content_id = p.content_id AND c.active = 1 AND c.type='content' %expage%)";
AUF
$sql="SELECT c.content_id,c.menu_text,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
ändern - durch Verzicht auf JOIN läuft die Abfrage schneller.
Re: Pisearch - empfohlene Änderung
Gibt es eigentlich irgend wo mal eine "Übersicht" über die Laufzeiten bzw. Ressourcenverbrauch von Befehlen ?Piratos wrote: durch Verzicht auf JOIN läuft die Abfrage schneller.
PS: Wenn möglich, bitte gleich im richtigen Board posten - erleichtert mir die Arbeit ungemein

Re: Pisearch - empfohlene Änderung
Was Mysql betrifft gibt es das schöne Kommando EXPLAIN das man jeder SQL Formulierung vorsetzen kann um dann z.B. mit PHPMyadmin mal zu sehen, was man da eigentlich macht und ob man seine Datenbank bzw. auch die Abfrage selbst optimal aufgebaut hat."Übersicht" über die Laufzeiten bzw. Ressourcenverbrauch von Befehlen
Man kann sich auch mal die Mysql System Informationen anschauen, da werden z.B. über PHPMyadmin wunderbar in Rot markante Stellen angezeigt, die als Hinweis zu Überlegungen in dieser Art dienen.
Hier ein Ausszug aus dem Mysql Handbuch - steht aber auch in jedem SQL Handbuch.
Der Punkt worauf es ankommt ist der in Abfragen und da insbesondere SELECT's möglichst auf Indexe zuzugreifen - mit EXPLAIN kann man das checken.When you precede a SELECT statement with the keyword EXPLAIN, MySQL explains how it would process the SELECT, providing information about how tables are joined and in which order.
With the help of EXPLAIN, you can see when you must add indexes to tables to get a faster SELECT that uses indexes to find the records.
Wird nicht über Indexe zugegriffen, werden praktisch alle Datensätze geflöht.
Bei einem Miniweb macht sich das kaum bemerkbar, aber hat man da reichlich Seiten schon.
So sind z.B. die Abfragen im Module News so gehalten , dass keinerlei Indexe verwendet werden, ja selbst wenn es da genügend geben würde (gibt es aber nicht).
Da werden dann teils temporäre Tabellen gebildet, Filesort angewendet und alle Datensätze abgeklappert.
Die meisten Coder arbeiten nach dem Motto schnell, einfach und bequem - es funktioniert auch, aber zu häufig mit angezogener Handbremse.
Man sollte sich einmal mit einem Testscript eine Tabelle mit mehreren tausend Inhalten füllen und dann mal mit Indexen und Abfragen spielen.
Web's die Ihre Nahrung offenbar überwiegend aus diesem Nerwstgeil beziehen (davon gibt es offenbar einige) sind damit echt in den Hintern gekniffen, denn die Aufbereitung dauert relativ sehr lange.
Aber auch bei einfachen Abfragen, die häufig eingesetzt werden, sollte man eine Überprüfung vornehmen, denn da kann enorm beschleunigt werden.
Im ürbigen - echte relationale Beziehungen habe ich bei CMSMS noch nirgends entdecken können.
Was PHP betrifft, kann man sich ebenfalls mit dem Handbuch behelfen - da werden direkt z.B. Hinweise gegeben wie array_push sollte man vermeiden da eine normale Zuweisung wie $array[]= $value sehr viel schneller ist, als der Funktionsaufruf array_push.
Es gibt einige wenige Websiten die sich mit PHP Optimierung beschfäftigen.
Das Problem ist bei einer PHP Optimierung immer das gleiche - die Differenz von X zu Y ist immer sehr kein und die sollte man dann nie absolut sondern immer relativ sehen, ansonsten wirft man gleich das Handtuch, weil man meint, es lohnt sich nicht.
Da sind insbesondere auch Schleifenoptimierungen interessante Punkte.
Wenn man z.B. CMSMS unter diesen Gesichtpunkten optimieren wollte, ändert man hunderte von Zeilen . Die Erfolge sind sichtbar und umso mehr, wenn ein mit CMSMS erstelltes Web nicht 10-15 Seiten hat sondern 100 - 200 oder noch mehr.
Wegen der kleinen Schritte die sich im Einzelfall im Microssekundenbereich bewegen, machen sich relativ wenig Coder überhaupt die Mühe da etwas zu verbessern, denn Einzelerfolge gehen da praktisch in den Schwankungen unter, sind nicht erkennbar.
Bei komplexen Systemen wie diese CMS macht sich das jedoch dann gesammelt negativ bemerkbar und die Coder suchen dann nach der grossen Bombe, die das verursacht, erkennen aber nicht die Fliegenfürze, die oftmals die wahre Ursache sind.
Stichwort relationale Beziehungen
Da möchte ich nochmals etwas zu bemerken.
Alle von CMSMS unterstützten DB sind hammerharte Db's mit allen möglichen Fähigkeiten.
Relationale Beziehungen sind eigentlich das Fleisch und die Würze solcher Systeme , finden aber hier keinerlei Verwendung, obwohl sich das ausgerechnet anbietet, da ein klassisches Einsatzgebiet.
Si sieht z.B. eine 1:n Beziehung in einer Mysql Struktur aus - dürften den meisten die hier mit Code zu tun haben, wohl unbekannt sein:
Und so sieht die Beziehung im Bild aus:
[attachment deleted by admin]
Alle von CMSMS unterstützten DB sind hammerharte Db's mit allen möglichen Fähigkeiten.
Relationale Beziehungen sind eigentlich das Fleisch und die Würze solcher Systeme , finden aber hier keinerlei Verwendung, obwohl sich das ausgerechnet anbietet, da ein klassisches Einsatzgebiet.
Si sieht z.B. eine 1:n Beziehung in einer Mysql Struktur aus - dürften den meisten die hier mit Code zu tun haben, wohl unbekannt sein:
Code: Select all
--
-- Tabellenstruktur für Tabelle `table_01`
--
CREATE TABLE `table_01` (
`idTable_01` int(10) unsigned NOT NULL auto_increment,
`name` varchar(45) collate latin1_general_ci default NULL,
PRIMARY KEY (`idTable_01`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;
--
-- Daten für Tabelle `table_01`
--
-- --------------------------------------------------------
--
-- Tabellenstruktur für Tabelle `table_02`
--
CREATE TABLE `table_02` (
`idTable_02` int(10) unsigned NOT NULL auto_increment,
`Table_01_pw_idTable_01` int(10) unsigned NOT NULL,
`inhalt` varchar(255) collate latin1_general_ci default NULL,
PRIMARY KEY (`idTable_02`,`Table_01_pw_idTable_01`),
KEY `Table_02_FKIndex1` (`Table_01_pw_idTable_01`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;
--
-- Daten für Tabelle `table_02`
--
[attachment deleted by admin]
Re: Pisearch - empfohlene Änderung
Eine Anpassung von Pisearch an die 0.13b1 gibbet auch schon
...
http://forum.cmsmadesimple.org/index.ph ... l#msg23590

http://forum.cmsmadesimple.org/index.ph ... l#msg23590
Re: Pisearch - empfohlene Änderung
Das betrifft nur clean url - das mit clean url wird noch ein heisses thema wenn es denn endlich mal eine multilinguale Version geben sollte (bei PW - ist ja von Haus aus multilingal - verzichte ich dankend auf clean url hä hä - das gibt nur Ärger.).
Last edited by Piratos on Tue Apr 25, 2006 4:10 pm, edited 1 time in total.
Re: Pisearch - empfohlene Änderung
There are times when I wish I spoke German, or that the Google translator wasn't so rubbish. I'd be interested to hear (actually read) your comments.
Russ
Russ
Re: Pisearch - empfohlene Änderung
Ich arbeite stink normal mit der pageid und Sprache und das war's - einfach schnell und gut.URLs dann suma-freundlich
Die Seiten werden bei Google und Yahoo & co genauso gut aufgenommen, als wenn man das so mit clean url macht - ich sehe da keine Probleme, da die Aufnahme sowieso über externe Scripte gesteuert werden - siehe Google Sitemap.
Bei Yahoo geht das z.B. über eine automatisch erstellte Liste oder ein entsprechenden Atomfeed, ja sogar über ein RSS Feed.
Da ist clean url gut gemeint aber für mich bereits Schnee von gestern - was soll ich mich da mit alten Märchen beschäftigen.
Last edited by Piratos on Tue Apr 25, 2006 5:02 pm, edited 1 time in total.
Re: Pisearch - empfohlene Änderung
You should take the changed pisearch script in the dev if it works and not in the forum.There are times when I wish I spoke German
Change this:
FROM
$sql="SELECT c.content_id,c.type,c.show_in_menu,c.menu_text,p.content FROM ".cms_db_prefix()."content c INNER JOIN ".cms_db_prefix()."content_props p ON p.content_id = c.content_id WHERE (c.content_id = p.content_id AND c.active = 1 AND c.type='content' %expage%)";
TO
$sql="SELECT c.content_id,c.menu_text,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
Last edited by Piratos on Tue Apr 25, 2006 5:46 pm, edited 1 time in total.
Re: Pisearch - empfohlene Änderung
Oh Gott, ich hätte mir mal den Code ansehen sollen, das mag ja für clean url gut sein (das überprüfe ich nicht) , aber für alle anderen ist das voll Sch... , der hat ja fast ein ganzes Menüsystem dort eingebaut - ade Power.
Re: Pisearch - empfohlene Änderung
Für mod_rewrite (Ausgabe als html) muss pisearch wie folgt geändert werden:
1. SQL Anweisung damit content_alias geholt wird.
$sql="SELECT c.content_id,c.menu_text,c.content_alias,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
2.
Im Code selbst muss diese Stelle geändert werden.
$searchi++;
if ($config['assume_mod_rewrite'] == true)
$searchy[$searchi]->url=$config["root_url"]."/".$dbr['content_alias'].$config['page_extension']."&pimsw=".$pimsw;
else
$searchy[$searchi]->url=$config["root_url"]."/index.php?".$config["query_var"]."=".$dbr["content_id"]."&pimsw=".$pimsw;
Alles andere inclusive der Templates bleibt unverändert. Ist mod_rewrite aktiv werden die links als html ausgegeben.
1. SQL Anweisung damit content_alias geholt wird.
$sql="SELECT c.content_id,c.menu_text,c.content_alias,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
2.
Im Code selbst muss diese Stelle geändert werden.
$searchi++;
if ($config['assume_mod_rewrite'] == true)
$searchy[$searchi]->url=$config["root_url"]."/".$dbr['content_alias'].$config['page_extension']."&pimsw=".$pimsw;
else
$searchy[$searchi]->url=$config["root_url"]."/index.php?".$config["query_var"]."=".$dbr["content_id"]."&pimsw=".$pimsw;
Alles andere inclusive der Templates bleibt unverändert. Ist mod_rewrite aktiv werden die links als html ausgegeben.
Re: Pisearch - empfohlene Änderung
1. I think it works, but you can see as it is now up on our test site (look at the links produced by search) try searching with the phrase 'test' which will give you a few resultsPiratos wrote:You should take the changed pisearch script in the dev if it works and not in the forum.There are times when I wish I spoke German
Change this:
FROM
$sql="SELECT c.content_id,c.type,c.show_in_menu,c.menu_text,p.content FROM ".cms_db_prefix()."content c INNER JOIN ".cms_db_prefix()."content_props p ON p.content_id = c.content_id WHERE (c.content_id = p.content_id AND c.active = 1 AND c.type='content' %expage%)";
TO
$sql="SELECT c.content_id,c.menu_text,p.content FROM ".cms_db_prefix()."content c ,".cms_db_prefix()."content_props p WHERE p.content_id = c.content_id AND c.active = 1 AND c.type='content' AND c.show_in_menu = 1 AND p.content >'' %expage%";
http://www.cms.shoesforindustry.net/search.html
Not sure how to 'take the changed pisearch script in the dev'?
2. Was the change in SQL code for me?? Is there a reason for it? (If it is for me thank you

Russ
Re: Pisearch - empfohlene Änderung
If you dispense with JOIN instruction pisearch will running faster ...Russ wrote: Is there a reason for it?
Re: Pisearch - empfohlene Änderung
Thanks cyberman, I've updated the example, still not sure what to do with it, but it is updated. I shall try and not frequent the German language pages too much, especially untill my German improves 
Russ

Russ