There used to be a bug which I though I fixed in #2981

Which version of Piwik are you using? please try with latest.

Sorry - forgot to mention the version.

I wrote the above report when I was on 2.2.3-b1.
I have just updated to 2.2.3-b4 now and I can still reproduce the issue - as soon as I lower "Reports for today will be processed at most every" to 10 seconds displaying any goal graph takes always ~40 seconds instead of happening immediately (after having displayed it at least once).
While I wait for those 40 seconds I see that the DB (mysql) is performing write operations for the whole duration.

I have to mention that my server is not using async writes but the fs is mounted with sync writes (because once when it was using async it crashed and I had to spend an afternoon to bring back the DB in a usable state), so in my case I am probably suffering more than others who are using full async.
Thx

I have just updated to 2.2.3-b4 now and I can still reproduce the issue - as soon as I lower "Reports for today will be processed at most every" to 10 seconds displaying any goal graph takes always ~40 seconds instead of happening immediately (after having displayed it at least once).

Thats normal if you setup timeout to 10 seconds that Piwik re-processes the data after 10 seconds.

To test, set the timeout to 1 hour, then wait one hour + wait that the archive cron has executed. Then visit the Goal report -> does it load instantly? if yes, all is working. If it's still slow to load, then it means the archive cron did not process the Goal data and that's a bug (which is #2981)

Please re-open if it does not work for you, as this is important to make sure it works :)

So, since yesterday evening the timeout ("General settings => reports for today will be processed at most every") is set to "3600" seconds.

The current time on my server is:
#####==========

date

Wed May 14 19:05:57 CEST 2014
#####==========

On the server the last archive cronjob ran 5 minutes ago and it is scheduled to run every 30 minutes (for unknown reasons the time that the archiver generates in its logs while it runs is always "localtime - 2hrs" (UTC?) but all other apps and webpages and programs I have don't have this problem - my php.ini does contain "date.timezone = Europe/Zurich"):
#####=========
INFO CoreConsole17:00:01 [d31dc] ---------------------------
INFO CoreConsole17:00:01 [d31dc] INIT
INFO CoreConsole17:00:01 [d31dc] Piwik is installed at: http://access.blah
-blah.ch/index.php
INFO CoreConsole17:00:01 [d31dc] Running Piwik 2.2.3-b4 as Super User
INFO CoreConsole17:00:01 [d31dc] ---------------------------
INFO CoreConsole17:00:01 [d31dc] NOTES
INFO CoreConsole17:00:01 [d31dc] - Reports for today will be processed at
most every 3600 seconds. You can change this value in Piwik UI > Settings > General Set
tings.
INFO CoreConsole17:00:01 [d31dc] - Reports for the current week/month/year
will be refreshed at most every 3600 seconds.
INFO CoreConsole17:00:01 [d31dc] - Archiving was last executed without err
or 24 min 0s ago
INFO CoreConsole17:00:01 [d31dc] - Will process 1 websites with new visits
since 24 min 0s , IDs: 1
INFO CoreConsole17:00:01 [d31dc] ---------------------------
INFO CoreConsole17:00:01 [d31dc] START
INFO CoreConsole17:00:01 [d31dc] Starting Piwik reports archiving...
INFO CoreConsole17:00:02 [d31dc] Archived website id = 1, period = day, 180 visits in last 2 days, 87 visits today, Time elapsed: 0.371s
INFO CoreConsole17:00:02 [d31dc] Archived website id = 1, period = week, 922 visits in last 2 weeks, 288 visits this week, Time elapsed: 0.346s
INFO CoreConsole17:00:02 [d31dc] Archived website id = 1, period = month, 3875 visits in last 2 months, 1061 visits this month, Time elapsed: 0.347s
INFO CoreConsole17:00:03 [d31dc] Archived website id = 1, period = year, 68376 visits in last 2 years, 14119 visits this year, Time elapsed: 0.350s
INFO CoreConsole17:00:03 [Archived website id = 1, 4 API requests, Time elapsed: 1.417s 1/1 done
INFO CoreConsole17:00:03 [d31dc] Done archiving!
INFO CoreConsole17:00:03 [d31dc] ---------------------------
INFO CoreConsole17:00:03 [d31dc] SUMMARY
INFO CoreConsole17:00:03 [d31dc] Total visits for today across archived websites: 87
INFO CoreConsole17:00:03 [d31dc] Archived today's reports for 1 websites
INFO CoreConsole17:00:03 [d31dc] Archived week/month/year for 1 websites
INFO CoreConsole17:00:03 [d31dc] Skipped 2 websites: no new visit since the last script execution
INFO CoreConsole17:00:03 [d31dc] Skipped 0 websites day archiving: existing daily reports are less than 3600 seconds old
INFO CoreConsole17:00:03 [d31dc] Skipped 0 websites week/month/year archiving: existing periods reports are less than 3600 seconds old
INFO CoreConsole17:00:03 [d31dc] Total API requests: 4
INFO CoreConsole17:00:03 [d31dc] done: 1/1 100%, 87 vtoday, 1 wtoday, 1 wperiods, 4 req, 1465 ms, no error
INFO CoreConsole17:00:03 [d31dc] Time elapsed: 1.465s
INFO CoreConsole17:00:03 [d31dc] ---------------------------
INFO CoreConsole17:00:03 [d31dc] SCHEDULED TASKS
INFO CoreConsole17:00:03 [d31dc] Starting Scheduled tasks...
INFO CoreConsole17:00:03 [d31dc] No task to run
INFO CoreConsole17:00:03 [d31dc] done
INFO CoreConsole17:00:03 [d31dc] ---------------------------
#####=========

When I now go to the dashboard of website #1 and have a look at any goal I have to wait for the usual 40 seconds - once that first goal has loaded/is displayed any other goal of website #1 loads immediately.
If I switch to website #2 the same happens again: 40 seconds for the first goal, and then the others display immediately.

And again: this happens only with the goals - all other stats behave as I expect.
Thx

you're using 2.2.3 could you first check to upgrade to 2.3.0 ? I don't think this will fix it, but it's important to be sure :)

I'm reopening the ticket. if you can confirm bug in 2.3.0 please set priority to 'major' and I'll investigate before next release!

Hi
Upgraded to 2.3.0 => same behaviour. Just after running manually "/usr/bin/php /var/www/localhost/blah-blah.ch/access/console core:archive --url=http://access.blah-blah.ch" going to any goal took ~2 minutes in order to display it (HDD write-activity during the whole duration of the wait).
Thx

I've just read again your ticket description and now I understand the problem. It actually works as intended!

What's happening is that the Goal report, uses segments to process NEW vs Returning visits. Segmented data by default are still allowed even when the archiving is setup. It is possible to tell Piwik to disable ALL browser trigger archiving. This is done by setting this setting to 1 under [General] in your config file.

; if browser trigger archiving is disabled, API requests with a &segment= parameter will still trigger archiving.
; You can force the browser archiving to be disabled in most cases by setting this setting to 1
; The only time that the browser will still trigger archiving is when requesting a custom date range that is not pre-processed yet
browser_archiving_disabled_enforce = 0

I probably should mention this in the User Guide for archiving!

see also #4569 Add feedback message when a segment is used, and browser_archiving_disabled_enforce = 1

I've updated the user guide: http://piwik.org/docs/setup-auto-archiving/

and added:

By default, when you disable browser triggers for Piwik archiving, it does not completely disable the trigger of archiving as you might expect. Users browsing Piwik will still be able to trigger processing of archives in one particular case: when a Custom segment is used. To ensure that users of your Piwik will never trigger any data processing, in your config.ini.php file you must add the following setting below the [General] category:

; disable browser trigger archiving for all requests (even those with a segment)
browser_archiving_disabled_enforce = 1

Great, thanks a lot!! :)