Queries take tremendous amount of time (4-15 seconds) average 6 seconds about echoprint-server

[alnesbit]

Hello Daniel,

Apologies for the delay in getting back to you regarding this. Are you still having this problem?

Did you split the fingerprint codes into overlapping segments upon ingestion or are you ingesting full codes? In other words, how did you run the ingestion, and was split=True or split=False set when calling fp.py:ingest?

What happens when you make rapid, repeated queries of the Solr index? Do all the queries take a long time or

Andrew

[danielbenzvi]

Hello Andrew,
We are still receiving this problem and is consistent through upgrades.

Multiple queries to the exactly same result set will become faster but not significantly faster. The lowest we can get is 1.9 seconds. The highest was 28 seconds and it was the only query being performed on the system.

We ingested full length codes and we used split=True (as defined in fp.py).

All the queries take long time.

[Tomtomgo]

I experience exactly the same issue... Did you find a solution @danielbenzvi ?

[alnesbit]

Lately we have been investigating this issue in detail and have found that when the Solr database becomes very large then performance upon querying can indeed suffer in this way, if the entire index is deployed onto a single Solr core on one server.

We've found various solutions that have helped tremendously in reducing the time required to perform a query (e.g., improvements in time of about an order of magnitude). One of these solutions involves sharding, which requires a more complicated Solr setup. Another solution involves changes to the way the fingerprints are actually indexed and queried. We have had great success in running these improvements on our servers that are behind the song/identify method on our API.

We will push out source code when it is ready for GitHub, for example, to make a more sophisticated Solr configuration easier to deploy out-of-the-box (no ETA yet). But this will most likely involve large changes to the back end rather than tweaking the current setup.

[ranger123]

Andrew, Could you provide a little more detail as to how you've adjusted the indexing and queries to improve the Solr query times? I'm struggling getting an acceptable response time for a large collection and am interesting in any direction you may be able to provide to assist. thanks.

[zemariamm]

Same problem here guys, Solr is taking too long to answer.. I get response times around 5 seconds per query, I used the patches suggest by Justin Haygood (https://groups.google.com/forum/#!topic/echoprint/J7MQftCfpCM) which improved the recognition significantly. Any ideas ?

[alnesbit]

Increasing the density of hash codes will improve the OTA recognition rate, but this will also make the Solr part of the search significantly slower.

The overall ideas in improving scalability of the index are the following:

• to reduce the number of hash codes down by omitting uninformative hash codes from the index and queries
• improving the efficiency of the search algorithm in Solr (Solr 4.x already has a patch for this but to use it we obviously need to upgrade from Solr 1.4 to Solr 4).
• changing the architecture of the index itself

We've already tried the first approach. It improves the results but it is a hack, and the other approaches are better.

[zemariamm]

Thanks for the fast answer Andrew! I actually ran a few tests that surprised me (with Justin Haygood's patch):

• the OTA recognition quality is paired with some proprietary stuff that I tried in the past
• Every time I run a query - it doesn't matter if I only have 1 song, 100 or 2000 on the DB) it always takes around 4 or 5 seconds (if I run the same query again it takes around 20 ms on my local machine), how can this be happening ? Shouldn't it be blazing fast with a basically empty database ?

So replacing Solr for the newest version should fasten it right ? I'll give it a try :)

Thanks for the help!
Zé

[ranger123]

Hi Andrew, Thanks for the response. I wasn't able to reach the C experimental repo either. I'd be interested in taking a look.

I did take a look at migrating to Solr 4.x, but it looks like there are a few functions that have been deprecated that prevent the hashr from compiling. I did try using a version from another user that utilizes Maven to compile other versions, but it would only compile to 3.x.

When you mention an uninformative hash, could you help me understand what type of hash value would be uninformative?
Thanks.

[danicuki]

I am having the same issue here. Does anyone have a solution?