do you think that still stands, I would like to move it into to the track_index
luks
yes, the search servers are overloaded, the database server is not
I think track_index is large enough already
but you should wait for ruaok
ijabz
Yeah sure, I didnt think should be done as part of the search rewite anyway, but thought could possibly go into NGS release
luks
I think there is enough PUIDs to double the size of the track index
ijabz
II'll need to run a performance test without/without puids to see how they impact a track search
luks
how does it affect PUID lookup is also an important test
it's the most often used code in MB, as the comment in the source code says
ijabz
where do you mean ?
luks
how fast are DB-based vs Lucene-based PUID lookups
MBChatLogger
luks probably meant ' PUID lookups are what generates the most http hits to musicbrainz.org '
luks
PUID lookups are what generates the most http hits to mb.org
ijabz is confused
ijabz
only talking about finding track by puid, not looking up an individual puid
luks
yes, that's why I'm talking about, too
what
ijabz
ok,, yes would want search over lucene to as quick as search by database, thats harder to measure because you would be interested in this test with production setup which would be more difficult to test
But my first test would at least indicate if adding puid to track index had much of a negative effect on the track indexing as a whole
luks
you can't correctly measure that
if you have twice as much data in the index, and maybe 10 as many requests, the disk will have to seek around the disk much more often
which will cause regular track searches to be slower
