PDA

View Full Version : Slimserver wants a FAST machine



MelonMonkey
2006-11-29, 11:42
I'm relatively new to the forum so I've been doing my best to read as much as I can to quickly get up to speed. I had plenty of time to fiddle with Slimserver without the use of an actual Squeezebox thanks to UPS (have to thank the Slim support guys for finally putting UPS in their place and sending out a replacement unit).

Anyway, I've seen countless numbers of posts asking what hardware to use as a server and even more replies suggesting nearly any system will work fine. That even a lowly PII at a couple of hundred MHz is suitable, etc...

I'm sure you can run Slimserver on an imbedded Micro if the software dependancies are all met, but a slow system is far from ideal.

I first installed Slimserver on one of the machines I keep on 24/7. A Mac server that runs a few development mySQL databases, bug tracking software and SVN. These services require very little CPU time as they're only access a few times per day.

The hardware consists of a Dual Processor 533MHz PowerMac G4 connected to my LAN with 100baseTX.

While browsing the web interface in cover mode I've been finding load times unacceptably slow. It's painful to use the web interface for extended periods. I'm sure some people may find it acceptable, but when I get better performance loading graphics intensive sites from the Internet, that's a problem for me.

Yesterday I increased the thumbnail size from 100 pixels to 120 pixels - which obviously made matters even worse.

Today as an experiment, I moved all the music over to an Intel Core Duo (1.66GHz) Mac mini. Its boot drive is a slow 2.5" model but the music is on the same 250GB external Firewire drive as I've been using all along.

I copied the whole preferences folder from the G4 and installed the current (11-29) nightly (same as the G4). The complete scan/indexing of the library was much faster than on the G4. That's not a huge concern as I'll usually clear the whole DB manually before going to bed if I need to load updated tracks (scanning from the UI whether complete or not, is just not as reliable yet).

Speed while browsing has drammatically increased. I mean, I still find the web interface somewhat slow (Perl is slow, there's no way around that), but it's simply much faster than it was on the G4.

If I had a faster system I'd continue testing with that to get additional deltas, bt unfortunately I don't at the moment.

Seeing as the 6.5 stream uses mySQL, it only makes sense that Slimserver craves some CPU performance. While a lowly system may be able to stream tracks to one or more Squeezeboxes without much effort, access to the web UI - and therefore complex real-time queries, requires some muscle.

So what's the point? Just an observation. I'm not suggesting everyone go out and buy new machines. I'm not certain I can leave the mini as the server for long - it's one of my development and test machines aqnd I'd hate to have to interrupt the music while working on a problem with my own software.

If I can make a wish for 7.0 it's for increased stability and speed, while eliminating the outstanding bugs of the 6.5 stream. I think most of us would wait on new features to have something solid to use in the meantime.

stinkingpig
2006-11-29, 12:07
On 11/29/06, MelonMonkey
<MelonMonkey.2i1rsz1164825901 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I'm relatively new to the forum so I've been doing my best to read as
> much as I can to quickly get up to speed. I had plenty of time to
> fiddle with Slimserver without the use of an actual Squeezebox thanks
> to UPS (have to thank the Slim support guys for finally putting UPS in
> their place and sending out a replacement unit).
>
> Anyway, I've seen countless numbers of posts asking what hardware to
> use as a server and even more replies suggesting nearly any system will
> work fine. That even a lowly PII at a couple of hundred MHz is
> suitable, etc...
....

everyone's got different ideas about acceptable performance. I agree
with you, personally, but if someone's willing to put up with running
it on an NLSU2 or Via EPIA, good for them.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

georgem
2006-11-29, 12:10
I'm relatively new to the forum so I've been doing my best to read as much as I can to quickly get up to speed. I had plenty of time to fiddle with Slimserver without the use of an actual Squeezebox thanks to UPS (have to thank the Slim support guys for finally putting UPS in their place and sending out a replacement unit).

Anyway, I've seen countless numbers of posts asking what hardware to use as a server and even more replies suggesting nearly any system will work fine. That even a lowly PII at a couple of hundred MHz is suitable, etc...

I'm sure you can run Slimserver on an imbedded Micro if the software dependancies are all met, but a slow system is far from ideal.

I first installed Slimserver on one of the machines I keep on 24/7. A Mac server that runs a few development mySQL databases, bug tracking software and SVN. These services require very little CPU time as they're only access a few times per day.

The hardware consists of a Dual Processor 533MHz PowerMac G4 connected to my LAN with 100baseTX.

While browsing the web interface in cover mode I've been finding load times unacceptably slow. It's painful to use the web interface for extended periods. I'm sure some people may find it acceptable, but when I get better performance loading graphics intensive sites from the Internet, that's a problem for me.

Yesterday I increased the thumbnail size from 100 pixels to 120 pixels - which obviously made matters even worse.

Today as an experiment, I moved all the music over to an Intel Core Duo (1.66GHz) Mac mini. Its boot drive is a slow 2.5" model but the music is on the same 250GB external Firewire drive as I've been using all along.

I copied the whole preferences folder from the G4 and installed the current (11-29) nightly (same as the G4). The complete scan/indexing of the library was much faster than on the G4. That's not a huge concern as I'll usually clear the whole DB manually before going to bed if I need to load updated tracks (scanning from the UI whether complete or not, is just not as reliable yet).

Speed while browsing has drammatically increased. I mean, I still find the web interface somewhat slow (Perl is slow, there's no way around that), but it's simply much faster than it was on the G4.

If I had a faster system I'd continue testing with that to get additional deltas, bt unfortunately I don't at the moment.

Seeing as the 6.5 stream uses mySQL, it only makes sense that Slimserver craves some CPU performance. While a lowly system may be able to stream tracks to one or more Squeezeboxes without much effort, access to the web UI - and therefore complex real-time queries, requires some muscle.

So what's the point? Just an observation. I'm not suggesting everyone go out and buy new machines. I'm not certain I can leave the mini as the server for long - it's one of my development and test machines aqnd I'd hate to have to interrupt the music while working on a problem with my own software.

If I can make a wish for 7.0 it's for increased stability and speed, while eliminating the outstanding bugs of the 6.5 stream. I think most of us would wait on new features to have something solid to use in the meantime.
There have been few posts about artwork slowing things considerably, another one is the BBC radio stream. I wonder if you eliminate the artwork from the original setup if it is still unaceptable ? If it is artwork, maybe there is a way to optimize it.

I was running slimserver on PPC 266 Mhz linkstation like device and the only complain I had was that when browsing to music folder, there was some delay. Of course scanning is a different issue altogether.

snarlydwarf
2006-11-29, 12:20
It is a bit unclear from your posting: in your tests, were you using the web interface on the server (ie running firefox or whatever on the same machine as the files)?

That can slow things down noticably, especially on older machines -- there are a whole lot more "context changes" and, well, web browsers do suck. Not to mention Softsqueeze can be sorta sucky too (not that the program itself sucks, it is impressive what it does, but Sun's Java VM can be icky too).

So what you end up with is the footprint of Mysql, Slimserver, Firefox/IE/Whatever and Java...

bem 20812 0.0 13.6 318120 34968 pts/3 S 09:26 0:00 /home/bem/jre1.5.(etc)

Yes, that means that Softsqueeze is, for reasons known only to Sun, using 318M of virtual memory. Firefox is, at the moment, using only 100M...

Obviously these can have a pretty nasty impact on performance. The bad news is that there is very little Slim can do about Java sucking memory like a fat pig, or about all the mysterious memory leaks in Firefox... the Good News is that with a real squeezebox in hand, it doesn't really matter how sucky Java and Firefox are: just don't run them on the server.

You may want to try (while muttering at the UPS guy: what did they do, decide to route your package 3000 miles away in a shortcut? I've seen that :/) running Slimserver on the G4 machine, but using Softsqueeze on the Mini. This will let you get a better feel for how a real SB would perform (assuming the Mini has enough oomph to make the browser and java bloat less of an issue).

Good luck with UPS... at least most of the time they do reasonably well, but when they suck, they tend to -really- suck.

JJZolx
2006-11-29, 12:30
It is a bit unclear from your posting: in your tests, were you using the web interface on the server (ie running firefox or whatever on the same machine as the files)?

That can slow things down noticably, especially on older machines -- there are a whole lot more "context changes" and, well, web browsers do suck. Not to mention Softsqueeze can be sorta sucky too (not that the program itself sucks, it is impressive what it does, but Sun's Java VM can be icky too).

So what you end up with is the footprint of Mysql, Slimserver, Firefox/IE/Whatever and Java...

bem 20812 0.0 13.6 318120 34968 pts/3 S 09:26 0:00 /home/bem/jre1.5.(etc)

Yes, that means that Softsqueeze is, for reasons known only to Sun, using 318M of virtual memory. Firefox is, at the moment, using only 100M...
You can easily test the web interface and scanner without any clients, either Squeezebox or software, connected to the server. I have several instances of SlimServer running on my network like this.

peter
2006-11-29, 12:31
MelonMonkey wrote:
> Speed while browsing has drammatically increased. I mean, I still find
> the web interface somewhat slow (Perl is slow, there's no way around
> that), but it's simply much faster than it was on the G4.
Perl is not slow, you're talking nonsense. Loads of very big sites are
run on Perl. Slashdot is a prime example. Ever heard of the Slashdot
effect? It's what happens when Slashdot links to another site and the
*other* site goes to it's knees.

Yes, for raw operations C is faster and assembly language is even
faster, but in real world speed is limited by disk access times and
database transactions. Perl is no slower in accessing databases than
assembly language.

Regards,
Peter

JJZolx
2006-11-29, 12:44
So what's the point? Just an observation. I'm not suggesting everyone go out and buy new machines. I'm not certain I can leave the mini as the server for long - it's one of my development and test machines aqnd I'd hate to have to interrupt the music while working on a problem with my own software.

If I can make a wish for 7.0 it's for increased stability and speed, while eliminating the outstanding bugs of the 6.5 stream. I think most of us would wait on new features to have something solid to use in the meantime.
I agree with some of your observations. SlimServer needs a fast machine to be usable for many of us. I have zero tolerance for slow loading web sites and even less when that site is running on a local machine with 5% CPU load.

The slow-loading gallery issues seem to me to be a factor of a slow HTTP server (what can you do - it's written in Perl) and poor caching of artwork thumbnails. There are also ongoing issues with the database implementation, as others have pointed out - such as queries returning millions of rows to generate a single web page.

Keep in mind that for the gallery view when you change the thumbnail size, all those images are regenerated on the fly when the page is served (then they're served from a cache). I _still_ haven't figured out why they all can't be pregenerated during the scanning process. Probably easier caching them.

TonyCharman
2006-11-29, 12:44
... with you Mr MelonMonkey, I run Slimserver from a QNAP TS-101 NAS that I bought specifically for the job as I liked the idea of a dedicated machine with a small power need. It's just too slow!

Streaming seems fine. Maybe I use it differently from most others but I want view and play around with my collection from my PDA, Laptop or PC. Doing so is just like, as you say, loading a graphically intensive site from a poor/ overloaded server. And how many times have you hung around for the pages to load?!!

It spoils the whole experience for me - may have to put Slimserver back on a (fast) PC. Looking forward to seeing if Logitech have some ideas on this - perhaps they will add discreet track advance/back buttons to the top of the machine as well - oh the number of times I've wished for those!!

radish
2006-11-29, 13:02
It is a bit unclear from your posting: in your tests, were you using the web interface on the server (ie running firefox or whatever on the same machine as the files)?

That can slow things down noticably, especially on older machines -- there are a whole lot more "context changes" and, well, web browsers do suck. Not to mention Softsqueeze can be sorta sucky too (not that the program itself sucks, it is impressive what it does, but Sun's Java VM can be icky too).

So what you end up with is the footprint of Mysql, Slimserver, Firefox/IE/Whatever and Java...

bem 20812 0.0 13.6 318120 34968 pts/3 S 09:26 0:00 /home/bem/jre1.5.(etc)

Yes, that means that Softsqueeze is, for reasons known only to Sun, using 318M of virtual memory. Firefox is, at the moment, using only 100M...

Obviously these can have a pretty nasty impact on performance. The bad news is that there is very little Slim can do about Java sucking memory like a fat pig, or about all the mysterious memory leaks in Firefox... the Good News is that with a real squeezebox in hand, it doesn't really matter how sucky Java and Firefox are: just don't run them on the server.

You may want to try (while muttering at the UPS guy: what did they do, decide to route your package 3000 miles away in a shortcut? I've seen that :/) running Slimserver on the G4 machine, but using Softsqueeze on the Mini. This will let you get a better feel for how a real SB would perform (assuming the Mini has enough oomph to make the browser and java bloat less of an issue).

Good luck with UPS... at least most of the time they do reasonably well, but when they suck, they tend to -really- suck.

You seem to think pretty much everything sucks! Whilst I reserve judgment on UPS, and Firefox has been behaving itself for me lately, I take issue with your anti-Java rant. Having a JVM running certainly adds a memory-usage overhead to your app, it's typically around 10-20mb. Java apps can leak memory just as easily as anything else, but I notice you don't blame gcc for Firefox's memory problems :)

ModelCitizen
2006-11-29, 13:03
Yes, for raw operations C is faster and assembly language is even
faster, but in real world speed is limited by disk access times and
database transactions. Perl is no slower in accessing databases than assembly language.
Regards,
Peter
I'm not sure you are not completely correct on this. I know he's Mac (Linux plus GUI) based and that Slashdot runs on a *nix based servers but Perl on Windows seems quite inefficient. CYG-Win (or whatever it is) just does not cut the mustard.
MC

snarlydwarf
2006-11-29, 13:06
You can easily test the web interface and scanner without any clients, either Squeezebox or software, connected to the server. I have several instances of SlimServer running on my network like this.

Yes, but the OP said he was using Softsqueeze while waiting for UPS to actually deliver his Squeezebox (and I gather they sent it the long way.. slow enough that Slim actually shipped another one that will hopefully go more directly) and a web browser with album art displayed.

Java sucks, Firefox sucks (okay, so it sucks less than IE most of the time, but it still sucks :P) and tossing them onto the same machine as the actual server can be misleading performance-wise, especially since once the Squeezebox shows up the footprint of Softsqueeze and the JRE is usually irrelevant.

My recommendation as something to do while waiting for UPS is to put it back on his slow machine, but use the faster Mini as the web browser/softsqueeze part and see if that performance is better.

If it is, then he can use his g4 as a server (which is what he wants to do) and not worry about load. Effectively isolating the suckiness of JRE and browser from the server.

(And, yeah, all software sucks. So does hardware, but it usually has the dignity to catch fire and self-destruct when it sucks. :P)

ModelCitizen
2006-11-29, 13:07
There is a quite a difference between running SlimServer via the remote as opposed to the web gui. I ran a 192mb, 500ghz PII dedicated Windows XP machine for Slimserver 5.*/6.2/6.3 for a long while. Using the remote (my usual device) was fine but the web gui was pretty pants (I could even say it sucked). Scanning was slow but it always happened while I was asleep so I didn't care.
Unfortunately 6.5 was too much for this machine so I gave it away.
MC

snarlydwarf
2006-11-29, 13:12
You seem to think pretty much everything sucks! Whilst I reserve judgment on UPS, and Firefox has been behaving itself for me lately, I take issue with your anti-Java rant. Having a JVM running certainly adds a memory-usage overhead to your app, it's typically around 10-20mb. Java apps can leak memory just as easily as anything else, but I notice you don't blame gcc for Firefox's memory problems :)

All software sucks. This is hardly news...

"typically around 10-20mb" is certainly not the case I see.

Let's look again:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
bem 20812 0.0 11.4 321052 29276 pts/3 S 09:26 0:00 /home/bem/jre1.5.0_07/bin/java -Xbootclasspath/a

Yes, resident size is 29M... look at the virtual size: what the heck is it doing demanding 320M of virtual memory?

As for gcc/firefox: do recall that C makes no effort at all to provide for garbage collection and recycling. I don't blame my cable company for not picking up the trash: it isn't something they claim to do. I will blame my trash company if they don't visit, since that garbage collection is exactly what they promise.

gerph
2006-11-29, 13:15
I agree with some of your observations. SlimServer needs a fast machine to be usable for many of us. I have zero tolerance for slow loading web sites and even less when that site is running on a local machine with 5% CPU load.

The slow-loading gallery issues seem to me to be a factor of a slow HTTP server (what can you do - it's written in Perl)

I don't think you should really blame a language for an implementation. I've seen Perl servers that out-perform all-C servers or all-Assembler servers. I've seen Perl servers beaten hands down by all-C servers. I've seen Perl servers beaten by Perl servers.


... and poor caching of artwork thumbnails. There are also ongoing issues with the database implementation, as others have pointed out - such as queries returning millions of rows to generate a single web page.

Keep in mind that for the gallery view when you change the thumbnail size, all those images are regenerated on the fly when the page is served (then they're served from a cache). I _still_ haven't figured out why they all can't be pregenerated during the scanning process. Probably easier caching them.

When I originally installed SlimServer, around 6.1 time, I thought about it for a little bit whilst I looked at the configuration. The idea of resizing the images seemed silly to me, so I updated one of the scripts I have which regularly processes the entire collection so that it pre-generates thumbnails of exactly the right size for the server to use as 'CoverThumb.jpg'. Like you I felt that they should be pre-generated so that they're ready for use immediately. Why waste time serving up dynamic content when you don't have to ?

So I had CoverFront.jpg as the main graphic and CoverThumb.jpg as the thumbnail. Lovely. Only it looks like that's gone now that I've upgraded to 7.0. It makes me a little sad. But only a little, because I so rarely use the web interface. But it does seem silly to not be able to use pre-generated images that are intended for the purpose.

In fact, it's only because you mentioned the lack of pre-generated images that I decided to look and actually saw that the coverThumb option has gone from the configuration completely.

If I thought about it, I might re-add the functionality to Slim::Music::Artwork.pm, but it looks like the 'purpose' for the image is no longer known - in 6.2.1 Slim::Music::Info.pm was supplied a parameter to request either the 'cover' or the 'thumb'. This meant that it knew which to return. The new form doesn't seem to do anything like that so you wouldn't otherwise know. So it'd mean more extensive changes to restore that option. I'm sure there was a good reason for losing the ability to use pre-generated thumbnails, but it seems to me like a backward step.

stinkingpig
2006-11-29, 13:36
....
> I'm not sure you are not completely correct on this. I know he's Mac
> (Linux plus GUI) based and that Slashdot runs on a *nix based servers
> but Perl on Windows seems quite inefficient. CYG-Win (or whatever it
> is) just does not cut the mustard.
> MC
....

Cygwin is not Perl, it's a unix emulation layer. It lets you run Perl,
along with a lot of other software, but you're running the unix
version inside an emulated shell, and the performance is poor. A
little googling will show why.

Slimserver is using ActiveState Perl, which is a Windows build. I
develop with it as well, though nothing of the complexity of
Slimserver. There is no measurable performance difference in my simple
or complex scripts between ActiveState Perl running on XP and Perl.org
Perl running on SuSE.

Slimserver may conceivably have a performance difference based on OS,
but I rather doubt that it has anything to do with Perl on Windows,
until someone can step up with some numbers to prove otherwise. I am
definitely willing to believe that it's a little slower on OS X, which
is not so hot with multi-threaded applications like mysql
(http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=8). Even there
though, I doubt that there's a lot of impact on the Slimserver
specifically.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

Paul_B
2006-11-29, 13:54
What would be useful in this thread is to actually quote some stats. Slimserver allows you to measure the responsiveness of the various operations. In my case I started using 6.5 with QNAP TS-101, the web generation suffered with a response of the web pages averaging 2 to 5 seconds. I now have a VIA EPIA EN15000 running Slimserver on Windows 2003 server. The Flac files are still held on the remote QNAP TS-101 and this is connected via a wireless bridge running at 54Mbps. The Slimserver web interface is now fine for me.

The Web Page Build is now around 0.5 seconds

radish
2006-11-29, 14:58
"typically around 10-20mb" is certainly not the case I see.

Let's look again:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
bem 20812 0.0 11.4 321052 29276 pts/3 S 09:26 0:00 /home/bem/jre1.5.0_07/bin/java -Xbootclasspath/a

Yes, resident size is 29M... look at the virtual size: what the heck is it doing demanding 320M of virtual memory?

Did you read what I wrote? I said that a JVM adds 10-20mb of overhead to an app - in other words a Java version of Hello World would take roughly that much memory - it's what's used by the JVM itself. I did NOT say that all Java apps take 10-20mb of memory total - I'm responsible for apps which have image sizes in the 10's of GB. And, I might add, they'd take that much regardless of what language I implemented them in.

In your example _Softsqueeze_ is taking that much memory, not "Java" - unless you have some evidence as to what that memory is being allocated for it's a stretch to blame some mysterious suckage of Java. More likely, the Softsqueeze app has (for whatever reason) built a lot of objects.



As for gcc/firefox: do recall that C makes no effort at all to provide for garbage collection and recycling. I don't blame my cable company for not picking up the trash: it isn't something they claim to do. I will blame my trash company if they don't visit, since that garbage collection is exactly what they promise.
Completely irrelevant. You are looking at Softsqueeze taking 320mb and saying "that's too much" without any understanding of what's actually going on under the hood or whether it's really using that memory. You then proceed to blame this supposed problem on the platform which the app is running on, again with no evidence that it is at fault in any way.

Remember that garbage collection only cleans up things which are actually garbage. It's trivial to write an app which eats up every byte of available memory in C++, it's just as easy in Java. Neither can be held responsible for the actions of the programmer.

(Note: I'm not laying any blame on Softsqueeze, I have no idea what it's doing and am not suggesting it's leaky :) )

That aside, memory management under Java is a complex subject, just as it is in any other environment. It's also handled in a very different manner to something like C++ which leads some people to assume it's broken just because it doesn't behave as they expect.

MelonMonkey
2006-11-29, 15:59
Sorry I wasn't a bit more clear in my opening post regarding some details.

I'm running with a real Squeezebox now. I thanked the Slim support team for handling the situation with UPS. UPS says they delivered the original package yet I received nothing. They had no signature because they said it was left at the front of the house. Nice job. In 2003 my car was stolen from the driveway while I slept. They thought they should trust the neighborhood with a US$340 package while no one was home (that's the price with shipping).

I also wasn't accessing the web server from the same system. I've tested using a third system, a PowerBook G4 (my main workhorse), both with Camino and Safari and wired plus wireless connection. I no longer run Firefox as it's a huge bloated memory pig and so full of bugs that it's practically useless on a Mac.

I also forgot to say that the Mini has 1GB of memory while the G4 had only 640MB, both running 10.4.8.

I thought that the artwork would be generated during the build/scan but I have seen first hand that it's not (which is exactly what's been written in this thread by others). All the artwork in my music has been imbedded using iTunes 7.x and collected from various sources. The images range in size from 200x200 to 800x800 and probably average in the middle somewhere.

The tracks are all stored neatly in their own album folders in a top-level hierarchy arranged by artist, so I wouldn't mind running some script to generate the required external images ahead of time.

I have no doubt most of the time spent by the CPU is with the sql queries and I didn't mean to imply that the blame rested on the shoulders of the Perl implementation. But to call Perl fast has to be taken in context. Sure, it can be considered adequate in terms of a scripting/interpreted language, but look at the broader picture which includes compiled languages like C. Execution times of 100x faster for the same piece of code would not be uncommon. Whether speeding up portions or all of the current Perl modules would help the web serving performance drammatically is anyone's guess (I suppose anyone touching that code can comment with better hypothesis). But having some portions compiled would certainly not adversely affect runtime speed.

So, how does one time the web interface as was briefly mentioned earlier in this topic? I'll try getting some numbers for various scenarios.

snarlydwarf
2006-11-29, 16:54
I'm running with a real Squeezebox now. I thanked the Slim support team for handling the situation with UPS. UPS says they delivered the original package yet I received nothing. They had no signature because they said it was left at the front of the house. Nice job. In 2003 my car was stolen from the driveway while I slept. They thought they should trust the neighborhood with a US$340 package while no one was home (that's the price with shipping).

UPS seems to have a "if it is worth stealing, leave it on the step; if it is worthless, leave a yellow card and make them come get it" rule. How they know what is worthless/worthwhile I never have figured out.


I also wasn't accessing the web server from the same system. I've tested using a third system, a PowerBook G4 (my main workhorse), both with Camino and Safari and wired plus wireless connection. I no longer run Firefox as it's a huge bloated memory pig and so full of bugs that it's practically useless on a Mac.

Well it has less bugs than IE, but yes, it sucks tons of RAM, especially if you leave it running for a while and even more so if pages auto-refresh. (Even 2.0 seems to leak those...)



I have no doubt most of the time spent by the CPU is with the sql queries and I didn't mean to imply that the blame rested on the shoulders of the Perl implementation. But to call Perl fast has to be taken in context. Sure, it can be considered adequate in terms of a scripting/interpreted language, but look at the broader picture which includes compiled languages like C. Execution times of 100x faster for the same piece of code would not be uncommon. Whether speeding up portions or all of the current Perl modules would help the web serving performance drammatically is anyone's guess (I suppose anyone touching that code can comment with better hypothesis). But having some portions compiled would certainly not adversely affect runtime speed.

Be careful: Perl -is- compiled. It just has a very fast compiler. (It is compiled to bytecode, which is actually pretty efficient.) In cases were Perl shines (like pattern matching), it can be very much on par with C, especially since a ton of very strange optimizations go on in libperl: "commonly used functions" are grouped together, for example, so that they will have a tendency to always stick in the CPU cache.

The real difference you are seeing is probably in constant resizing of images, and the lack of a real multithreaded http server. There has been a lot of cleanup of the number of SQL calls so they shouldn't be too painful any more.



So, how does one time the web interface as was briefly mentioned earlier in this topic? I'll try getting some numbers for various scenarios.

There are some debugging flags you can turn on for timing http transactions, and you can also use the "Server and Network Health" option under Health, it should show you how certain operations are typically timing.

Since you are on MacOS, you may also want to turn on the forking for HTTP on the Performance setting page. This may speed up web clients by pawning off some of the multithreading onto the OS instead of faking it in Perl. (That is probably the worst thing about the perl implementation ... that perl doesn't deal well with multithreaded applications so it has to be faked.)

640M shouldn't really be a problem... I have... um... 256M. I'm cheap. The CPU isn't the fastest, but then you have a dual cpu, so that should help a bit since the 6.5 model lets you have at least some fake multithreading with the SQL stuff moved into mysqld. Turning on forking for http may help use both processors as well.

peter
2006-11-30, 03:47
ModelCitizen wrote:
> There is a quite a difference between running SlimServer via the remote
> as opposed to the web gui. I ran a 192mb, 500ghz PII dedicated Windows
> XP machine for Slimserver 5.*/6.2/6.3 for a long while. Using the
> remote (my usual device) was fine but the web gui was pretty pants (I
> could even say it sucked). Scanning was slow but it always happened
> while I was asleep so I didn't care.
> Unfortunately 6.5 was too much for this machine so I gave it away.
>
I'm still on 6.2.2 so perhaps I'll start running into problems when I
upgrade. My current machine has no problems running slimserver. If it
does run into problems I won't be blaming Perl, which is plenty fast in
my experience, but the slimserver coders. The speed of software is
mainly impacted by poor design decisions.

In the case of slimserver I've been wondering about the wisdom of
putting all tasks in one program. Good candidates for running in
seperate modules would probably be the music library indexer (I believe
they actually did that in 6.5) and the web interface. A 'slim' core
slimserver module doing the core business that communicates with the
other modules would seem more logical to me.

I don't mean to imply that the current slimserver is poorly designed. In
fact, I think the programmers did a marvellous job. Also, to butcher a
Dutch expression: The best helmsmen are usually on the shore. ;)

Regards,
Peter

mherger
2006-11-30, 04:51
> If it does run into problems I won't be blaming Perl, which is plenty
> fast in my experience, but the slimserver coders. The speed of software
> is mainly impacted by poor design decisions.
[..]
> I don't mean to imply that the current slimserver is poorly designed.

How should these to paragraphs be interpreted?

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

peter
2006-11-30, 05:36
Michael Herger wrote:
>> If it does run into problems I won't be blaming Perl, which is plenty
>> fast in my experience, but the slimserver coders. The speed of
>> software is mainly impacted by poor design decisions.
This is a general remark, not specifically targeted at slimserver.
> [..]
>> I don't mean to imply that the current slimserver is poorly designed.
>
> How should these to paragraphs be interpreted?
1. Slow software is IMHO usually bad programming & design
2. If SS is (too) slow, the cause *may be* bad design and not Perl (I'm
no slimserver expert)
3. I've often wondered if it wouldn't be better to split things up in
specialized modules (I may be wrong)

One of the reasons Perl is perceived to be slow is that Perl script
execution preceded by two things:
- Loading of a relatively bulky compiler
- Compilation of the source code

Using a packaged 'perlapp' bundle (as the Windows slimserver usually
does) adds the overhead of unpacking the compiler en sourcecode.

These extra operations are not required for compiled C-code so it would
seem that C-code must always be much faster than Perl. The trick is,
however, that the unpacking, compiler loading and copiling operations
are only done when the PerlApp is first started up. When the Perl code
is already compiled and running, performance can be pretty good.

Some people have experience in running cgi-bin versions of Perl scripts,
that can be very slow because on each page access the compiler must be
loaded and the script must be compiled. The overhead is very large in
this case. That's why smart webmasters use mod_perl, in which case the
Perl interpreter is part of the Apache server (like mod_php). In that
case Perl websites suddenly become pretty fast. Slower than C, yes, but
C has other disadvantages.

Slimserver is a long running daemon, which IMHO means that load and
compile overhead are mostly irrelevant.

Regards,
Peter

peter
2006-11-30, 05:41
radish wrote:
> Completely irrelevant. You are looking at Softsqueeze taking 320mb and
> saying "that's too much" without any understanding of what's actually
> going on under the hood or whether it's really using that memory. You
>
It's just too much for a music player, radish...

Regards,
Peter

Eric Seaberg
2006-11-30, 14:29
I have no doubt most of the time spent by the CPU is with the sql queries and I didn't mean to imply that the blame rested on the shoulders of the Perl implementation.

I was running the server on my G5 (2x2.3G w/ 5G RAM) and ended up getting a reconditioned Mac MINI. It's the new dual 1.8GHz w/ 2GB RAM. I have an external 500GB FW drive holding the library.

I, too, was wondering what the CPU did during streaming and opened up the App "Activity Monitor" in Apple Utilities folder. Perl takes VERY LITTLE CPU power, actually. The "thief" is LAME encoding to the individual devices. If I'm playing ONLY on my Transporter, LAME does nothing due to the fact that my wireless connection to it is 5-feet away from my Airport... translation, 100% signal and the file format remains as native as possible.

My SB3 in the Master Bedroom only gets 50% signal strength, so I have to limit its bandwidth to 320kbps to work without hiccups. Once LAME is engaged for the SB3, the Transporter also receives a 320k limited stream. When it's running, LAME hits one of the CPU Cores @ 95%+. This isn't continuous but varies as LAME is required.

When bandwidth is limited, I've got the LAME quality set to 3 for the TP, 6 for the SB3 and default of 9 for any connected computers. Sync is working GREAT (now) and hiccups NEVER happen anymore.

peter
2006-12-01, 01:08
TonyCharman wrote:
> It spoils the whole experience for me - may have to put Slimserver back
> on a (fast) PC. Looking forward to seeing if Logitech have some ideas
> on this - perhaps they will add track discreet advance/back buttons to
> the top of the machine as well - oh the number of times I've wished for
> those!
That's a good idea. In fact, let's add an equally discreet pause button,
volume up/down and a power toggle.

Regards,
Peter

stinkingpig
2006-12-01, 07:31
On 12/1/06, Peter <landen-slimp (AT) frg (DOT) eur.nl> wrote:
> TonyCharman wrote:
> > It spoils the whole experience for me - may have to put Slimserver back
> > on a (fast) PC. Looking forward to seeing if Logitech have some ideas
> > on this - perhaps they will add track discreet advance/back buttons to
> > the top of the machine as well - oh the number of times I've wished for
> > those!
> That's a good idea. In fact, let's add an equally discreet pause button,
> volume up/down and a power toggle.
>
> Regards,
> Peter

Don't forget the button that lights up the buttons, and the six
programmable favorites buttons, and the windows logo and the apple
logo and the penguin button, and the number pad and cursor keys.

I wouldn't be surprised to see a knob or trackwheel or joystick, but I
don't think a set of buttons is going to happen. I've been wrong
before though :)
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

Mark Lanctot
2006-12-03, 19:48
Slimserver may conceivably have a performance difference based on OS,
but I rather doubt that it has anything to do with Perl on Windows,
until someone can step up with some numbers to prove otherwise. I am
definitely willing to believe that it's a little slower on OS X, which
is not so hot with multi-threaded applications like mysql
(http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=8). Even there
though, I doubt that there's a lot of impact on the Slimserver
specifically.

Still, it seems that there's an awful lot of forum posts with comments about SlimServer serving up pages slowly where the user is running OS X.

I'm using a relatively fast Windows machine (2.8 GHz P4 with 512 MB RAM) and my only other experiment has been with a much slower 1.2 GHz AMD Duron with 256 MB RAM on Ubuntu Linux, but in both cases, page generation is just about instantaneous for all intents and purposes. Even album art image generation is very fast.

bgriffis
2006-12-03, 21:44
I've lately been feeling more fed up with the response time of SlimServer. I'm not sure if I never noticed it before or if it has actually gotten slower since the 6.5 release. I'm running SS on WinXP SP2 with a 2.6GHz P4 HT with 1GB RAM and RAID0. For example if I click on a song to delete it from the playlist I count about 6 seconds before that actually occurs. That's an ETERNITY! I decided I didn't want to hear the album I had just queued up and it took forever to get the freaking thing deleted!

I'd love to see performance take center stage for the 7.0 release. I'm not sure where the bottleneck is, but it would be great to see someone from Slim Devices do that analysis and then take the appropriate corrective action. Perhaps that means restructuring some of the Perl code or maybe even re-writing critical portions in C. I don't really care what needs to be done, just so long as SS becomes more responsive!

(Perhaps there's a setting I need to change -- if so please kindly respond!)

Pale Blue Ego
2006-12-03, 21:58
A few thoughts:

RAM is your friend, the more the better.

The 6.5+ MySQL-based Slimserver builds are much quicker than the old SQLite backend.

The best performance I have seen, comparing several Windows and Linux installations on the same machine, has been ClarkConnect, a Linux-based server OS which makes excellent use of resources. It has low overhead, no GUI, and any extra RAM is used to speed up file throughput and access times. It is easily administered via a web interface from any other computer on the network.

stinkingpig
2006-12-03, 22:11
On 12/3/06, bgriffis
<bgriffis.2i9y8z1165207501 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I've lately been feeling more fed up with the response time of
> SlimServer. I'm not sure if I never noticed it before or if it has
> actually gotten slower since the 6.5 release. I'm running SS on WinXP
> SP2 with a 2.6GHz P4 HT with 1GB RAM and RAID0. For example if I click
> on a song to delete it from the playlist I count about 6 seconds before
> that actually occurs. That's an ETERNITY! I decided I didn't want to
> hear the album I had just queued up and it took forever to get the
> freaking thing deleted!
>

That's crazy bad performance. Most people with that class of hardware
are not seeing that sort of problem. Ergo, you've got something wrong.
Maybe you should open the web interface, click help, click server and
network health, and click enable performance monitoring. Then later
on, you could go back to that page and click server statistics or
player statistics, and you'd have some data to work with.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

JJZolx
2006-12-03, 22:12
One thing that may help a bit is to unload any plugins that you're not using. Restart SlimServer after going into the server settings and unchecking the ones you don't want. If you don't use Rhapsody, you can disable the UPnP client in the server by using the --noupnp command line option. If you run SlimServer as a service you'll have to dig into the registry and ad it there as a startup parameter.

If you're running on a dedicated server, you can also run your own instance of MySQL and tweak some of its startup settings. Throwing some more memory at the MySQL's InnoDB engine may help some. If you do this and have a SlimServerMySQL service running on your system (6.5.1 or 7.0) then set the startup type of SlimServerMySQL to 'Disabled'.

Mitch Harding
2006-12-04, 14:58
I'm running SS 6.5.1 (a nightly from a couple weeks back) on WinXP SP2 with
a 1GHz Athlon and 512MB RAM. My typical playlists have 3-4k tracks. When I
add or delete tracks from them, or try to save them, the web interface takes
5-10 seconds to respond to each transaction. While I am doing this, the
clocks on my SBs often skip several seconds.

This happens whether I make the changes locally on the SS system itself (via
a web interface to localhost:9000) or from a different system, so I would be
surprised if this was a network issue.

I had always assumed this was normal SS behavior. Is there someone out
there working with 3-4k playlists who is experiencing better response time?

On 12/3/06, Jack Coates <jack (AT) monkeynoodle (DOT) org> wrote:
>
> On 12/3/06, bgriffis
> <bgriffis.2i9y8z1165207501 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> >
> > I've lately been feeling more fed up with the response time of
> > SlimServer. I'm not sure if I never noticed it before or if it has
> > actually gotten slower since the 6.5 release. I'm running SS on WinXP
> > SP2 with a 2.6GHz P4 HT with 1GB RAM and RAID0. For example if I click
> > on a song to delete it from the playlist I count about 6 seconds before
> > that actually occurs. That's an ETERNITY! I decided I didn't want to
> > hear the album I had just queued up and it took forever to get the
> > freaking thing deleted!
> >
>
> That's crazy bad performance. Most people with that class of hardware
> are not seeing that sort of problem. Ergo, you've got something wrong.
> Maybe you should open the web interface, click help, click server and
> network health, and click enable performance monitoring. Then later
> on, you could go back to that page and click server statistics or
> player statistics, and you'd have some data to work with.
> --
> "I spent all me tin with the ladies drinking gin,
> So across the Western ocean I must wander" -- traditional
>

Triode
2006-12-04, 15:05
6.5 is generally much better than 6.2/6.3, but there may be some special cases which take longer and which could be improved.

It would help if people experiencing long delays could enable performance monitoring and post the output of the server diagnostics for all events taking more than 0.5 seconds [see second part of the following]:
http://wiki.slimdevices.com/index.cgi?DiagnosingPerformanceIssues

Mitch Harding
2006-12-04, 15:11
I'll try to do this sometime this week and get back to you.

I love my SB's either way, but if the performance could be improved, I would
not complain!

On 12/4/06, Triode <Triode.2ibamn1165270201 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> 6.5 is generally much better than 6.2/6.3, but there may be some special
> cases which take longer and which could be improved.
>
> It would help if people experiencing long delays could enable
> performance monitoring and post the output of the server diagnostics
> for all events taking more than 0.5 seconds [see second part of the
> following]:
> http://wiki.slimdevices.com/index.cgi?DiagnosingPerformanceIssues
>
>
> --
> Triode
> ------------------------------------------------------------------------
> Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
> View this thread: http://forums.slimdevices.com/showthread.php?t=30145
>
>

stinkingpig
2006-12-04, 20:03
On 12/4/06, Mitch Harding <mitcharf (AT) gmail (DOT) com> wrote:
> I'm running SS 6.5.1 (a nightly from a couple weeks back) on WinXP SP2 with
> a 1GHz Athlon and 512MB RAM. My typical playlists have 3-4k tracks. When I
> add or delete tracks from them, or try to save them, the web interface takes
> 5-10 seconds to respond to each transaction. While I am doing this, the
> clocks on my SBs often skip several seconds.
>
> This happens whether I make the changes locally on the SS system itself (via
> a web interface to localhost:9000) or from a different system, so I would be
> surprised if this was a network issue.
>
> I had always assumed this was normal SS behavior. Is there someone out
> there working with 3-4k playlists who is experiencing better response time?

Hm, my comment was assuming a different use case; I don't build
massive playlists and make changes in them; people who do that should
comment on their performance. Still, as Triode points out, performance
problems won't go away without some help in troubleshooting.

--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

bgriffis
2006-12-05, 07:11
Thanks for the suggestions. I have disabled all plugins EXCEPT for CLI, clock screensaver, and network health. I then restarted SS so my new plugin selections would take effect, but it was still very slow. I enabled the network health monitoring and it reported that Server Response Time is poor. (Tell me something I don't know!) In the statistics section it broke down the components of the server and the main culprit appears to be the web page build:

Web Page Build
The length of time taken to build each web page.

< 0.002 : 0 : 0%
< 0.005 : 0 : 0%
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 1 : 7% ###
< 0.05 : 2 : 13% ######
< 0.1 : 2 : 13% ######
< 0.5 : 4 : 27% #############
< 1 : 2 : 13% ######
< 5 : 0 : 0%
>=5 : 4 : 27% #############
max : 10.843141
min : 0.018849
avg : 2.926769

So how do I improve such a statistic? Right now it sucks! Here are a couple more that might be noteworthy but don't appear as significant as that first one:

Timer Lateness
The time between when a timer task was scheduled and when it is run.

< 0.002 : 19 : 15% #######
< 0.005 : 5 : 4% #
< 0.01 : 37 : 28% ##############
< 0.015 : 10 : 8% ###
< 0.025 : 11 : 8% ####
< 0.05 : 4 : 3% #
< 0.1 : 3 : 2% #
< 0.5 : 8 : 6% ###
< 1 : 2 : 2%
< 5 : 31 : 24% ###########
>=5 : 1 : 1%
max : 5.142914
min : 0.000013
avg : 0.599746




Server Response Time
The response time of the server - the time between successive calls to select.

< 0.002 : 585 : 63% ###############################
< 0.005 : 91 : 10% ####
< 0.01 : 104 : 11% #####
< 0.015 : 2 : 0%
< 0.025 : 10 : 1%
< 0.05 : 14 : 1%
< 0.1 : 91 : 10% ####
< 0.5 : 16 : 2%
< 1 : 5 : 1%
< 5 : 16 : 2%
>=5 : 0 : 0%
max : 2.568374
min : 0.000066
avg : 0.049329

Any thoughts on how to improve this? Thanks!

Brad

Triode
2006-12-05, 12:49
Could you set the warning level to 0.5 and post the output of the log too? [see wiki referenced below for detailed steps]

The results you have posted are a summary of what is going on and indicate that web page builds are taking a long time. At present we optimise to avoid streaming drop outs, which should keep the response time down, but you do see some longer times for this too. It would be good to find out what is causing this.

Do your hard disks spin down?

Paul_B
2006-12-05, 13:58
Triode,

This the sort of thing you are looking for?

Web Page Build > 0.5 : 3.87970Backtrace:

frame 0: Slim::Utils::PerfMon::log (/PerlApp/Slim/Web/HTTP.pm line 829)
frame 1: Slim::Web::HTTP::generateHTTPResponse (/PerlApp/Slim/Web/HTTP.pm line 687)
frame 2: Slim::Web::HTTP::processURL (/PerlApp/Slim/Web/HTTP.pm line 533)
frame 3: Slim::Web::HTTP::processHTTP (/PerlApp/Slim/Networking/Select.pm line 238)
frame 4: Slim::Networking::Select::select (slimserver.pl line 492)
frame 5: main::idle (slimserver.pl line 35)
frame 6: PerlSvc::Startup (perlsvc.pl line 1482)
frame 7: PerlSvc::_startup (slimserver.pl line 0)
frame 8: (eval) (slimserver.pl line 0)

Page: browsedb.html

Web Page Build > 0.5 : 0.85548Backtrace:

frame 0: Slim::Utils::PerfMon::log (/PerlApp/Slim/Web/HTTP.pm line 829)
frame 1: Slim::Web::HTTP::generateHTTPResponse (/PerlApp/Slim/Web/HTTP.pm line 687)
frame 2: Slim::Web::HTTP::processURL (/PerlApp/Slim/Web/HTTP.pm line 533)
frame 3: Slim::Web::HTTP::processHTTP (/PerlApp/Slim/Networking/Select.pm line 238)
frame 4: Slim::Networking::Select::select (slimserver.pl line 492)
frame 5: main::idle (slimserver.pl line 35)
frame 6: PerlSvc::Startup (perlsvc.pl line 1482)
frame 7: PerlSvc::_startup (slimserver.pl line 0)
frame 8: (eval) (slimserver.pl line 0)

Page: browsedb.html

Triode
2006-12-05, 14:59
Don't need the backtrace set, just the following:
To help diagnose poor server reponse times, follow the following steps:

* Enable Performance Monitoring on the Network and Server Health page
* Select the Server Statistics page
* Enter "0.5" in the box at the very bottom of the page between High and Set All and then press "Set All"
* Leave the server to run for some time until you experience poor performance

This should give one line per entry and logs all events taking longer than 0.5 seconds. (If you make the 0.5 less then you get more information as you reduce the threshold of when to generate a log entry, but 0.5 is a good target performance. In an ideal world you see nothing as everything takes less than 0.5 seconds, but probably need a very fast server for that!)

RainmanRam
2006-12-24, 10:47
I'm having extramly slow web response from slim server 6.5 on a 2.8 GHz dual core with 1 Gig of ram runing xp sp2 as well. The initial web page takes about 15 seconds to open (even on the server). Other web pages take 5+ seconds for the most part. Painfully slow.

I've enabled server statistics and set the warning threshold to .5. I have not cleaned out the plugins however.

I played around n the web interface for a bit and don't notice a difference when I'm streaming and when I'm not but have come up with the following log:

Response Time > .5 : 2.66207
Response Time > .5 : 2.65432
Timer Late > .5 : 5.39169
Timer Late > .5 : 5.35924
Timer Late > .5 : 5.29809
Timer Late > .5 : 4.77590
Web Page Build > .5 : 5.64807 Page: playlist.html
Select Task > .5 : 5.65810 Slim::Web::HTTP::processHTTP
Timer Late > .5 : 1.79268
Web Page Build > .5 : 0.51666 Page: browsedb.html
Select Task > .5 : 0.52908 Slim::Web::HTTP::processHTTP
Response Time > .5 : 2.63811
Timer Late > .5 : 2.52953
Response Time > .5 : 2.64287
Timer Late > .5 : 4.91616
Timer Late > .5 : 4.93991
Database Access > .5 : 2.51656 DBIx select_single
Response Time > .5 : 2.62078
Timer Late > .5 : 7.56193
Timer Late > .5 : 6.90818
Timer Late > .5 : 5.95956
Timer Late > .5 : 5.00998
Web Page Build > .5 : 8.24471 Page: playlist.html
Select Task > .5 : 8.25496 Slim::Web::HTTP::processHTTP
Timer Late > .5 : 2.79036
Timer Late > .5 : 1.77821
Web Page Build > .5 : 0.59839 Page: browsedb.html
Select Task > .5 : 0.61241 Slim::Web::HTTP::processHTTP
Web Page Build > .5 : 0.63281 Page: browsedb.html
Select Task > .5 : 0.64608 Slim::Web::HTTP::processHTTP
Request Task > .5 : 0.56606 Notify: Plugins::RandomPlay::Plugin::commandCallback
Response Time > .5 : 0.59826


The first thing I should note is that if one entry is supposed to be present for each slow response, that is not the case. EVERY web page I call for takes 5 seconds or more to display and there aren't nearly as many entries as pages I've opened.

Seems to be quite a few late timers - don'tcha think? I don't know the code well enough to understand the relationship of timers with the other items on this list but I suspect there is some interdependency going on here.

The other interesting tidbit of data I can provide is that for the most part slim.exe doesn't consume more than 2% of the CPU as indicated by taskman. The only place I see slim.exe spike is when I request it hit the database by browsing music. Then I see a spike of 25-30% CPU usage for one blip on taskman. After that slim goes quiet with a blip of 1-2% for the 5-15 seconds it takes to display the page. If I don't access the database, I don't see the spike in CPU at the web request (setting up statistics, and other non-db related pages).

5-15 second wait times are the norm on this machine, not the exception, so I can gather more data if someone can tell me how to get it.

One last note, I don't recall this much pain with the web pages slow response a month or so ago (I could be wrong) so I suspect one of the XP updates might be the culprit (I stay updated).

- Ray

Triode
2006-12-24, 13:20
Are you using the default skin. If so please try the latest 6.5.1 as this should speed up the time to build the playlist which looks like it is the web page taking the longest time to build.

In addition to this, the database line lead me to suspect that something is causing the database to respond slowly - you could try disabling any virus checker you have as a temporary measure to see if this helps.

"Timer Late" is usually a symptom of a problem rather than the problem itself.

RainmanRam
2006-12-25, 09:19
I tried disabling my virus checker on the server and accessing slimserver via localhost and it was lightning fast. I reenabled my virus checker and it still was lightning fast. Unfortunately, I didn't try the local server before disabling the virus checker so I'm not convinced it was the problem. I also had stopped and restarted slimserver several times since the last time I noticed the localhost being slow. I'll let it run for a few days and check if it slows down.

Even though the localhost is lightning fast (at the moment), accessing the slim across my network is still incredibly slow.

So, what I (think I) know at the moment is that there appear to be two problems. The first being when the localhost slows down -- possibly the virus checker and I'll test that theory the next time I see localhost being slow. The second problem being remote access slowness.

I did not install 6.5.1 since the localhost appears to be speedy now which seems to imply something in the communications between the two machines is causing the remote access slow down.

Since I suspect slim server isn't doing anything different for local vs. remote access (or is it?), I'm guessing the problem lies elsewhere, but where? I'm using http://<servername>:9000 to access slim on windows xp sp2. All other operations to the server are quick (remote desktop, file sharing, backups, etc.). I'm at a loss...

- Ray

wcburnette
2006-12-26, 19:11
I have a Mac mini, 512MB ram, 1.33 Ghz G4, with upgraded 5400rpm 100GB internal drive, and all music stored on an external Maxtor 300GB drive. I have three SqueezeBox v3s, one wired, and the other two wireless.

I have ~35K tracks. I just wiped my hard drive, and installed a fresh copy of 10.4.8, and the latest daily build (12-25) of 6.5.1. I use iTunes to organize my tracks and playlists.

From the very beginning, I have had performance issues with changing playlists from the SB3s. I used to run several plugins, but did the clean install to determine if any of those were causing the issue. Right now, the installation is as clean as possible, with the "Disable library statistics" option. I also set the server to a -16 priority. The only application running in the background is iTunes, but it is not playing or doing anything.

As a reference, I created 4 playlists, 80 songs, 300 songs, 2250 songs, and 22000 songs. Following the instructions I have read in this post, I set up performance monitoring to show all operations that take longer than 1.0 sec. I then performed the following tests, to show just how long the server takes to switch. Right now, two slims are set to sync, and the third is not. Once playback begins, there is no stuttering or pauses during playback.

Delays ranged from 7 seconds in the best case to nearly 4 minutes in the worst case. This seems to be significantly worse performance than I see posted about in other places on the site. I have been plagued with this issue since I began several months ago with this setup... It has never been quick. I have 1GB of ram on its way, but I also tried running this on a PowerBook G4 with 1.25GB ram, and the performance was not much better. The library was freshly imported, and the slimserver I just rescanned the library using "Clear library and rescan everything" the night before (which takes over three hours).

Can anyone offer a suggestion on why the slimserver performance is so horrible? Or anything I can do to fix it? Could corrupt music files be the culprit?

Timing for the playlist switches is listed below. I started the clock when I hit "Play" on the remote and stopped it when music played from the speakers:

switch from 22000 playlist -> 80 playlist: 57 sec
80 -> 300: 16 sec
300 -> 80: 7 sec
80 -> 300: 15 sec
300 - > 2250: 80 sec
2250 -> 300: 16 sec
300 -> 2250: 88 sec
2250 -> 22000: 240 sec (4 min !)

I have attached the log file for this sequence of events... a small excerpt of the last 4 playlist switches are shown below:

2006-12-26 16:49:13.6167 Request Task > 1.0 : 60.40402 Notify: Slim::Player::Playlist::modifyPlaylistCallback
2006-12-26 16:49:56.4850 Request Task > 1.0 : 1.30956 Execute: Slim::Control::Commands::playlistXtracksCommand
2006-12-26 16:49:56.4875 Request Task > 1.0 : 1.34285 Execute: Slim::Control::Commands::buttonCommand
2006-12-26 16:49:56.4880 Timer Task > 1.0 : 1.34682 Slim::Hardware::IR::checkRelease
2006-12-26 16:49:56.4919 Response Time > 1.0 : 1.35257
2006-12-26 16:49:57.2914 Timer Late > 1.0 : 1.54495
2006-12-26 16:49:57.3133 Timer Late > 1.0 : 1.55636
2006-12-26 16:49:57.3264 Timer Late > 1.0 : 1.55630
2006-12-26 16:49:57.3383 Timer Late > 1.0 : 1.55020
2006-12-26 16:49:57.3907 Timer Late > 1.0 : 1.39060
2006-12-26 16:49:57.4084 Timer Late > 1.0 : 1.23776
2006-12-26 16:50:05.8359 Request Task > 1.0 : 9.25155 Notify: Slim::Player::Playlist::modifyPlaylistCallback
2006-12-26 16:50:27.5006 Request Task > 1.0 : 2.09362 Execute: Slim::Control::Commands::buttonCommand
2006-12-26 16:50:27.5030 Request Task > 1.0 : 2.10049 Execute: Slim::Control::Commands::irCommand
2006-12-26 16:50:27.5046 Response Time > 1.0 : 2.10682
2006-12-26 16:50:27.5188 Timer Late > 1.0 : 1.85805
2006-12-26 16:50:27.5213 IR Delay > 1.0 : 2.12298
2006-12-26 16:50:27.6044 Timer Late > 1.0 : 1.89278
2006-12-26 16:50:27.6052 IR Delay > 1.0 : 2.09913
2006-12-26 16:50:27.6097 Timer Late > 1.0 : 1.60964
2006-12-26 16:50:27.6167 IR Delay > 1.0 : 2.11035
2006-12-26 16:50:27.6213 Timer Late > 1.0 : 1.48516
2006-12-26 16:50:27.6282 Timer Late > 1.0 : 1.48050
2006-12-26 16:50:38.8838 Request Task > 1.0 : 5.42240 Execute: Slim::Control::Commands::playlistXtracksCommand
2006-12-26 16:50:38.8858 Request Task > 1.0 : 5.44032 Execute: Slim::Control::Commands::buttonCommand
2006-12-26 16:50:39.0105 Timer Task > 1.0 : 5.56844 Slim::Hardware::IR::checkRelease
2006-12-26 16:50:39.0131 Response Time > 1.0 : 5.57213
2006-12-26 16:50:39.0785 Timer Late > 1.0 : 5.45754
2006-12-26 16:50:39.2074 Timer Late > 1.0 : 5.56088
2006-12-26 16:50:39.2188 Timer Late > 1.0 : 5.56322
2006-12-26 16:50:39.2301 Timer Late > 1.0 : 5.23001
2006-12-26 16:50:39.2442 Timer Late > 1.0 : 5.24411
2006-12-26 16:50:39.2592 Timer Late > 1.0 : 4.80038
2006-12-26 16:50:39.2770 Timer Late > 1.0 : 2.54650
2006-12-26 16:50:39.2887 Timer Late > 1.0 : 2.54461
2006-12-26 16:50:39.2998 Timer Late > 1.0 : 2.48104
2006-12-26 16:51:34.3389 Request Task > 1.0 : 55.25821 Notify: Slim::Player::Playlist::modifyPlaylistCallback
2006-12-26 17:31:54.5815 Select Task > 1.0 : 1.19545 Slim::Web::HTTP::processHTTP
2006-12-26 17:38:45.8011 Web Page Build > 1.0 : 1.02237 Page: status_header.html
2006-12-26 17:38:45.8068 Select Task > 1.0 : 1.07228 Slim::Web::HTTP::processHTTP
2006-12-26 17:44:27.9259 Web Page Build > 1.0 : 2.10443 Page: setup.html
2006-12-26 17:44:27.9522 Select Task > 1.0 : 2.17352 Slim::Web::HTTP::processHTTP
2006-12-26 17:44:37.2127 Web Page Build > 1.0 : 1.41516 Page: setup.html
2006-12-26 17:44:37.2198 Select Task > 1.0 : 1.47551 Slim::Web::HTTP::processHTTP
2006-12-26 17:47:51.6084 Request Task > 1.0 : 23.56859 Execute: Slim::Control::Commands::playlistXtracksCommand
2006-12-26 17:47:51.6092 Request Task > 1.0 : 23.57848 Execute: Slim::Control::Commands::buttonCommand
2006-12-26 17:47:51.6096 Timer Task > 1.0 : 23.57982 Slim::Hardware::IR::checkRelease
2006-12-26 17:47:51.6110 Response Time > 1.0 : 23.58125
2006-12-26 17:47:51.9097 Timer Late > 1.0 : 23.58194
2006-12-26 17:47:51.9153 Timer Late > 1.0 : 23.50839
2006-12-26 17:47:51.9354 Timer Late > 1.0 : 23.24805
2006-12-26 17:47:51.9406 Timer Late > 1.0 : 22.94052
2006-12-26 17:47:51.9462 Timer Late > 1.0 : 22.94606
2006-12-26 17:47:51.9539 Timer Late > 1.0 : 22.93472
2006-12-26 17:47:51.9594 Timer Late > 1.0 : 22.92087
2006-12-26 17:47:51.9687 Timer Late > 1.0 : 12.37249
2006-12-26 17:47:51.9742 Timer Late > 1.0 : 12.36450
2006-12-26 17:51:12.5731 Request Task > 1.0 : 200.93569 Notify: Slim::Player::Playlist::modifyPlaylistCallback

mswlogo
2006-12-26, 21:26
I started down the NSLU2 path and after spending way too much time getting it up and running I realized I was stupid going down this path. I saw posts of it taking hours to reindex, don't put all your music in one play list, etc. I decided to abort and retired a 3 year old laptop Thinkpad T40p 1.6 Pentium M, 1 Gig Memory.

This actually will use LESS power on standby than the NSLU2. And is also very quiet. The USB drives are powered through USB and the Laptop can go to sleep and will power them down.

The SqueezeBox supports Wake-On-Lan to turn the laptop on. You can pick up a comparable laptop up for $300-$400 used.

Reindex, webserver etc. runs fast. Easy to debug issues.

Been using Softsqueeze, should have SB3 tomorrow. Should drop in and go.

RainmanRam
2006-12-27, 10:34
It would appear wcburnette is experiencing some really long timer late delays. I had a bunch of timer late delays in my performance logs as well.

wcburnette, I'm not quite clear if you ran your tests from a SB or from the web interface. Could you try the same tests on the box running the server using the web interface? If that turns out fast, can you try the web interface from a remote browser? I seem to be experiencing slow downs on external devices (remote browsers and SB's) but not on the server itself using the web interface. Perhaps you're tests will indicate the same and help focus the effort.


Can anyone explain what this message means or point me to documentation on how the timers are being used and their purpose? I do have a programming background so feel free to get technical or point me to some source code. I don't have a good feel for the slimserver code yet, and I'm rusty with perl but can probably slog through it.

If these timers are being used to trigger code execution, is there a way to determine who's timer is late and what the system is doing while delaying the timer event?

Thanks,
Ray

Triode
2006-12-27, 13:06
"Timer Late" means a timer task is firing late. But it is usually a symptom of another task taking a long time which blocks timer tasks being processed. So you really need to look at any log entries before the timer later ones.

So for the log above, the function calls taking a long time are Slim::Player::Playlist::modifyPlaylistCallback and Slim::Control::Commands::playlistXtracksCommand. These relate to the functions which maintain and store the current playlist - which fits as you are manipulating long playlists.

wcburnette
2006-12-28, 00:23
I ran my tests from the SB3. I clicked on a remote to change playlists, and I waited until sound actually came from the speakers.

I ran another set of tests as you requested, using the SlimServer web interface running on a browser on the server machine to change playlists. I wasn't able to save the logs this time, but the results were better, but similar:

2250 -> 80: 4 sec
80->300: 10 sec
300->80: 6 sec
80->300: 13 sec
300->2250: 39 sec
2250->300: 16 sec
200-> 2250: 30 sec
2250->22000: 248 sec

Any other ideas on what the bottleneck is?

Triode
2006-12-28, 04:27
Try turning of playlist persitance. I'm not in front of a server right now, so am not sure what it is actually called on the web interface - perhaps someone else can help here.

The main call taking time Slim::Player::Playlist::modifyPlaylistCallback writes the current playlist to the database every time it changes if playlist persitance is turned on. This seems to take a lot of time for your long playlists on your machine - so what happens if it is turned off?

RainmanRam
2006-12-28, 08:44
I can't find anything related to persisting the playlist, but looking at the data:


There are a few data points that may indicate what I observe in my system -- remote clients can be delayed (some times) but ignoring that issue and trying to work with a small dataset:


Time/removed item:

Web t/items SB t/items
--- ------- -- -------
80->300: 10 .125 16 .200
80->300: 13 .163 15 .186
300->80: 6 .020 7 .023
300->2250: 39 .130 80 .260
300-> 2250: 30 .100 88 .293
2250->80: 4 .002 57 .025
2250->300: 16 .007 16 .007
2250->22000: 248 .110 240 .106

This dataset seems to indicate that the time isn't related to the current playlist size. Looking at it the other way around:

Time/added item:

Web t/items SB t/items
--- ------- -- -------
2250->80: 4 .050 57 .712
300->80: 6 .075 7 .088
80->300: 10 .033 16 .053
80->300: 13 .043 15 .050
2250->300: 16 .053 16 .053
300->2250: 39 .017 80 .036
300->2250: 30 .013 88 .039
2250->22000: 248 .011 240 .011


This shows a relation to the new playlist size but it's not adding items to the list that is consuming the time since as the new list grows, the time/item decreases. Of course there is overhead per/item but the rate of decline in the cost/item as the list grows drops so rapid that I'd look elsewhere for the overhead.

Am I looking at this wrong?

I continue to experience huge delays in remote browsing while browsing directly from the server is instantaneous.

- Ray

Unfortuately My formatting of the tables doesn't appear on this page, it looks like white space is compressed. For some reason the formating appears when I edit the post however.

JJZolx
2006-12-28, 10:23
I can't find anything related to persisting the playlist

Server Settings > Behavior > Maintain Client Playlists

SadGamerGeek
2006-12-28, 10:26
Unfortuately My formatting of the tables doesn't appear on this page, it looks like white space is compressed. For some reason the formating appears when I edit the post however.

For info, you need to put
at the start of the text in question, and then at the end of the text.


Here is that part of your post with the code tags around it:


Web t/items SB t/items
--- ------- -- -------
80->300: 10 .125 16 .200
80->300: 13 .163 15 .186
300->80: 6 .020 7 .023
300->2250: 39 .130 80 .260
300-> 2250: 30 .100 88 .293
2250->80: 4 .002 57 .025
2250->300: 16 .007 16 .007
2250->22000: 248 .110 240 .106

This dataset seems to indicate that the time isn't related to the current playlist size. Looking at it the other way around:

Time/added item:

Web t/items SB t/items
--- ------- -- -------
2250->80: 4 .050 57 .712
300->80: 6 .075 7 .088
80->300: 10 .033 16 .053
80->300: 13 .043 15 .050
2250->300: 16 .053 16 .053
300->2250: 39 .017 80 .036
300->2250: 30 .013 88 .039
2250->22000: 248 .011 240 .011

RainmanRam
2006-12-28, 10:55
Server Settings > Behavior > Maintain Client Playlists

This has zero impact on the slow performance I'm seeing with remote browsing Again, browsing from the machine running slim server is immediate. Browsing from a remote machine is painfully slow. Another datapoint on this is that I'm not seeing log entries for slow reponse times, nor do the server statistics indicate problems. When a page loads, the IE progress bar runs up about 90% immediately and then there is a long pause before the page displays (default skin).

I'd be interested if this setting helps wcburnette however.

snarlydwarf
2006-12-28, 10:59
This has zero impact on the slow performance I'm seeing with remote browsing Again, browsing from the machine running slim server is immediate. Browsing from a remote machine is painfully slow. Another datapoint on this is that I'm not seeing log entries for slow reponse times, nor do the server statistics indicate problems. When a page loads, the IE progress bar runs up about 90% immediately and then there is a long pause before the page displays (default skin).

Hrrm.... is the browser on the remote machine running some weird plugins? Some of the Firefox plugins and such can take quite a while to process sometimes. It sounds like Slimserver is delivering the page in a timely manner but the remote machine is stopping to thing about it for some reason.

I would suspect that or a firewall of some sort.

RainmanRam
2006-12-28, 11:27
snarlydwarf, you nailed it! It wasn't a plugin, it was the content advisor in IE 6 that was causing the slowdown. I have no idea why. Disabling the content advisor made remote browsing of slimserver as fast as it should be.

I don't really understand how the content advisor works so I have no idea if slimserver's pages can be changed to keep the content advisor happy and this should be considered a bug, or if this is just the way it is and should just be noted for future reference for others?

I don't have this problem with any other pages that I can think of so I suspect there is some characteristic of slim's pages that is causing content advisor to stumble.

Thoughts?

snarlydwarf
2006-12-28, 11:41
I don't have this problem with any other pages that I can think of so I suspect there is some characteristic of slim's pages that is causing content advisor to stumble.

Thoughts?

From the little I can glean for MS's support site, it seems that IE6's Content Advisor can ask a "ratings bureau" about each web site you go to. My guess is that whatever ratings bureau is selected is having a cow with your URL's and being slow. Are you navigating by machine name or IP? Is the IP 192.168.1 or .2? It may be that it is trying to resolve the IP or hostname at the "ratings bureau" and timing out.

(Ie, if your network is 192.168.4.0, it may not be smart enough to know that it is a local network and timing out... or if your machine is named 'music' or something it is trying to resolve that instead of being smart and realizing it is not on the 'net.)

MelonMonkey
2006-12-30, 12:18
Why are people still posting to this thread?

Useful information would be a lot easier to find if posts didn't go off-topic and if new threads were started instead of hijacking older threads.