Gerard, I like wikidata a lot, kudos to the community for keeping it going. But keep it real, there is no exponential growth here.
We are looking at a slow and sustainable growth at the moment with possibly a plateauing of number of users and when it comes to total number of wikidata items. just take a look at the statistics. Date | Content pages | Page edits since Wikidata was set up | Registered users | Active users 4/2015 | 13,911,417 | 213,027,375 | 1,913,828 | 15,168 5/2016 | 17,432,789 | 328,781,525 | 2,688,788 | 16,833 7/2017 | 28,037,196 | 514,252,789 | 2,835,219 | 18,081 7/2018 | 49,081,962 | 701,319,718 | 2,970,150 | 18,578 4/2019 | 56,377,647 | 931,449,205 | 3,236,569 | 20,857 When you refer to "growing like a weed". What's that page views? queries per day? Mentions in the media? Best, Marco On Fri, May 3, 2019 at 3:36 PM Gerard Meijssen <gerard.meijs...@gmail.com> wrote: > Hoi, > This mail thread is NOT about the issues that I or others face at this > time. They are serious enough but that is not for this thread. People are > working hard to find a solution for now. That is cool. > > What I want to know is are we technically and financially ready for a > continued exponential growth. If so, what are the plans and what if those > plans are needed in half the time expected. Are we ready for a continued > growth. When we hesitate we will lose the opportunities that are currently > open to us. > Thanks, > GerardM > > On Fri, 3 May 2019 at 16:24, Thad Guidry <thadgui...@gmail.com> wrote: > >> Gerard mentioned the PROBLEM in the 2nd sentence. I read it clearly.... >> >> >we all experience in the really bad response times we are suffering. It >> is so bad that people are asked what kind of updates they are running >> because it makes a difference in the lag times there are. >> >> The response times are typically attributed to SPARQL queries from what I >> have seen, as well as applying multiple edits with scripts or mass >> operations. Although I recall there is a light queue mechanism inherent in >> the Blazegraph architecture that contributes to this, and I am fine with >> slower writes. >> >> What most users are not comfortable with is the slower reads in different >> areas of Wikidata. >> We need to identify those slow read areas or figure out a way to get >> consensus on what parts of Wikidata reading affect our users the most. >> >> So let's be constructive here: >> Gerard - did you have specific areas that affect your daily work, and >> what from of work is that (reading/writing , which areas) ? >> >> Thad >> https://www.linkedin.com/in/thadguidry/ >> _______________________________________________ >> Wikidata mailing list >> Wikidata@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > _______________________________________________ > Wikidata mailing list > Wikidata@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > -- --- Marco Neumann KONA
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
