JJZolx;194709 Wrote: > I'd be willing to bet that a _much_ larger gain in performance could be > had by switching to MyISAM tables and maybe getting rid of all the > text/blob fields.
I've since had a chance to try this theory out... I'm running SlimServer 6.5.2 with purely MyISAM tables and it doesn't feel particularly faster. I haven't run any timing tests, but I'm gauging it on the speed of the browse Albums pages (with artist display enabled), as this is by far the most annoyingly slow part of the Slim interface for me. The SlimServer programming, however, where the generation of a single page can easily run to more than 500 queries, is hopelessly beyond any possible MySQL server optimization. On a slower system, though, the differences using MyISAM might more pronounced. I don't have a way to test it, though. The way I was able to use MyISAM tables was to simply edit the schema files that SlimServer uses, then I emptied the database of all tables and let SlimServer build it again from scratch. I never really understood the use of blob and text columns in the database, so in the schema I also replaced these with varchar types instead. In MySQL 5.0.3 and later, varchar columns can be up to 65,535 characters long, so there should be no need for text columns. The cover and thumb columns of the tracks table need to remain blobs, though. There seems to be a bug converting file paths encoded in the server's codepage to and from UTF, so I presume that the use of a binary data columns was a quick and dirty way of fixing character set issues. But it's far from optimal, considering the use of blobs for things as common as track and album titles. -- JJZolx Jim ------------------------------------------------------------------------ JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=32417 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
