Also Alex, ich nehme seit etwa 3 Jahren die .sh. Angefangen hatte ich mit der .php aber das Problem war, dass dort der PHP-Prozess bestehen blieb, bis alle Archive gebildet wurden. Daher wurde dieser Prozess auch teils über 1,5 GB groß - zu groß für meinen Server. Bei der .sh war dem nicht so. Die startet zwar auch nur die .php (also die .sh selbst archiviert gar nicht), aber der .php-Prozess wird von der .sh bei jeder Site-ID beendet und neu gestartet. Daher deutlich weniger Speicherverbrauch und auch weniger Scriptlafzeit. Über die .sh reicht mir ein Timeout von 10 Minuten (für einen einzelnen Prozess), über die .php direkt brauche ich hier über 60 Minuten, da es nur ein Prozess ist!
Langsamer kann daher die .php an sich eigentlich nicht sein, denn die .sh startet die gleichen Klassen aus dem Core also Bezogen auf mögliche Geschwindigkeitsunterschiede durch verschiedene Programmiersprachen, denn das ist nicht vorhanden. Der Unterschied eben nur, dass der Archivierungsprozess zwischendurch neu gestartet wird.
Habe gestern aber auch gelesen, dass die .sh deprecated ist und man die .php verwenden soll. Getestet habe ich die neue Version aber nicht. Das Problem wird aber wohl das gleiche sein, denn wenn die .php erst mal gestartet ist, dann läuft die bis zum Ende durch. Und nachdem Piwik alle Daten per curl einließt, wird die dann halt sehr schnell sehr groß. Schade ist halt, dass die nicht auf php-CLI gehen, sondern php-Apache mit Curl nehmen.
"Bin grade die PHP Datei am durchjagen, nachdem ich die sh genommen habe. Geht sehr langsam."
Ich weiß jetzt nicht, was Du damit bezwecken wolltest. Gingst Du davon aus, dass die php danach sehr schnell ist, weil die sh vorher schon durchgelaufen ist und die Daten quasi schon verarbeitet wurden? Wenn ja, dann liegst Du hier falsch. Bei der Archivierung werden nur die Archive gebildet, die zum aktuellen Zeitpunkt möglich sind. Lässt Du die Archivierung zwei Stunden später wieder laufen, dann werden die gleichen Archive wieder gebildet + die von den neuen 2 Stunden. Also ein schnellerer Intervall vom Cron z.B. bringt gar nichts. Die Daten werden erst komplett und endgültig mit dem Tagesarchiv verarbeitet, also etwa 24 Stunden später.
Wenn es aber nur ein Vergleich sein sollte, was schneller geht, dann teste das am besten mit nur einer Site-ID. Die kannst Du seit der neuen Version angeben. Es müssen also nicht alle Seiten verarbeitet werden. Und teste das am besten an zwei verschiedenen Tagen mit gleichen Uhrzeiten, so dass die Datenbankeinträge in etwa gleich sind.
Wobei ich aber wirklich sagen muss, ich habe mit Piwik eigentlich keine Probleme. Meinen Server kennst Du ja, das ist immer noch der gleiche
512 MB RAM garantiert, 1024 max.
Mal so meine Einstellungen:
Piwik ist auf den Webseiten über das Proxy-Script eingebunden.
Die Piwik.js auf dem Piwik-Server wird mit Expire ausgeliefert.
Mod_Rewrite ist deaktiviert.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 30
MaxRequestsPerChild 20
</IfModule>
memory_limit = 1300M
MySQL-Anbindung per "mysqlnd" und MySQLi
extension=apc.so
apc.shm_size = 8M
key_buffer = 64K
sort_buffer_size = 64K
max_allowed_packet = 2M
thread_stack = 192K
thread_cache_size = 8
max_connections = 29
table_cache = 350
query_cache_limit = 1M
query_cache_size = 2M
default-storage-engine=INNODB
innodb_buffer_pool_size = 256M
innodb_locks_unsafe_for_binlog = 1
innodb_lock_wait_timeout = 300
innodb_log_buffer_size = 8M
innodb_log_file_size = 16M