PDA

View Full Version : Server architecture / performance



awy
2006-11-29, 23:52
[This is mostly a repost of stuff I posted on the General forum about 6 weeks ago. It was suggested that I repost here.]

I have SlimServer (6.5.1 - about 3 weeks ago) running on my general home server. This is a rather ancient box with a c.600MHz Pemtium II/III(?) CPU and a pair of EIDE drives in a software mirror configuration. Nothing sparkling at all but generally fine for most purposes. It runs Fedora Linux FC5 (up to date).

I notice a couple of performance-related issues. If I use the SlimServer web interface, from another client PC, to browse the music archive, then I get interruptions in the playback. Would it be possible, perhaps, to increase the buffering to (SoftSqueeze) players to overcome this?

When monitoring the system performance with top(1), I often see slimserver.pl using 15-25% of the CPU. I find it hard to correlate this usage with what is going on at the time. What is it doing?

Does the server use multiple threads (other than the separate scanner thread) or does it multiplex various activities (streaming audio, serving web pages) within a single thread?

I think that web-page access seems to be the biggest issue, although there are other occasions where it seems to be chewing the CPU without an obvious good reason.

Actually, is there a good architecture overview of SlimServer? If I could get a handle on how it all works (without ploughing through the code from top to bottom) then I may be in a position to contribute (my field is performance engineering).

Alan.

mherger
2006-11-30, 01:16
> SlimServer web interface, from another client PC, to browse the music
> archive, then I get interruptions in the playback. Would it be

What player?

> possible, perhaps, to increase the buffering to (SoftSqueeze) players
> to overcome this?

Preferences/Audio/Audio buffer size

> When monitoring the system performance with top(1), I often see
> slimserver.pl using 15-25% of the CPU. I find it hard to correlate this
> usage with what is going on at the time. What is it doing?

25%? I don't care... :-) What plugins are you using? Any integration with
systems like iTunes, MusicMagic et al.?

> Does the server use multiple threads (other than the separate scanner
> thread) or does it multiplex various activities (streaming audio,
> serving web pages) within a single thread?

It's rather single threaded.

--

Michael

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

stinkingpig
2006-11-30, 08:51
On 11/29/06, awy <awy.2i2pln1164869701 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
....
> Does the server use multiple threads (other than the separate scanner
> thread) or does it multiplex various activities (streaming audio,
> serving web pages) within a single thread?
>
> I think that web-page access seems to be the biggest issue, although
> there are other occasions where it seems to be chewing the CPU without
> an obvious good reason.
>

Have you enabled webserver forking? Server settings > Performance.

> Actually, is there a good architecture overview of SlimServer? If I
> could get a handle on how it all works (without ploughing through the
> code from top to bottom) then I may be in a position to contribute (my
> field is performance engineering).
>
> Alan.

http://wiki.slimdevices.com/index.cgi?SlimServer and scroll down to
Server Development.

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

Triode
2006-11-30, 13:29
> Does the server use multiple threads (other than the separate scanner
> thread) or does it multiplex various activities (streaming audio,
> serving web pages) within a single thread?

The server is single threaded with the only separate process being the scanner.

> Actually, is there a good architecture overview of SlimServer? If I
> could get a handle on how it all works (without ploughing through the
> code from top to bottom) then I may be in a position to contribute (my
> field is performance engineering).

There is already a reasonable amount of performance monitoring capability built into the server. Have a look at the "Network and
Server Health" web pages.

Have a look at: http://wiki.slimdevices.com/index.cgi?DiagnosingPerformanceIssues and play with the server performance pages. What
is stalling the server for long times?

andyg
2006-11-30, 13:36
On Nov 30, 2006, at 3:29 PM, Triode wrote:

>> Does the server use multiple threads (other than the separate scanner
>> thread) or does it multiplex various activities (streaming audio,
>> serving web pages) within a single thread?
>
> The server is single threaded with the only separate process being
> the scanner.
>
>> Actually, is there a good architecture overview of SlimServer? If I
>> could get a handle on how it all works (without ploughing through the
>> code from top to bottom) then I may be in a position to contribute
>> (my
>> field is performance engineering).
>
> There is already a reasonable amount of performance monitoring
> capability built into the server. Have a look at the "Network and
> Server Health" web pages.
>
> Have a look at: http://wiki.slimdevices.com/index.cgi?
> DiagnosingPerformanceIssues and play with the server performance
> pages. What is stalling the server for long times?

SlimServer performance is very good. As an example, look at
SqueezeNetwork. We currently have 25-30 clients per process, and the
internal latency of each process is generally around 4ms (measured as
average delay in calling a timer). The big problems are synchronous
network operations which for the most part have been eliminated.

Triode
2006-11-30, 14:14
>> Have a look at: http://wiki.slimdevices.com/index.cgi? DiagnosingPerformanceIssues and play with the server performance pages.
>> What is stalling the server for long times?
>
> SlimServer performance is very good. As an example, look at SqueezeNetwork. We currently have 25-30 clients per process, and
> the internal latency of each process is generally around 4ms (measured as average delay in calling a timer). The big problems
> are synchronous network operations which for the most part have been eliminated.

I think it works pretty well too! Web page building is probably the slowest bit other than stalls due to blocking network code. If
people seeing problems can try the diagnoistics and post info on what specifically is taking a long time, then we can probably
improve it.

There's no reason why single threaded shouldn't work well, but there can be cases where we don't yield to streaming fast enough and
it would be good to find any more of these.

andyg
2006-11-30, 14:16
On Nov 30, 2006, at 4:14 PM, Triode wrote:

>>> Have a look at: http://wiki.slimdevices.com/index.cgi?
>>> DiagnosingPerformanceIssues and play with the server performance
>>> pages. What is stalling the server for long times?
>>
>> SlimServer performance is very good. As an example, look at
>> SqueezeNetwork. We currently have 25-30 clients per process, and
>> the internal latency of each process is generally around 4ms
>> (measured as average delay in calling a timer). The big problems
>> are synchronous network operations which for the most part have
>> been eliminated.
>
> I think it works pretty well too! Web page building is probably
> the slowest bit other than stalls due to blocking network code. If
> people seeing problems can try the diagnoistics and post info on
> what specifically is taking a long time, then we can probably
> improve it.
>
> There's no reason why single threaded shouldn't work well, but
> there can be cases where we don't yield to streaming fast enough
> and it would be good to find any more of these.

True, web is a big one, and of course is completely ripped out on
SN. Web forking is a big help.

Paul_B
2006-12-02, 12:54
Web page build is what killed my QNAP TS-101 with 6.5. Average response was over 5 seconds. I now use a VIA EN 15000 MoBo running Windows 2003 R2 with data on the remote QNAP. Performance is more than acceptable. Although web page build is still the weakest link but at an average of 0.5 seconds is acceptable

awy
2006-12-05, 02:37
If
people seeing problems can try the diagnoistics and post info on what specifically is taking a long time, then we can probably
improve it.

There's no reason why single threaded shouldn't work well, but there can be cases where we don't yield to streaming fast enough and
it would be good to find any more of these.

I'll try the diagnostics and report on any findings.