Project usage/download/install statistics not being generated in a timely manner

If #2129811: Reported install usage statistics count on the project page is not being updated is resolved before this, all projects will show 0 usage on their project page as well. I moved this to critical since the module, theme, and distribution lists are all sorted by number of installs by default. Not getting this resolved in going to result in a very negative Drupal.org user experience. Hopefully this data was captured and just isn't being processed.

https://drupal.org/project/usage/views
https://drupal.org/project/usage/zen
https://drupal.org/project/usage/commerce_kickstart

The current usage appears to be fixed for most projects and may only be impacting distributions also effected by #2127355: Supported release not showing on project page for distributions now...

0 usage:

https://drupal.org/project/usage/erpal
https://drupal.org/project/usage/civicrm_starterkit

Some usage:

https://drupal.org/project/usage/commerce_kickstart
https://drupal.org/project/usage/openfed

May potentially be related to #2133385: project_generate_download() query needs porting to D7 structure.

Lowering priority and updating title per #3.

This issue relates to the following irregularities in project statistics:

1. Project usage statistics for the week ending Nov 3rd are Zero
2. Graph shows statistics up to October 27th, however...
3. Project page shows usage statistics only up to October 20th, some 22 days ago.

Not all projects show all three problems, larger projects such as Drupal Core, Libraries API etc. are not affected by 1. above, but seem to be affected by 2. and 3.

For recently launched, smaller projects such as mine here: https://drupal.org/project/usage/neat_scrollbar , the problem is evident.

Also whereas downloads (as opposed to installs) were updating daily, this is no longer working.

Updated the title to help people find it more easily, through the keyword "statistics". I had raised this issue as a duplicate because it is difficult to find based on the current title.

@davidmac The download issue is being tracked in #2129811: Reported install usage statistics count on the project page is not being updated

@kreynen thanks, as both issues relate to the same topic (usage/downloads/statistics), perhaps it's worth merging them into one issue.

@davidmac,

I am maintaner of Bluez Theme. All the issues you mentioned at comment-6 are visibile with my Project/Theme.

Have a look : https://drupal.org/project/usage/bluez

Any update on this issue ?

Thanks,
Ujval

@Ujval Shah I agree that it would be helpful to have some update/explanation as to the posssible cause and/or resolution. At the moment, it appears that larger projects are prioritised for some reason, but lacking any explanation, we can only guess.

Also the comment in #3 above suggesting a link with the release version issue does not appear to be the case, for all projects.

The Graph issue seems to be fixed, so thanks to the Drupal.org team for that.

I don't believe this is fixed per #12, in a new strange twist, stats seemed to have been updated only yesterday for November 2 for my project, Gratis and today for stats for November 9th but the 9th shows the graph dipping to zero so that seems to be the old issue before the D7 upgrade.

Yeah, it's still ongoing, mine isn't showing zero on the graph anymore but appears to be a week behind your graph. Looking at the dates, it seems that themes and modules are updated on a different schedule.

For the cause, see comment #4.

Everything (both modules and distributions) reporting 0 usage again this week.

https://drupal.org/project/usage/views
https://drupal.org/project/usage/commerce_kickstart

Another example:
https://drupal.org/project/usage/ubercart

One more is https://drupal.org/project/usage/node_expire

The project/usage/<module> page shows three things:
1) Graph (under the heading "Weekly project usage")
2) Breakdown of usage by date (also under the heading "Weekly project usage")
3) Breakdown of usage by project version (under the heading "Recent release usage")

The third item hasn't been mentioned yet in this thread. All three have old statistics that aren't getting regenerated in a timely manner.

For example, at https://drupal.org/project/usage/ubercart you can see that items 1) and 3) (and also the number of installs shown on the project page) haven't been updated since 19 October. Item 2) was last updated on 3 November.

I've updated the title to reflect the nature of the discussion from comments #6 & up.

EDIT: Corrected date.

Comment #19 outlines 3 problems. Problems 1 and 2 appear to be tied together and it's been noted that their resolution is dependent on #2133385: project_generate_download() query needs porting to D7 structure. Is it also correct to say that the resolution to the 3rd problem (the "usage by project version" report data) is linked to #2133385, or is this a separate issue entirely?

It would also seem that the overall "weekly" statistics by branch for most projects have started to update on a weekly schedule again, and data is available now through last week (starting Nov 16th). However data for a very select few projects (such as the Ubercart example) is still stuck on stats from Nov 2nd or 3rd. Does this mean that there is a project-specific variable at play? Is there a reason that the aggregation of this data is skipped for only some projects (e.g. does something like issuing a release or a certain number of commits affect if/how/when these stats get aggregated)?

I would say Problems 1 and 3 appear to be tied together, because both the graph and the breakdown by project version have last update days of 19 October (in my #19 example), while problem 2 has a different, more recent last update of 3 November.

Look at Views for a similar example - the Views graph and breakdown by project version also haven't been updated since 19 October, but problem 2 (breakdown by date) was last updated on 16 November.

Is there a reason that the aggregation of this data is skipped for only some projects (e.g. does something like issuing a release or a certain number of commits affect if/how/when these stats get aggregated)?

Ubercart is one of the most active projects on drupal.org, and has been for several years. I think it is unlikely that this problem is triggered by lack of project activity.

I would say Problems 1 and 3 appear to be tied together...

Do you mean problems 1 and 2 are tied together (not 1 and 3)? As far as I can tell, the "weekly project usage" graph (prob 1) and table (prob 2) are always in sync (though they may be outdated or show 0 in these problem cases). It looks like views project usage graph and table both have data through the week of Nov 16th, and the Ubercart project usage graph and table has data through Nov 10th (but only "real" data through Nov 3rd)... so the table and graph are in sync for both, but only Ubercart has bad/outdated data. The "recent release" data (prob 3) for all projects seems to be equally outdated (Oct 19th being the latest across the board).

Also, I think you're right in that the activity/popularity of a project is not correlated to the stat update frequency. I was just wondering if some other activity patten could cause the project to be skipped during an update interval (e.g. a release was pushed on the same day some usage stat script happens to run, etc.).

You're right it should be 1 and 2.

I really did mean 1) and 3), but it appears I misread the graph - it looked like it ran only through mid-October but looking more closely the ticks are quarterly (every three months) so although I can't tell exactly when the graph ends it does appear to be mid-quarter, which is mid-November.

So yes, you're right, problems 1) and 2) are tied together.

Graph is now updated for most of my projects, but Anonymous Publishing usage still shows zero for November 17 (1 and 2).

Recent release usage (at the bottom of the graph page) has not been updated since October 20 (3).

Usage number on project page has not been updated since October 20 (4).

The last two issues affect all my projects.

Added the four issues involved to the issue summary.

I've update the issue summary to include the fact that the number of downloads, which was updated daily, has been broken since the onset of this problem. This was a handy way to see indicative usage in advance of the weekly update of installs. i.e. downloads versus installs. Also, it is the only indicator of downloads anwhere within the stats, so is important, particularly when we know that a lot of sites don't report usage.

I took the liberty of creating a summary based on the issue queue template. As most users probably don't know much about the technical specifics of the usage tracking scripts I guess a good articulation of the problem is our best contribution at this point. Maybe this can serve as a useful "parent" issue for those familiar with the scripts that need attention and the related child issues.

@rjacobs You've amended No.5 in the issue summary.

(the data of onset for this needs to be confirmed).

Is there a typo there, should that be date?, if so I can confirm that this was broken from the date of my comment #6 above and a few days before that.

Ok, I adjusted the summary to add that detail about the downloads stat problem timing. Feel free to edit at will. I personally have no special expertise or authority on this issue (I just wanted to make our observations more easily accessible in the summary).

At some point in the last few days it looks like the example projects showing problem #1 (Ubercart, Anonymous Publishing, Juicebox) have "caught up" with the majority of other projects, and now have updated weekly usage stats. I don't know if this means anything was fixed/changed, but I've removed them as demonstrative examples in the summary to avoid confusion.

The descriptions and symptoms for problems 2-5 remain unchanged.

Just adding to the noise. This is happening for https://drupal.org/project/bootstrap as well

Project page: 11,440 installs
Usage page: 13,387 installs

Also, seeing the #3 issue: the new 7.x-3.0 release doesn't appear

One quick nugget of info related to prob #3 that might be useful to some people... It appears that the usage statistics for each release are still being collected, and are available for viewing on d.o. It's just the aggregate summary table on the project usage stat page that's not being updated (since Oct.). If you click on the individual release links in this "Recent release usage" table you should be able to access a graph and table with stats, just for that release, which will most likely be up-to-date within a week or so.

Looking at the Backup and Migrate module as an example (https://drupal.org/project/usage/backup_migrate), the aggregate data in the table only goes to Oct 19th (like all projects), but specific stats, for say 7.x-2.7, are available through last week at: https://drupal.org/project/usage/1996614

This also works for releases pushed after Oct 19th, that don't appear in the "Recent release usage" table at all. For example, Backup and Migrate 7.x-2.8 is not in the aggregate table, but it's release ID (2128465) can be found via the "all releases" list and then it's usage stats can be accessed at: https://drupal.org/project/usage/2128465

Perhaps this is handy for anyone who's really jonesing for fresh data while these issues get resolved.

With respect to points 4 & 5 from the issue summary, here are extracts from comment #7 through #9 in related issue #2129811:

• I don't think the previous description of 'not being updated in a timely manner' can hold when we are seeing projects where the reported installs and downloads are not updated at all (as stated in #3 on Nov 21st).
• There is also the added irk that the 'last updated' date in this section of the project page seems to be 'updating' whilst the reported statistics have been static for over a month now.
• While stats for the module as a whole still seem to tick along (in the graphs only), any RELEASE-SPECIFIC data for releases after 20 Oct isn't on the project page or anywhere.
• An important special case of this is that any new modules released after 20 Oct 2013 have NO download stats or usage stats at all.
• Newbie developers as well as old developers with newbie modules thrive on this sort of initial feedback.
  Please don't deprive them!
• I would prefer to have this section of the project page hidden until it is fixed, thereby forcing people to look at the graph (which I suspect remains buggy). Presumably this could be done easily enough?
• Any feedback from the Drupal.org upgrade/webmaster team would be welcome.

I would prefer to have this section of the project page hidden until it is fixed

I agree with @davidmac. It would be better not to show the information that to have incorrect information on the front page of a project.

#davidmac #35, @yanniboi #36

Not a bad suggestion indeed.
Having that section of the project page hidden until it is fixed would give everyone the same unfair disadvantage, so to speak

Rik

I updated the child issues.

For downloads: #2133385: project_generate_download() query needs porting to D7 structure is committed and looks okay. Next step is to restore logs at /var/log/DROP/drupal-awstats-data on util.

For usage: #2129811: Reported install usage statistics count on the project page is not being updated. Next step is to run usage stats again and see what happens.

For testing in the future: #2153419: Staging should have access to update status logs

Updating the title to match the summary.

util.drupal.org had some disk space issues. nnewton is optimizing the Mongo DB to regain space. This is routine, it has to happen approximately every 2 months. A long-term fix would involve the Mongo-related code in http://drupalcode.org/project/project.git/blob/refs/heads/7.x-2.x:/usage....

Once this is done, the Jenkins jobs related to usage and downloads can be run and we can see what problems remain, or if they are fixed. This will take a day or two.

Thanks drumm. I updated the "resolution" notes in the summary based on new info.

After a few followup commits to remove notices, updating downloads completed. Anyone want to sanity check the reported numbers on project pages?

As mentioned in the child issue, the download field has updated over night.

In terms of sanity check, the ratio of installs to downloads tends to be around 10-12% as a minimum average (themes and modules), but can be much higher for other projects such as Libraries API (22%), Views (14%), Module Filter(17%), Admin Menu (16%).

So it would appear to be in the ballpark with with last nights figures.

However, in the abscence of an historic downloads column in the usage table, it is difficult to tell exactly, and would require those with access to the database to perfom a sanity check, if historical download data exists.

In saying that, each module maintainer should have a feel for the trend in downloads and the resulting usage/downloads ratio.

As pointed out here https://drupal.org/comment/8255251#comment-8255251, newer modules seem to have been more affected than more established ones.

Also, the usage seems to be buggy with a levelling off and/or unexpected drop reported across many modules in the last weekly update.

Here's my go at a sanity check!

The table below shows some historic download data I've kept for three of my projects. The final column (Daily) is the sanity check. It computes the average daily number of downloads for all the days in the the interval between the date in the first column and the date preceeding it.

As you can see, the numbers for the interval ending today (2013-12-11) are in the same ballpark as the downloads for the project in the previous intervals. The odd number out: The 98 average daily downloads for Custom Error in the 42 days between 2013-07-03 and 2013-08-14 is probably because the first significant new release for both D6 and D7 branches since 2011-10-03 occurred within that time frame.

Anonymous Publishing                
Date       Days Downloads Diff Daily
2013-07-03          823
2013-09-04  63      895     72   1.1
2013-10-14  40      957     62   1.6
2013-11-01  18      972     15   0.8
2013-12-11  40     1004     32   0.8
-
Custom Error                
Date       Days Downloads Diff Daily
2013-07-03        26609        
2013-08-14  42    30724   4115  98.0
2013-11-01  79    32714   1990  25.2
2013-12-11  40    33517    803  20.1
-
Flexi Access                
Date       Days Downloads Diff Daily
2013-02-17         1753        
2013-07-03 136     2395    642   4.7
2013-12-11 161     3087    692   4.3

In other words, these numbers look sane, and the downloads now appear to be up to date.

My congratulations to everyone that participated in resolving this.

Since this has been re-purposed as a meta-issue, can we get someone to i) confirm that each of the items in the issue summary is still an issue, and ii) ensure that each has an associated child issue created and related to this meta? (Possibly combining #1/#2, and #3/#4, which may only need a single issue between them if not already solved.)

While the symptoms and underlying causes may be related, lumping every usage/download/statistics view into a single issue like this makes it difficult to keep tabs on i) what is currently working and what is not, ii) where the different pages/views are coming from, and iii) what is the current state of any potential patches being proposed for each page/view. Handling each page/view in a dedicated issue makes things much easier for folks trying to do the troubleshooting.

I maintain four projects. For all those, Weekly project usage stats graph/table and Number of Downloads on project page are fixed.

Issues Breakdown of usage by project version and Number of reported installs on the project page are not fixed. Both statistics are stuck at Oct. 20.

As pointed in comment #34 above, and in the summary, the stats for issue Breakdown of usage by project version are collected, and can be viewed if one uses the method described. It is just the aggregate that isn't updated.

Edit: Replaced numbers with strings, at latest edit (comment #47) of issue summary changed numbering.

Regarding the recent fix for the number of downloads on the project page, I have seen no daily change in this number since the fix on my relatively recent project https://drupal.org/project/neat_scrollbar, this is the opposite of the trend when everthing was working fine, when it saw 10-20 downloads per day approx.

Also I've recently created two further recommended releases taking this project from 7.x-1.1 two upticks to 7.x-1.3. There is no sign of those in the 'Recent release usage' table.

This bring us back to various comments above and in the child issue that recently published modules are being affected more negatively than established ones. To date there has been no comment from those 'in-the-know' one way or the other on this point.

If feedback shows that the 'release update' is an additional problem for others, I am happy to update the issue summary.

Also given the ongoing nature of this problem and without wanting to slam the hard work being done, I feel that less emphasis should be placed on housekeeping and organising the issue description and more emphasis placed on providing feedback to module/theme contributors with respect to concerns raised and what investigations over the last 6 weeks have uncovered, if only to help restore confidence in the statistics as reported.

To date there has been no comment from those 'in-the-know' one way or the other on this point.

There is no comment, because noone is 'in the know' about the speculation that 'recent' releases are somehow treated differently than 'non-recent' releases, despite the fact that they all use the same scripts to generate statistics. I think you're looking for something that doesn't exist.

I feel that less emphasis should be placed on housekeeping and organising the issue description and more emphasis placed on providing feedback to module/theme contributors with respect to concerns raised and what investigations over the last 6 weeks have uncovered.

I'm a bit offended at the suggested inference that something is being held back from contributors ... you can dig as deep as you want, but there is no conspiracy here. The fact is that keeping the issue description current helps those performing the troubleshooting, as it prevents them from wasting time tracking down and learning the code paths for issues that have already been solved. It's a drupal best practice, encouraged in any queue. Hell ... we even have entire 'issue summary initiatives' in core which do nothing BUT going back and updating issue descriptions for outstanding issues.

As for this issue itself ... I did some digging yesterday after a helpful hint from drumm. There is a drush script that is used to parse varnish logs and build the usage statistics, which is triggered by a scheduled job in our jenkins server. This script did not run between October 31st and December 7th, but has attempted a daily run since. Upon execution, this script is throwing two different types of PHP notices (and eventually failing the jenkins build).

One of the notices is due to some data corruption in the database (roughly a dozen releases which have a non-project node in their 'parent project' field), and the other is due to an error in the log parsing itself (still haven't sorted it out exactly, but it's expecting strings of the form "key=value", but not finding the '=' sign).

The function is located at http://drupalcode.org/project/project.git/blob/refs/heads/7.x-2.x:/usage..., with the exception occuring at line 264 ... but the log files it parses is on a server that requires a fairly high level of Drupal infrastructure access.

Good to see some progress.

Stating the obvious here, but perhaps someone with access there can post a log file so people can have a look?

re:#49

The phrase 'in the know' is used to delineate between those that have access to data vs those that don't, it has nothing whatsoever to do with your suggestion about 'conspiracy theories', but then again that's obvious. The comment above highlights this difference:

perhaps someone with access there can post a log file so people can have a look

Nothing I wrote in the comment you refer to could be reasonably construed as anything other than polite feedback, and I find any suggestion to the contrary to be deeply cynical and overly defensive. I'm afraid your interpretation places a spin on things which delves into conspiracy theories and fictional inferences, which simply aren't there.

The fact remains that comments made by others that some new modules are not receiving any stats at all, went unanswered, and my remarks simply pointed this out. There has been an obvious difference in statistics reporting between more established projects and less established ones throughout this issue, as pointed out by various people. Despite the scripts being the same, people have reported differences, and I think we can all agree that we have a joint objective to understand these differences.

Changed issue description to move number 3 (number of downloads) back into unresolved, as it is not updating for everyone.

Following on from previous comments I can confirm that established projects such as Views, Libraries, Features are today showing updates in the stats table to 8th December whereas newer projects such as Neat Scrollbar are showing updates to 1st December only. There are no stats showing for modules such as Entity Lister Example, Social Comment, Batch Jobs and many others.

Downloads

I found a new issue, #2157887: Project download statistics not recorded for new releases. I expect this could be the final issue for downloads; it involves the UPDATE query at the very end of the process.

Usage

I updated #2129811: Reported install usage statistics count on the project page is not being updated with the current status.

The DB servers currently kill any query taking longer than 25 seconds because of #2136119: Text search on issue queues is slow and sometimes WSODs. That query killer is killing the saving usage data to MySQL, so we likely won't be able to fully fix usage data until that is done.

I added some instructions for implementing #2157887: Project download statistics not recorded for new releases, which is nearly a novice issue, if anyone wants to try out working on it. An UPDATE query should be replaced with proper use of field collection's API.

I've updated the summary based on comments #53 and #54 and removed a "related" issue #2129811 (since it's already listed in the issue relationships as a "child" issue). I think there are mixed feelings about the value of a parent issue like this, but given that there are many people following this and several dups pointed here, I figure it can't hurt to keep that summary up-to-date. I've also re-numbed the issue items to match the numbers referenced in the comments (this was broken when we split-out resolved vs unresolved lists).

Also @drumm, do you think it's safe to say that both issues #3 and #4 (which reference different interfaces but relate to usage stats) can be tied to a resolution of #2136119: Text search on issue queues is slow and sometimes WSODs?

I started an 8.x branch with a dev and alpha release for my project a few weeks ago and I figured that would be enough time for it to show up in the stats but only my 7.x branch shows up. I'm not sure if I need to open a new issue for that or if it's sufficient to post here about it.

@highrockmedia
I've reported the same problem, and it has been kindly added to the issue description under (#3): Breakdown of usage by project version, so you're in the right place.

Regarding the issue description, I question whether the resolved issues are actually resolved. If lagging problems remain with differing stats tables for different modules can we say that this particular problem is resolved?

I suppose there was no definitive statement or commit that marked problems #1 and #2 as fixed. It looks like jthorson informally marked them as "resolved" in comment #47, probably based on some of the comments coming from drumm and reported observations that previously "stuck" usage stats (the overall ones, not the ones linked to specific releases) were updating reasonable normally once again. Anyway, there was a child issue attached to those at one point, but it turned out to be the wrong child issue. So yes, the status of those if not fully concrete.

In the context of this issue and queue I suppose it's not just a question of whether-or-not #1 and #2 are resolved, but whether-or-not the D7 upgraded has anything to do with those issues. After all, the timing of those stat updates was never really consistent even before the d.o. D7 upgrade. However it is clear now that that D7 upgrade did have some impact on all the other usage-reporting issues (#3 - #5).

Made at note that issue #5 does not affect all projects. For instance, this statistic changes daily for all my four projects.

Issue #5 seems to depend on child issue #2157887: Project download statistics not recorded for new releases being resolved.

Regarding the amendement to the issue description (#5), I don't want it to seem as if my project is of priority as it isn't, so I've removed the example you mentioned. The priority is to get it resolved for everyone.

Just to say that I'm seeing some changes in the download figure, although they aren't as expected (I had performed various downloads from different IP's as a test). This leads me to think that the logs in the intervening period have not been added back in, but start again from when the code was commited i.e. old total plus daily downloads from fix day. This isn't a major issue, just worth noting.

Although some problems remain, for my part, I'd like to say thanks for everyones efforts on this issue, it is appreciated.

I've also been puzzling over this with regards to several of my projects for a number of weeks (at least since the d.o. migration to D7).

Example: https://drupal.org/project/google_analytics_counter has 755 installs on the front page for many weeks, while on the usage stats page it shows 840. And on the usage stats page it shows 0 installs for D7 every week since September 18, 2011 (see https://drupal.org/project/usage/google_analytics_counter).

Further, there's another module - https://drupal.org/project/google_analytics_referrer - which doesn't even have the line "Reported installs" (even though I am sure there are several installs, if only on my sites).

I've been seeing this for months on the Demo Framework project - even before the D7 migration.

I wonder how that's possible, since the demo install was reset daily AFAIK. And why wasn't it reported by anyone, including you?

This likely has a different root cause, but is there is a problem with recording usage stats of 8.x? https://drupal.org/project/usage/572834 suggests Drupal 8 usage peaked in February 2013 and has been declining ever since, and somehow I doubt this is really the case.

Edited description and removed the "resolved issues" heading as the problems remain. Although I had seen some updates in the "project graph" and "stats table" this has dropped back to zero. https://drupal.org/project/usage/neat_scrollbar

Also, the reported installs on the project page has not been updated since October 2013, when the D7 upgrade occurred.

I know a lot of work hs been done to correct these problems, and I would grateful for any advice on where we stand with respect to a likely resolution.

Thanks.

@davidmac, the "project graph" and "stats table" going to zero on a Sunday is probably not related to the D7 upgrade. While slightly annoying, it is well known that this occur from time to time. These two are closely related and this also occured before the D7 upgrade. You'll probably see these stats updated by Tuesday evening.

I do not think removing the "resolved issues" heading for these two items is constructive.

I can't think of many opposites to constructive. As you know from my revision in #61, your own changes to the issue description are not always agreed with, but you weren't criticised for them.
Given the numerous changes to the issue description by many of us, we aren't always going to agree with each other, fortunately there are guidelines in place to help us avoid antagonistic remarks https://drupal.org/dcoc

I don't know if this is totally OT here, but since this "0 installs" phenomenon -though a known issue- seems to confuse people perhaps we should make it so that if stats are 0 for the very first (most recent) date row, then the specific row should be hidden till it is actually populated with values. Separate issue?

...#2176757: Hide the last date row in project stats page when it has no values. ;)

Problems #1 and #2 seem to demand special classification. On one hand they are unresolved issues, but on the other hand it's starting to appear that they may not be linked to the D7 upgrade (which is the context of this parent issue). This was not clear when this issue was opened, but some comments (such as #40 from drumm) seem to indicate that D7 changes are not the culprit. Setting up a dedicated issue for this (#2176757: Hide the last date row in project stats page when it has no values.) makes good sense, and I think it's worth noting that in the description as well.

Also, isn't #5 fixed now? Maybe I missed something but the linked issues are both marked "fixed".

In terms of updates, I'm not an authority, but my understanding is that #2136119: Text search on issue queues is slow and sometimes WSODs is still a big blocker on lots of things, and after a read-through of the comments it looks like there's been lots of activity over there recently (but no magic bullet solution).

The problem with project usage statistics being shown as zero in the stats graph (#1) and stats table (#2) has occured periodically since 2011 and is probably not related to the D7 upgrade. It usually sorts itself out by Tuesday. Looking at this old issue, it looks as if manually clearing the project statistics cache may sometimes be required.

Q: (#67) I would grateful for any advice on where we stand with respect to a likely resolution.

A: (#53) The DB servers currently kill any query taking longer than 25 seconds because of #2136119: Text search on issue queues is bringing the site down. That query killer is killing the saving usage data to MySQL, so we likely won't be able to fully fix usage data until that is done.

Status update: While a lot of work has been done on #2136119, I believe the 'killer query' is still in place. The usage stats for all projects are inserted with a single query, which exceeds the time allowed by the 'long query killer', so to speak. So as long as that query is in place, we won't see resolution of this issue.

That said, the last time I looked at the output of the usage calculation script in Jenkins, I did not see any other errors or exceptions being thrown in the calculation portion of the script ... the death of the insert query was the first and only indication of anything not working, and the cause of that is a known (and intentional) issue.

Hi everyone, thanks for all your comments and up-to-date issue summary. The status update in #74 is correct, we still have work to do on #2136119: Text search on issue queues is slow and sometimes WSODs and that is a priority this week. Additionally, we have one more critical issue to deal with still #1710850: Deploy RestWS for D7 project issue JSON. Depending on the progress on the 2 of them, we might be able to get to this one next week.

It is now Wednesday and problem that the "project graph" and "stats table" dropping back to zero on Sunday (problem #1 and #2 in the description, and noted in comment #67 above) has now gone away.

This is the same pattern that has repeated itself multiple times since 2011.

#1/#2 is not quite fixed for all projects this week; at the time of writing, https://drupal.org/project/usage/drupal shows data up to January 12 but https://drupal.org/project/usage/ubercart only has data up to January 5 - January 12 is missing entirely, not even shown as zero.

#2129811: Reported install usage statistics count on the project page is not being updated is fixed and the usage stats pages I see look normal. I think this fixes all the regressions since D6.

Yay! And it works for new modules created after 20 Oct 2013 too!
These new babies now have install counts on their project pages for the first time in their youg lives.
Sensational work drumm and all involved.

The statistics table at https://drupal.org/project/usage/ubercart is still out of date; it is showing six column headings but only four columns of data, the columns seem out of sync with the dates, and some releases are missing such as 7.x-3.6.

I released an 8.x branch of my project (dev and alpha both visible on the project page) back on November 23, 2013 and it still has yet to show up in the graphs and stats for my project. Is there still some delay involved here or should it show up eventually?

Usage stats for Drupal 8 don't seem to have been recorded properly since March 2013. I mentioned this in #66 and have also filed #2179741: Drupal 8 usage statistics not being recorded? in the core queue, as it's not obvious which end this problem lies.

FWIW, I had the exact same thing happen with https://drupal.org/project/usage/bootstrap. Only 4 out of 6 columns were appearing and the 7.x-3.0 release (which was after the D7 migration) wasn't showing up. I just checked and it's fine now, so maybe there's just some cron queue. Give it a little bit.

Am I missing the point here, but are we sure this is all fixed? The project overview https://drupal.org/project/usage is showing new dates in the headers, but the numbers are still stuck at three months out of date. The numbers for Druapl core for Jan 12, Jan 5, Dec 29 and Dec 22 are shown as 972,322, 971,897, 957,360 and 958,463. But according to https://drupal.org/project/usage/drupal these are the numbers for 20th, 13th, 6th Oct and 29th Sept. [these are right as I happened to record them separately back in Oct from the overview page].

Apologies if this is obvious and you've known about this all the time, but I did not see any talk previously about wrong values in the columns, only about zeros being shown or no new dates being generated.

There are some extra long-lived caches for usage stats pages. I believe they expire in 24 hours. If the pages do not fix themselves in a few hours, please re-open with an updated issue summary.

Just wanted to confirm we're now showing current usage stats at http://drupal.org/project/df

I know drumm said that there are some long-lived caches but I think we still have a problem that needs to be looked at, or atleast explained. There are discrepancies in the usages stats which are now two weeks out of date. Same problem as I reported in #84 the stats at https://drupal.org/project/usage/drupal show the core usage for 2nd Feb at 1,001,656 and 9th Feb at 1,015,705. But on https://drupal.org/project/usage the data does not match the column headings. 2nd Feb says 995,855 which was actually the number from 26th Jan according to the other page.

It is not so important that one page is two weeks behind the other, but the problem is that the column headings do not match the data being shown in those columns. This gives conflicting information.

Re-opening and setting this down to normal priority, hope that's OK. Just close it again if there is a good explanation and no more work is needed. Thanks.

jonathan1055:

Would you consider opening that concern as a new issue? It is not something that was discussed earlier in this issue; and I fear it could get somewhat lost in the noise with everything else that was dealt with in this thread ...

... Whereas with a new issue and clean issue summary, we can filter out that noise and focus on the specific issue you're mentioning.

Yes, sure. I've now opened #2202451: Two project usage pages give contradicting data
Thanks for the reply. Restoring the priority and status here, just to keep the records straight.

Jonathan

I just noticed that no statistics have been generated for the last two weeks (up until the last weekend of March).

Feel free to close this again if there is another issue about this that I missed. I just wanted to notify you of this problem.

Yes https://drupal.org/project/usage/drupal shows all zeros for 23rd and 30th March

Just to add that I have seen the same flatlining on several projects over the last two weeks:

Examples:
https://drupal.org/project/usage/libraries
https://drupal.org/project/usage/neat_scrollbar
https://drupal.org/project/usage/views
https://drupal.org/project/usage/panels

I confirm the same problem on ERPAL as a Distribution but also on many other projects.

#2176153: Reported installs on project page not updating / not correct is tracking the current problem. In general, new problems are unlikely to be Drupal 7 upgrade regressions.