nonamethanks said:
I did some stress tests and I found the following (searched 200 times for the same tag via python script, no authentication, just loading the https search page):
non-web_source limit:20 -> 0.23 seconds on average
-source:http* -source:none limit:20 -> 0.21 seconds on average (for some reason faster than the single search)
non-web_source limit:200 -> 1.30 seconds on average
-source:http* -source:none limit:200 -> 1.81 seconds on average
So there's a delay for large amount of posts per page but it's not really noticeable, or risking timeout for anons/members, especially considering that the default search limit is 20 posts, and anonymous users cannot even change that unless they specifically add the limit: tag to their searches.
I'm getting different numbers myself. I tested it with a browser, since a browser is the platform that most users will be using and not Python. Also, I don't know if you did this for your tests, but you want to be looking at the return headers, specifically the value "x-runtime". That's how long the database is actually taking to complete the requests, and it's this value which will indicate how close things were to timing out.
Test setup
- Platform: Chrome 83
- Iterations: 5
- Limit: 200
In addition to the vanilla tests like you did, I also added an additional search tag of translation request to test out the aspect of using other search terms. It's true that this would put the Anonymous/Member users over their tag limit, but this was done to show the performance of a tag approach versus a metatag approach.
Non-web source
- vanilla: 0.8274266 seconds
- translation request: 0.3244044 seconds
source: metatag
- vanilla: 1.456441 seconds
- translation request: 2.5366118 seconds
- 2 of 5 tests exceeded the 3 second limit
Analysis
So on the vanilla test, the tag solution did about 1.8 times better, and on the translation request test, the tag solution did about 7.8 times better. Additionally as shown, the tag solution does better when additional search terms are added, whereas the metatag solution does worse. Although not done for this particular test, I imagine that this trend would continue the more tags/metatags get added, which makes sense since searching using the tag index is much faster than performing wildcard matching on a string.
Also, there's 4k+ posts under -source:http* -source:none -non-web_source. The tag is not even being mantained. Might as well implement it server-side if it has to exist, and remove the need for manual tagging.
All of the tags on Danbooru have varying degrees of being maintained or not. Regardless, I would be for the server taking over for this. It would be simple enough to implement.
On the other hand, if the tag does get nuked, I would propose that a source:nonweb metatag option should be added which would combine both the -source:http* and -source:none search terms into one, which would benefit all users not having to use up one of their search terms to complete the same search.
As for the concerns on this being merely technical, well it is my opinion that that this aspect is important to me at least, which is why I voted against it. Those that do not feel this way can vote for it. The administrative staff can then decide which way would be the best course for this.
