Hiya. On Aug 3, 2005, at 6:25 PM, Stewart Loving-Gibbard wrote:
I can't shake the feeling that if the server were multi-threaded that these problems would be completely absent. One thread to make sure the players didn't go dry, one to handle navigation via the remote, one to handle the web server, etc. Part of me keeps hoping SlimDevices has a master plan to fix all this. Python, Java? A tidy C++ core maybe? I'm not holding my breath.
Like many of the people who have written on this thread, I have also thought that separating the stream-serving and web-interface portions of SlimServer into separate processes would help performance dramatically. Over the last couple of years I've pretty much given up using the web interface because of poor response, and very frequently the device UI freezes for 10-100 seconds while trying to navigate. I've just resigned myself to wandering away for a while and coming back in a minute or two.
These are definitely problems that were once unnoticed, but have grown as my library has grown, now at a large 120 GB / 25,000 tracks on an admittedly aging 450 MHz single proc G3 Mac that's dedicated to SlimServer. On one hand, I'd love it if my server was more robust, on the other hand, I'm running two Slims from a 25K song library on a 7 year old computer with annoyances I've learned to live with.
I do sometimes renice the slimserver process down to -10 or -19 to squeeze a little more out of it, but since it's a dedicated box it doesn't do too much.
I've also noticed that some hooks for a mysql DB option are there somewhere, yes? I've certainly considered switching to that in the hopes I can squeeze some more performance out.
- Ert _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
