_______________________________________________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 users4/2015 | 13,911,417 | 213,027,375 | 1,913,828 | 15,1685/2016 | 17,432,789 | 328,781,525 | 2,688,788 | 16,8337/2017 | 28,037,196 | 514,252,789 | 2,835,219 | 18,0817/2018 | 49,081,962 | 701,319,718 | 2,970,150 | 18,5784/2019 | 56,377,647 | 931,449,205 | 3,236,569 | 20,857When you refer to "growing like a weed". What's that page views? queries per day? Mentions in the media?Best,MarcoOn Fri, May 3, 2019 at 3:36 PM Gerard Meijssen <gerard.meijssen@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 <thadguidry@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) ?
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