lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoniya Statelova <>
Subject Re: Embedded Server, Caching, Stats page updates
Date Wed, 19 May 2010 14:45:46 GMT
> The way you phrased that paragraph makes me think that one of us doesn't
> understand what exactly you did when you "switched" ...

"Switched" works for the specific setup i'm using - the server would refer
to itself in the CommonHttpSolrServer request sent, i.e. it would run both
the server and client sides. Removing this and simply using
EmbeddedSolrServer just made the setup a little more sane in that aspect.
Does that make more sense now?

> Now for starters: if the remote server you were running solr on is more
> powerful then the local machine you are running your java application on,
> that alone could explain some performance differences (likewise for JVM
> settings).
The machine I'm running it on is exactly the same - the code change was
pushed and I had performance before and after. Same load observed (since
it's a testing machine i could regulate that). That's why i was so surprised
that removing that additional http request didn't cause improvement.

> Most importantly: when running solr embedded in your application, there is
> no "stats.jsp" page for you to look at -- because solr is no longer
> running in a servlet container.  so if you are seeing stats on your
> solr server that say your caches aren't being hit, the reason is because
> the server isn't being hit at all.

This is nice to know, I didn't look into how the actual page was generated.
I expected something like this to be true. Thank you!

> When running an embedded solr server, the filterCache and queryResultCache
> will still be used.  the settings in the solrconfig.xml you specify when
> initializing the SolrCore will be honored.  you can see use JMX to monitor
> those cache hit rates (assuming you have JMX enabled for your application,
> and the appropriate setting is in your solrconfig.xml)
> I'll look into using JMX, thanks for the suggestion.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message