[
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
