Some time ago I learned, that phex horribly down (speed), when you have too many files, because the searches just eat up too much speed.
Could that be solved by using a second index, where you pre-sort the files by most often used keywords?
For that phex would need to
!. Create a list of the most often used queries (just save them and sort them, by part (.. .mp3) and by whole name (song.mp3).
2. Create a precompiled list of the files fitting the search-quere for each of the 20 or 50 most often used queries.

Then phex would only need to search smaller files instead of one large file.

I don't know the statistics, so I can't say if that would work, but if most searches can be put into one of 20 or 50 cathegories, the speed would likely go up and sgharing would work better again.

Bab

Hi...

the problem is that most searches contain more then one keyword and you have to match both. So even if one keyword is mp3 you need to match for the second keyword.
Also there is a huge amount of different searches going through your node. The memory that would be needed to track the most 20 searches would be very high.
Since new HUGE ( searches by file hash ) protocol that will be used more often by clients now. You will see much faster matching. The file hash is indexed and if a match is found no keyword match needs to be done.
Also with the next release Phex will support Ultrapeer connections, this will reduce search bandwidth dramatically.
But still I would recommend not to share more then 1000 - 2000 files, even though Phex and your system might be able to handle this, you should question yourself if you really have that many highly "wanted" files.

Gregor

__________________