Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show duration per engine / and in total #3092

Open
Myzel394 opened this issue Jan 2, 2024 · 6 comments · May be fixed by #3102
Open

Show duration per engine / and in total #3092

Myzel394 opened this issue Jan 2, 2024 · 6 comments · May be fixed by #3102

Comments

@Myzel394
Copy link
Contributor

Myzel394 commented Jan 2, 2024

Is your feature request related to a problem? Please describe.
Google and other engine show the duration it took them to load the results:

image

Describe the solution you'd like
Add a same hint for the duration of the engine that took the longest to respond beneath the search input. Show a detailed view about the duration of each engine on the right side.

Describe alternatives you've considered

Additional context
I can try to open a PR if you're okay with this :)

@return42
Copy link
Member

return42 commented Jan 3, 2024

Add a same hint for the duration of the engine that took the longest to respond beneath the search input.

And what if some engines run into timeout?

I can try to open a PR if you're okay with this :)

Sure, why not .. feel welcome 👍 .. to have a POV concept is most often better and can avoid dumb questions like mine from above :)

@Myzel394
Copy link
Contributor Author

Myzel394 commented Jan 3, 2024

It seems like there is already such a mechanism implemented - is there some reason why it's not being shown in the frontend? Otherwise, I'd simply use that and just add it to the renderer

@dalf
Copy link
Member

dalf commented Jan 4, 2024

See searx/searx#1637

From my experience, the "usual" response is important, not a one time request. By usual I mean the median, the quartile, or even the average. This is what is shown in the preference.

@return42 I let you decide

@return42
Copy link
Member

return42 commented Jan 4, 2024

Sorry for being slow in uptake ... As far as I can tell, we have

What @Myzel394 asked for is more or less the "duration of a individual query".

Most often, when one ore more engines run into timeout without response, this duration is dominated by max timeout .. that is why I asked for:

And what if some engines run into timeout?

Since this question has not been answered, it is not clear to me what @Myzel394 has in mind .. a POC (a draft PR) might clarify .. or a more detailed concept .. whatever.

@return42 I let you decide

I think we should not decide before the idea behind / the concept is clear.

@Myzel394
Copy link
Contributor Author

Myzel394 commented Jan 4, 2024

What @Myzel394 asked for is more or less the "duration of a individual query".

Isn't this already implemented? I'm specifically talking about the add_timing method, don't we need to simply show these values in the frontend?

Most often, when one ore more engines run into timeout without response, this duration is dominated by max timeout .. that is why I asked for:

I'd show the longest duration under the input; if there's a timeout, this means the timeout is the longest duration.

@return42
Copy link
Member

return42 commented Jan 4, 2024

Isn't this already implemented? I

The time recording per engine is implemented, but it will take a few more lines of code to determine the maximum time of all engines used in the search query and display it in the user interface.

I'm specifically talking about the add_timing method, don't we need to simply show these values in the frontend?

I don't have an overview yet, but I think the times of engines with a timeout are not recorded by the method.

May you implement your POC and we discuss the details of the code in the PR?

@Myzel394 Myzel394 linked a pull request Jan 6, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants