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.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