Meeting output:

• pick a vote threshold
• above said threshold show a warning, but still have the button available

In T276354, @Tchanders wrote:

@jrbs attempted to tally some large elections in T269029#6693314 and T269029#6693321 and found:

No. votes	Timed out?
143	No (tallies instantly)
594	Yes
2118	Yes

This was before we improved the speed of tallying in T271824. Locally we found significant speed-ups. It's difficult to test on production given the limited availability of large elections. @jrbs is the above table still the case, since T271824?

The issue is that a lot of the elections I tallied were not encrypted. The larger / "more important" elections tend to be the ones that are encrypted. So that 143-voter election (the 2020 Farsi ArbCom election) likely tallies immediately because it doesn't have to bother with GPG and such, which I think we isolated as the issue with the larger elections timing out. I don't know if a 143-voter election with encryption would be as easy to tally, and there's not really an easy way to test that in production since we'd need 100+ accounts to cast votes.

The other elections in your list (which I think are likely to be English ArbCom elections from other years) were encrypted which may have been the real reason they timed out.

Can we maybe try an encrypted election with a dozen or so voters to work out how long it takes per vote and do it that way?

Can we maybe try an encrypted election with a dozen or so voters to work out how long it takes per vote and do it that way?

@jrbs Sounds like a good idea to check this, since we did find it scaled linearly when testing locally. (Not sure if 12 will be enough for the decryption to be the main bottleneck though.) I had mistakenly assumed all the elections you tallied were encrypted. Just to clarify, did the 594-vote and 2118-vote elections both still time out after we implemented the speedup?

When testing locally, we found quite a large speedup for tallying encrypted elections:

From T271824#6768315:

no. votes	master	patch
500	190s	20s
1000	x	40s
3600	x	140s

From T271824#6763484:

No. votes	master	new patch
500	30s	20s
1000	60s	40s

@dom_walden also tested on beta and found that encrypted elections with 50 votes didn't time out: T271824#6817965

! In Task Description, @Tchanders wrote:
It's difficult to test on production given the limited availability of large elections.

One of the major deficiencies of MediaWiki-extensions-SecurePoll is that it does not have an API interface. If it did, we could use it to submit some votes programmatically to an election on testwiki. We could even create a CI test like that which would empirically measure the efficiency of SecurePoll after each patch.

In T276354#6880963, @Huji wrote:

! In Task Description, @Tchanders wrote:
It's difficult to test on production given the limited availability of large elections.

One of the major deficiencies of MediaWiki-extensions-SecurePoll is that it does not have an API interface. If it did, we could use it to submit some votes programmatically to an election on testwiki. We could even create a CI test like that which would empirically measure the efficiency of SecurePoll after each patch.

Thanks @Huji, sounds like this would be worth filing... I doubt AHT would get round to this before the end of March, but would be useful to consider next time work is done on SecurePoll. @Niharika What do you think?

(sorry, I hadn't seen T276360: Output the time taken to run tally.php so we can judge what size of encrypted election times out when I commented here :) )

In T276354#6880571, @Tchanders wrote:

Can we maybe try an encrypted election with a dozen or so voters to work out how long it takes per vote and do it that way?

@jrbs Sounds like a good idea to check this, since we did find it scaled linearly when testing locally. (Not sure if 12 will be enough for the decryption to be the main bottleneck though.) I had mistakenly assumed all the elections you tallied were encrypted. Just to clarify, did the 594-vote and 2118-vote elections both still time out after we implemented the speedup?

I just tested both on votewiki (2014 English ArbCom election, id:392, and 2018 English ArbCom election, id:710) and both timed out.

In T276354#6883573, @Tchanders wrote:

In T276354#6880963, @Huji wrote:

One of the major deficiencies of MediaWiki-extensions-SecurePoll is that it does not have an API interface. If it did, we could use it to submit some votes programmatically to an election on testwiki. We could even create a CI test like that which would empirically measure the efficiency of SecurePoll after each patch.

Thanks @Huji, sounds like this would be worth filing... I doubt AHT would get round to this before the end of March, but would be useful to consider next time work is done on SecurePoll. @Niharika What do you think?

@Tchanders this is already proposed by @Legoktm in T44465 which was filed back in 2012.

In T276354#6889393, @Huji wrote:

@Tchanders this is already proposed by @Legoktm in T44465 which was filed back in 2012.

Thanks @Huji - we won't file a duplicate then!

Change 670586 had a related patch set uploaded (by AGueyte; owner: AGueyte):
[mediawiki/extensions/SecurePoll@master] WIP No tally large encrypted elections

https://gerrit.wikimedia.org/r/670586

Change 670586 merged by jenkins-bot:
[mediawiki/extensions/SecurePoll@master] No tally large encrypted elections

https://gerrit.wikimedia.org/r/670586

• I cannot tally a 200 vote, encrypted election. I get a message The election is too large to be tallied via this page. Please use the maintenance script tally.php instead
• I can tally a 100 vote, encrypted election.
• I can tally a 200 vote, unencrypted election.

We only count votes which are not struck or marked as duplicates. Therefore, I can tally an encrypted election with over 100 votes but less than 100 of which are not struck or duplicates.