Hi all (also Kishore !), I've set up typesense, I already indexed a collection with about 20k objects, the schema is a single id and text field which is the one indexed. Long thread incoming, but you would probably appreciate my findings. I have noticed that, when running multiple search requests in a single one (i.e. multisearch) the time it takes to complete the requests does not match the time reported by the individual search_time_mss.

@Al Mo The difference between col1 and col2 seems to be around 3-6ms. This additional time most likely comes from http layer parsing, tiny tcp overhead and actual data transfer (like you mentioned). The search time excludes these. You could disable some document fields from being returned using the

exclude_fields

search parameter, but there's no way to disable snippets at the moment.

Following it, thanks!

I see, I wonder if this is specific to multi-search, since there's some JSON parsing involved there on the server side. If it's not too much trouble, would you be able to repeat this test with the single search (documents/search) endpoint?

Yes, I've just finished that about an hour ago 😄 One path uses multisearch, the other is just Promise.all(<with a lot of single searches>) (so they run concurrently) Results are pretty much the same on both paths. Same time per query, same overhead, same time overall (+- 20ms or so).

Got it, would you be able to share this dataset (say via email)? I used a 2M recipes dataset recently to benchmark Typesense and Meilisearch and that dataset showed faster search response times with Typesense consistently. So I wonder if this is something specific to this dataset...

Sure, is JSON fine with you? I can dump the documents array, it's exactly the same on both ms and ts.

Yup, JSON is perfect, thank you!

Sure, what's your email?

email is contact@typesense.org

Ok, great give me a few mins.

Thank you! Will take a look

Thank you!

I will be taking a look at this today. Can you please tell me what version of Typesense you are using locally?

Hi again Kishore, ok. So, you mean the whole multisearch 'query' right (all of them bundled)?

Yup check your email for the exact snippet.

I left out a few in my pic, but still you should be able to see a big difference between the sum of all search_time_ms and the measured time for the whole thing (or not?).

I am measuring the end to end curl request time taken. The gist has the curl request I'm sending..if you can run the same on your localhost we can compare the times.

Ok, let me check.

No problem, good night!

Hi Kishore, I sent you an email some time ago, but I just wanted to add something. I've also wrote some code in node.js that makes and http request to the multi_search endpoint and parses the result. Measured times are virtually identical vs. using the library for the same thing. So I guess the overhead I'm seeing is just data transfer + json parsing, not much that could be donde regarding that. The response from the servers for all my queries combined is about 2Mb, so that explains it. I'll wait until there's a way to disable fields from the response, that's the bottleneck in my case.

Got it. Have you tried using

exclude_fields

?

Let me see what happens if I remove the 'text' field which is the heaviest.

Has the size of response dropped when you excluded the field?

Yes, it dropped, but processing time didn't change significantly.

Got it. We will be now looking at it from a json parsing angle. Will keep you posted.