@weixuezhang the solution would be to set up auto archiving see https://matomo.org/docs/setup-auto-archiving/ . When you then fetch a report it won't need to generate any reports. Fetching archived data is quite fast and there we aren't planning to change anything.

For range dates there is an issue already: #7573 . We will look into this more as part of #7573 and therefore marking this as a duplicate @weixuezhang

I have set up auto archiving with below settings in config.ini.php
browser_archiving_disabled_enforce = 1
enable_browser_archiving_triggering = 0
archiving_range_force_on_browser_request = 1

I add below code at head of method "public function query($sql, $bind = array())" inside file "/matomo-4.4.1/core/Db/Adapter/Pdo/Mysql.php"
Log::info("sql start time: " . microtime(true));
Log::info("sql: $sql");
Log::info("bind: " . var_export($bind, true));

From matomo.log, I can see below infomation, looks metrics are fetched from several plugins, but actually only ["nb_visits","nb_uniq_visitors"] for key viewDataTableParameters_admin_VisitsSummary.getEvolutionGraph inside option table, should only VisitsSummary plugin be related.

INFO VisitsSummary[2021-09-01 11:58:27 UTC] [cc6bb] sql: SELECT idsite, date1, date2,
INFO VisitsSummary[2021-09-01 11:58:27 UTC] [cc6bb] GROUP_CONCAT(CONCAT(idarchive,'|',name,'|',value) ORDER BY idarchive DESC SEPARATOR ',') AS archives
INFO VisitsSummary[2021-09-01 11:58:27 UTC] [cc6bb] FROM matomo_archive_numeric_2021_08
INFO VisitsSummary[2021-09-01 11:58:27 UTC] [cc6bb] WHERE idsite IN (1)
INFO VisitsSummary[2021-09-01 11:58:27 UTC] [cc6bb] AND ((name IN ('done','done.VisitsSummary')) AND (value IN (1,3,4,5)))
......
INFO Referrers[2021-09-01 12:12:44 UTC] [3ff11] sql: SELECT idsite, date1, date2,
INFO Referrers[2021-09-01 12:12:44 UTC] [3ff11] GROUP_CONCAT(CONCAT(idarchive,'|',name,'|',value) ORDER BY idarchive DESC SEPARATOR ',') AS archives
INFO Referrers[2021-09-01 12:12:44 UTC] [3ff11] FROM matomo_archive_numeric_2021_08
INFO Referrers[2021-09-01 12:12:44 UTC] [3ff11] WHERE idsite IN (1)
INFO Referrers[2021-09-01 12:12:44 UTC] [3ff11] AND ((name IN ('done','done.Referrers')) AND (value IN (1,3,4,5)))
......
INFO PagePerformance[2021-09-01 12:12:44 UTC] [3ff11] sql: SELECT idsite, date1, date2,
INFO PagePerformance[2021-09-01 12:12:44 UTC] [3ff11] GROUP_CONCAT(CONCAT(idarchive,'|',name,'|',value) ORDER BY idarchive DESC SEPARATOR ',') AS archives
INFO PagePerformance[2021-09-01 12:12:44 UTC] [3ff11] FROM matomo_archive_numeric_2021_08
INFO PagePerformance[2021-09-01 12:12:44 UTC] [3ff11] WHERE idsite IN (1)
INFO PagePerformance[2021-09-01 12:12:44 UTC] [3ff11] AND ((name IN ('done','done.PagePerformance')) AND (value IN (1,3,4,5)))
......
INFO Goals[2021-09-01 12:12:44 UTC] [3ff11] sql: SELECT idsite, date1, date2,
INFO Goals[2021-09-01 12:12:44 UTC] [3ff11] GROUP_CONCAT(CONCAT(idarchive,'|',name,'|',value) ORDER BY idarchive DESC SEPARATOR ',') AS archives
INFO Goals[2021-09-01 12:12:44 UTC] [3ff11] FROM matomo_archive_numeric_2021_08
INFO Goals[2021-09-01 12:12:44 UTC] [3ff11] WHERE idsite IN (1)
INFO Goals[2021-09-01 12:12:44 UTC] [3ff11] AND ((name IN ('done','done.Goals','done.VisitsSummary')) AND (value IN (1,3,4,5)))
......
INFO Actions[2021-09-01 12:12:44 UTC] [3ff11] GROUP_CONCAT(CONCAT(idarchive,'|',name,'|',value) ORDER BY idarchive DESC SEPARATOR ',') AS archives
INFO Actions[2021-09-01 12:12:44 UTC] [3ff11] FROM matomo_archive_numeric_2021_08
INFO Actions[2021-09-01 12:12:44 UTC] [3ff11] WHERE idsite IN (1)
INFO Actions[2021-09-01 12:12:44 UTC] [3ff11] AND ((name IN ('done','done.Actions')) AND (value IN (1,3,4,5)))

@weixuezhang fyi if you have disabled the archiving in the config then you also need to set either enable_general_settings_admin = 0 or disable the browser archiving in the UI.

Can you maybe log more information like what the exact URL is for that request? and show how long it took to fetch the reports? Is the page slow for you?

@tsteur , I set enable_general_settings_admin = 0, but log result is same as previous. URL of the request is like blow. It is the URL of report "Visits Over Time"
http://localhost/matomo-4.4.1/index.php?forceView=1&viewDataTable=graphEvolution&module=VisitsSummary&action=getEvolutionGraph&idSite=1&period=range&date=2021-08-30,2021-08-31&segment=&showtitle=1&random=9682

After adding "columns=nb_visits" to the URL as below, I can see only VisitsSummary metrics is fetched, and the page shows faster several times than before. So, looks the problem is the report fetching all metrics (in stead of only that from option cache) when no columns set in URL parameters.
http://localhost.com/matomo-4.4.1/index.php?columns=nb_visits&forceView=1&viewDataTable=graphEvolution&module=VisitsSummary&action=getEvolutionGraph&idSite=1&period=range&date=2021-08-30,2021-08-31&segment=&showtitle=1&random=9682

Thanks @weixuezhang . I'll reopen the issue again as this is bit different as the other referenced issue. I'm not sure we will work on it too soon though as usually fetching these reports is quite fast.

Do you have a performance problem there or how came you looked into it @weixuezhang ? be great to know to understand implications better.

@tsteur , when I use comparison features on long period of date, I noticed the performance problem. I also found the time consumed by SQL query of obtaining archiveId for metrics on each plugin is the major portion (about 80%) of the overall query time, and also a major portion of the whole report time. So, if we can get rid of the unneeded metrics queries, the report will be several times more faster.

BTW @weixuezhang you might want to test this change if it improves the situation maybe a little bit: https://github.com/matomo-org/matomo/pull/17943/files

@tsteur , I tested your change, but matomo.log still shows the unneeded sql queries. I also tested the cases of URL parameter period equaling day, week and month, problem is the same. I tried a temp change as https://github.com/matomo-org/matomo/pull/17954/files, the unneeded queries can disappear, but I'm not sure it is the right fix, and if it causes other problems.

Maybe slightly related. Noticed

        $multiSites = Request::processRequest('MultiSites.getAll', array(
            'period' => 'range',
            'date' => $from . ',' . $to,
            'showColumns' => 'nb_actions,nb_pageviews',
            'filter_limit' => -1
        ));

Can take a very long time. And in my case it created 1000 archive entries, 400 unique archive IDs (one for each site plus 3 or 4 segment archives per site).

I don't know if this can be avoided or improved. And not 100% sure it's related

Above suggested PR would not fix that one

I would like to add that I also have problems with the display of the widget "Visits over time" in all of my clients' installations. Whenever a user has selected any segment, this widget takes a very long time (usually the web server timeout stops).
It is always the following example POST request that takes the long time https: //myserver/index.php?segment=deviceType%3D% 3Ddesktop&date=today&forceView=1&viewDataTable=graphEvolution&module=VisitsSummary&action=getEvolutionGraph&disableLink=0&widget=1&idSite=1&period=month

Auto archiving is always active and browser archiving is inactive.

I'm not sure that is important to this problem

@utrautmann you might want to put this additional configuration into config/config.ini.php as part of the [General] section: browser_archiving_disabled_enforce = 1. Otherwise segments may still be archived while being requested from the browser. It's partially mentioned in https://matomo.org/docs/setup-auto-archiving/#more-information-about-matomo-archiving

@utrautmann do you know if the segment is configured to be "pre-processed" or to be processed in "Real time"? You can find out when editing that segment.

@tsteur All segments in the affected client installations are configured to be "pre-processed". But browser_archiving_disabled_enforce is actually set to 0. I will make a change.

Thanks for this @utrautmann I'm expecting this will help. I've also created a PR in #18123 so that it won't be needed to set this config in that case.

Thanks for your answer @tsteur . The "Visits Over Time" widget now renders faster.

Thanks for contributing to this issue. As it has been a few months since the last activity and we believe this is likely not an issue anymore, we will now close this. If that's not the case, please do feel free to either reopen this issue or open a new one. We will gladly take a look again!