[ https://issues.apache.org/jira/browse/SOLR-16228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Høydahl resolved SOLR-16228. -------------------------------- Resolution: Invalid It is not possible to do query benchmarks with a single query, let alone on a laptop with Windows, WSL and cURL. You have to setup a proper environment and run thousands of queries over time, eliminating random factors, caching etc. See e.g. [https://home.apache.org/~mikemccand/lucenebench/] for how the Lucene project does their benchmarks. For Solr we do not have anything like this running (yet) so there is a possibility that 9.0 has some performance regressions. However, before you could open a Jira to state there is a bug, there would need to be prior discussion, benchmarking and evidence. Please try phrasing this as a question in the users mailing list instead. I'm closing this issue as we do not use Jira for support questions. > solr 9 docker container searches are 10^5 slower than solr 8 docker container > ----------------------------------------------------------------------------- > > Key: SOLR-16228 > URL: https://issues.apache.org/jira/browse/SOLR-16228 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search > Affects Versions: 9.0 > Reporter: Sean W > Priority: Major > > Hi Everyone, > I just found that Solr 9 searches are 400%+ slower than Solr 8 when using > Docker containers. > In case it helps, my setup is on Windows 10 using WSL2 and Dropbox, but using > the official Docker images. > Steps to reproduce, starting with fast Solr 8: > > {code:java} > NAME=solr8 > PORT=8983 > CORE=demo # because that's available in the docker image - yay! > VERSION=8.11.1 > # create a named volume so you can retain the index and mount it to other > versions of docker run > docker volume create $NAME > docker run \ > --mount type=volume,source=$NAME,target=/var/solr \ > --restart always -d -p 127.0.0.1:$PORT:8983 \ > --name $NAME -e SOLR_HEAP=8000m -t \ > --memory="9000m" \ > --memory-swap="9000m" \ > --memory-swappiness=0 \ > --mount type=bind,source=/mnt/c/Users/foo,target=/opt/solr/mydata > \ > solr:$VERSION \ > solr-demo > # Solr 8 > docker exec -ti --user=solr $NAME bash -c \ > 'cp -r /opt/solr/server/solr/configsets/_default/conf/* > /var/solr/data/$CORE/conf/' > docker restart $NAME > # seed PDFs -- capitalization MUST match filesystem here!!! > docker exec --user=solr \ > $NAME \ > find \ > /opt/solr/mydata/Dropbox/PDFs/Shared \ > -not -path \ > '/opt/solr/mydata/Dropbox/PDFs/*/.stversions*' \ > -name '*.pdf' \ > -type f \ > -exec bin/post -c $CORE \ > "{}" ';'{code} > > Now the slower Solr 9: > {code:java} > NAME=solr9 > PORT=8984 > CORE=demo # because that's available in the docker image - yay! > VERSION=latest # create a named volume so you can retain the index and mount > it to other versions of docker run > docker volume create $NAME > docker run \ > --mount type=volume,source=$NAME,target=/var/solr \ > --restart always -d -p 127.0.0.1:$PORT:8983 \ > --name $NAME -e SOLR_HEAP=8000m -t \ > --memory="9000m" \ > --memory-swap="9000m" \ > --memory-swappiness=0 \ > --mount type=bind,source=/mnt/c/Users/foo,target=/opt/solr/mydata > \ > solr:$VERSION \ > solr-demo# seed PDFs -- capitalization MUST match filesystem > here!!! > docker exec --user=solr \ > $NAME \ > find \ > /opt/solr/mydata/Dropbox/PDFs/Shared \ > -not -path \ > '/opt/solr/mydata/Dropbox/PDFs/*/.stversions*' \ > -name '*.pdf' \ > -type f \ > -exec bin/post -c $CORE \ > "{}" ';' > {code} > When using the Linux `time` command, I see: > solr 8: .01 seconds REAL time > solr 9: 2.21 seconds REAL time > 2.21*(60) / .01 = 13260 # thus 10^5 slower (5 orders of magnitude) > My query: > {code:java} > /usr/bin/time -f %e curl -G --data-urlencode q=xfoo -s > 'http://localhost:$PORT/solr/$CORE/select?fl=highlighting,score&hl.method=unified&hl=true&hl.simple.pre=&hl.simple.post=&hl.snippets=3&hl.fragsize=100&hl.maxMultiValuedToMatch=2&hl.maxAnalyzedChars=0&hl.mergeContiguous=true&hl.requireFieldMatch=true&rows=9999 > {code} > Could this be a performance regression from changing the base image to > "eclipse-temurin:17-jre" in Jira Issue SOLR-15949? -- This message was sent by Atlassian Jira (v8.20.7#820007) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org