hm - im wesentlichen debian-standard.
Die max_execution-time ist auf 180 sekunden - das liegt aber eher daran, dass andere aktive komponenten der site (die nicht auf dokuwiki zurückgreifen) manchmal systembedingt langsam sind.
Wie gesagt: keine irgendwie getweakte php.ini - ich stell die aber auf wunsch auch gern hier rein.
im moment läuft das auf einem shared host - d.h. php hat entsprechend wenig memory zur verfügung - läuft trotzdem prima.
Die suche ist optisch deaktiviert, funktioniert aber, wenn man direkt über die url arbeitet:
Beispiel:
http://dw.serversniff.de/doku.php?do=search&id=dokuwiki
langsamer wirds, wenn man nach häufig und sehr häufig vorkommenden begriffen sucht:
Beispiel:
http://dw.serversniff.de/doku.php?do=search&id=apache
wie die suche in der geschwindigkeit funktioniert, ist mir ein rätsel. das aktuelle backup des daten-verzeichnisses sind als .tgz 230MB.
beim testen ist mir aufgefallen, dass die suche als snippet rohtext ausgibt, den ich dem user so eigentlich gar nicht zugänglich machen wollte. für "normale" wikis ist das aber sicher kein problem.
Der Index hat mich etwas nachdenken gekostet - ich wollte zeit und index-seitengrösse im rahmen halten, die verzeichnisse auf dem server nicht zu riesig werden lassen, den suchmaschinen aber dennoch orientierung bieten. Die simpelste lösung schien mir, das auf namensabhängige unterverzeichnisse aufzusplitten (/a/ab/abc/abc.de).
Die aktuelle Seitenzahl wird ersichtlich, wenn man auf ein Tag klickt (ich habe das Tag-Plugin so gehackt, dass es nicht mehr den Tagindex verwendet, sondern eine MySQL-DB).
thomas