These changes are include the time taken by the network request from client to server and back.

We should only display the time taken to generate the results, that is returning the time along with results.

The changes should be in backend code and not in front end IMHO.
Along with the results include the time and then parse the time to front end.

@AnshulMalik @raju249 @gabru-md The thing is we cannot include time analysis in backend as API GET /api/v1/search/<search-engine>?query=query&format=format will get affected and since this api is used by SUSPER and OPEN EVENT to get the responses so can't affect the API.

I think we don't have to include or change anything in the URL.
We can send the time in response. We can work it out like just pass the time value in json or xml, whoever wants to use it can use.

Others, any thoughts ?

@bhaveshAn That's good point.
So let's hold this, and try to think, do we really need this time analysis feature?
If yes, we can discuss with SUSPER or SUSI or others who are using.

@raju249, our response is currently just array, not a dictionary so we can not directly add another key to response.

Ohh.
I thought its a key value pair.
No issues then, I think we can follow what you said.

Scrapers currently return one parameter: the urls list. It would be possible to modify the scrapers to return two parameters instead: the urls list and the elapsed time. The first parameter would be returned to the calling program and the second parameter would only be used for display, logging, or printing.

That's possible @cclauss, but when I think about it's use case, I don't think this would be useful anywhere?
Why would someone want the time taken to generate the search results ?

As @AnshulMalik stated. I guess there is no definite benefit/use of actually including the time elapsed into query-server results. I mean i cannot figure out the possible benefits that it will have since it is not a search engine
@bhaveshAn please throw some light on this matter and explain ?

@bhaveshAn reminder

I actually like this PR a lot... In modern software you should "instrument everything" and round trip time measurement is worth doing as long as at least one user is going to study the resulting data from time to time to understand if we have any bottlenecks that are worth addressing.

@cclauss considering round trip time is not recommended, since it can vary a lot depending upon user connection, It won't help anyhow, but marking time for fetching and parsing on backend can be a matrix which we can rely on.

Our code's performance is roughly:

the time to run server.search() - the time to run each scraper's search().

Once we have tuned the former, we can focus on which search engines are too slow. My bet would be that some are faster than others but without metrics, we do not know for sure. Some search engines might be so slow that we drop them.

I think unless we pass the time in response from server, adding time via js is not useful.

There are two things: What we want to measure #382 and how we want to measure it (this PR / discussion). I believe the “what” should come before the “how”. Is it possible for the maintainers to respond to #382 so we know what we are trying to do before we decide how we are going to do it?

What is the status of this? Should this be closed and reopened later, when there is a follow-up?

@mariobehling I think we should go with adding this feature, since time analysis comes under performance category. And thats cool idea.
Though the discussion is only on whether we should implement it

1. In Flask backend where the API GET /api/v1/search/<search-engine>?query=query&format=format will get affected and we will return the search results response alongwith time taken.
2. In JavaScript frontend where we just calculate the time difference between the clicking the submit button and the response returned by backend. ( AS DONE IN THIS PR )
   Please give your opinion.

@vaibhavsingh97 What are your thoughts?

@mariobehling @bhaveshAn IMO, instead of checking time on client side, we should add one time parameter to the backend API and return the response along with the time. But my question is where time will be useful?

@bhaveshAn Update please

In Flask backend where the API GET /api/v1/search/?query=query&format=format will get affected and we will return the search results response alongwith time taken.

@vaibhavsingh97 Should I make these corresponding changes.

@bhaveshAn yes, just pass one dictionary context while rendering the page

This PR needs updation in codebase. Please give some time.

I agree time should be retrieved from the server, not the client.

Work on this issue is stalled. Closing this due to inactivity. Please reopen new PR if you want to resolve this.