add timing log; add new where condition only get 7 days posts

[ety001]

• add timing log
• add new where condition only get 7 days posts

[only-dev-time]

I'll run my tester over it for a day to see how long the response times are compared to my test in August.

Edit after testing:
The most important results in comparison:

no.	method and parameter description	avg response time old (ms)	avg response time new (ms)	Improvment (ms)	%
1	bridge.get_ranked_posts, sort trending, max limit 100, tag my, observer remlaps	21796	548	-21248	-97%
2	bridge.get_ranked_posts, sort created, max limit 100, tag my, observer remlaps	825	16225	+15400	+1867%
3	bridge.get_ranked_posts, sort trending, max limit 100, tag my, observer barski (following 16T)	timeout	786	no more timeout	-
4	bridge.get_ranked_posts, sort created, max limit 100, tag my, observer barski (following 16T)	timeout	timeout	-	-
5	bridge.get_ranked_posts, sort trending, max limit 100, tag hive-185836 = community trends	timeout	681	no more timeout	-
6	bridge.get_ranked_posts, sort created, max limit 100, tag hive-185836 = community trends	25863	timeout	-	-

Brief description of the test:
I sent various queries from the bridge_api every hour for one day. The queries are sent to my Hivemind test server. This excludes influences from other queries. The response time in min, max and average was then calculated for all responses.

The improvement in the requests with sort=trending (no. 1, 3, 5) can be seen very clearly. So the change had the desired effect here.

What surprises me, however, is the worsening of the requests with sort=created (no. 2, 4, 6). The change should have no effect at all on sort=created. At first I assumed network influences, but since this affects all created requests, I would exclude this.

Can anyone confirm this?

How ends your tests on logging level, @ety001?

10.09.2024: Update after repeating the test:
I measured the response times again with the code before the change and after the change. The test was performed on the same server (with address localhost). Network problems can therefore be ruled out.

[ety001]

What surprises me, however, is the worsening of the requests with sort=created (no. 2, 4, 6). The change should have no effect at all on sort=created. At first I assumed network influences, but since this affects all created requests, I would exclude this.

@only-dev-time Hi, thank you for your test.

The sort=created is low visit in real situation. So I keep the origin logic of this.

Maybe we can add a one-month range condition on sort=created in future some time.