You would have to implement that I don’t think that Solr is threading the query parser magically for you, but maybe some people have more insight on this topic.
> Am 16.08.2019 um 15:42 schrieb Vignan Malyala <dsmsvig...@gmail.com>: > > How do I check that in solr? Can anyone share link on implementation of > threads in solr? > >> On Fri 16 Aug, 2019, 4:52 PM Jörn Franke, <jornfra...@gmail.com> wrote: >> >> Is your custom query parser multithreaded and leverages all cores? >> >>> Am 16.08.2019 um 13:12 schrieb Vignan Malyala <dsmsvig...@gmail.com>: >>> >>> I want response time below 3 seconds. >>> And fyi I'm already using 32 cores. >>> My cache is already full too and obviously same requests don't occur in >> my >>> case. >>> >>> >>>> On Fri 16 Aug, 2019, 11:47 AM Jörn Franke, <jornfra...@gmail.com> >> wrote: >>>> >>>> How much response time do you require? >>>> I think you have to solve the issue in your code by introducing higher >>>> parallelism during calculation and potentially more cores. >>>> >>>> Maybe you can also precalculate what you do, cache it and use during >>>> request the precalculated values. >>>> >>>>> Am 16.08.2019 um 05:08 schrieb Vignan Malyala <dsmsvig...@gmail.com>: >>>>> >>>>> Hi >>>>> Any solution for this? Taking around 50 seconds to get response. >>>>> >>>>>> On Mon 12 Aug, 2019, 3:28 PM Vignan Malyala, <dsmsvig...@gmail.com> >>>> wrote: >>>>>> >>>>>> Hi Doug / Walter, >>>>>> >>>>>> I'm just using this methodology. >>>>>> PFB link of my sample code. >>>>>> https://github.com/saaay71/solr-vector-scoring >>>>>> >>>>>> The only issue is speed of response for 1M records. >>>>>> >>>>>> On Mon, Aug 12, 2019 at 12:24 AM Walter Underwood < >>>> wun...@wunderwood.org> >>>>>> wrote: >>>>>> >>>>>>> tf.idf was invented because cosine similarity is too much >> computation. >>>>>>> tf.idf gives similar results much, much faster than cosine distance. >>>>>>> >>>>>>> I would expect cosine similarity to be slow. I would also expect >>>>>>> retrieving 1 million records to be slow. Doing both of those in one >>>> minute >>>>>>> is pretty good. >>>>>>> >>>>>>> As Kernighan and Paugher said in 1978, "Don’t diddle code to make it >>>>>>> faster—find a better algorithm.” >>>>>>> >>>>>>> https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style >>>>>>> >>>>>>> wunder >>>>>>> Walter Underwood >>>>>>> wun...@wunderwood.org >>>>>>> http://observer.wunderwood.org/ (my blog) >>>>>>> >>>>>>>> On Aug 11, 2019, at 10:40 AM, Doug Turnbull < >>>>>>> dturnb...@opensourceconnections.com> wrote: >>>>>>>> >>>>>>>> Hi Vignan, >>>>>>>> >>>>>>>> We need to see more details / code of what your query parser plugin >>>> does >>>>>>>> exactly with term vectors, we can't really help you without more >>>>>>> details. >>>>>>>> Is it open source? Can you share a minimal example that recreates >> the >>>>>>>> problem? >>>>>>>> >>>>>>>> On Sun, Aug 11, 2019 at 1:19 PM Vignan Malyala < >> dsmsvig...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> I made my custom qparser plugin in Solr for scoring. The plugin >> only >>>>>>> does >>>>>>>>> cosine similarity of vectors for each record. I use term vectors >>>> here. >>>>>>>>> Results are fine! >>>>>>>>> >>>>>>>>> BUT, Solr response is very slow with term vectors. It takes around >> 55 >>>>>>>>> seconds for each request for 1000000 records. >>>>>>>>> How do I make it faster to get my results in ms ? >>>>>>>>> Please respond soon as its lil urgent. >>>>>>>>> >>>>>>>>> Note: All my values are stored and indexed. I am not using Solr >>>> Cloud. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Doug Turnbull **| CTO* | OpenSource Connections >>>>>>>> <http://opensourceconnections.com>, LLC | 240.476.9983 >>>>>>>> Author: Relevant Search <http://manning.com/turnbull> >>>>>>>> This e-mail and all contents, including attachments, is considered >> to >>>> be >>>>>>>> Company Confidential unless explicitly stated otherwise, regardless >>>>>>>> of whether attachments are marked as such. >>>>>>> >>>>>>> >>>> >>