Preferred Aggregator Site for Boinc projects

Major Tom MIB, Sun May 06 2007, 03:42PM

Cool, just saw your link Credit statistics web sites and services.

Should I make this my 'one-stop' for all my Boinc Stats needs?

Any preference on downloading the full user.xml.gz file verses hitting up get_user.php on demand?

I just recently started a Boinc Stats forum Signature service and so far I've only added 36 projects. I'm currently using the stats from each of the projects' servers. From what I've read, that's not the preferred way.
Re: Preferred Aggregator Site for Boinc projects
James, Mon May 07 2007, 02:40PM

I guess it depends. I would use the following guidelines:

  • If you need ALL or a significant number (100+) of the users, then download and use the user.xml.gz file
  • Please note the stats only update once a day. I'd greately appreciate only downloading the user.xml.gz file once a day, or if using the RPC, some kind of caching on your side (ie, make one RPC per user per day).


As far as I know, there isn't anything wrong with grabbing the stats from each project on your own and doing all the work yourself. It's just, uhm, more work for you.
Re: Preferred Aggregator Site for Boinc projects
Major Tom MIB, Mon May 07 2007, 06:15PM

Thanks. I won't know for some time if I'll have much demand--the signatures are still under development. The hardest part seems to be finding all the different projects--adding their link into the wget queue is easy.
Re: Preferred Aggregator Site for Boinc projects
Major Tom MIB, Tue May 08 2007, 06:12PM

I'm missing the 'last' user.gz files for a few projects like BBC, LHC, RenderFarm, and maybe a few others. Do you know where I can get a copy of them? I'd like to avoid 'extracting' the older projects from your aggregated stats. Thanks--it'll save me a lot of time.
Re: Preferred Aggregator Site for Boinc projects
James, Thu May 17 2007, 01:10PM

check your email - you should have a link to the files.
Re: Preferred Aggregator Site for Boinc projects
Major Tom MIB, Thu May 17 2007, 04:28PM

Thank you, I needed those smile3

They'll be available at http://boincstatsmirror.technutopia.net
Re: Preferred Aggregator Site for Boinc projects
Major Tom MIB, Sun Sep 30 2007, 12:53AM


I guess it depends. I would use the following guidelines:

  • If you need ALL or a significant number (100+) of the users, then download and use the user.xml.gz file
  • Please note the stats only update once a day. I'd greately appreciate only downloading the user.xml.gz file once a day, or if using the RPC, some kind of caching on your side (ie, make one RPC per user per day).


As far as I know, there isn't anything wrong with grabbing the stats from each project on your own and doing all the work yourself. It's just, uhm, more work for you.

James
What's the least 'intrustive' test to verify the stats have been updated for requests using RPC? I'm planning to setup a cache of the RPC results I receive and I'd like to 'know' when I should flush the cache. Thanks.

Also is this message temporary?

<b>Error performing query: Table 'boincstats.hosts_totals_exp' doesn't exist</b>
Re: Preferred Aggregator Site for Boinc projects
James, Mon Oct 01 2007, 09:01AM

I guess it depends. I would use the following guidelines:

  • If you need ALL or a significant number (100+) of the users, then download and use the user.xml.gz file
  • Please note the stats only update once a day. I'd greately appreciate only downloading the user.xml.gz file once a day, or if using the RPC, some kind of caching on your side (ie, make one RPC per user per day).
As far as I know, there isn't anything wrong with grabbing the stats from each project on your own and doing all the work yourself. It's just, uhm, more work for you.

James
What's the least 'intrustive' test to verify the stats have been updated for requests using RPC? I'm planning to setup a cache of the RPC results I receive and I'd like to 'know' when I should flush the cache. Thanks. Also is this message temporary? Error performing query: Table 'boincstats.hosts_totals_exp' doesn't exist

Major Tom MIB
What url are you using? That doesn't look like one of my current table names. As for the cache time, if you could do a 1 day resolution (I don't update more than once a day), that would be great. Or maybe 1/2 a day to perhaps catch the update a bit quicker.