Start of WebSocket server causes huge CPU load

Jan 23, 2012 at 10:17 AM


I am implementing a simple WebSocket Service using the SuperWebSocket lib using the code below:

wss = new WebSocketServer();
            wss.Setup(new RootConfig(),
                new ServerConfig
                    Port                = 8181,
                    Ip                  = "Any",
                    MaxConnectionNumber = 100,
                    Mode                = SocketMode.Async,
                    Name                = "WSServer"

My problem is, that as soon as I call wss.Start() the programm consumes up to 50% of my available CPU-resources.
At that moment:

- the server should only listen for incoming socket requests.
- No client tries to connect or is connected.
- Even if I call wss.Stop() the CPU load does NOT drop!
- Using .NET 4.0 for my service
- Using the latest build of SuperWebSocket v0.1.0.0 from January 2012

I assume there is:

- an configuration issue on my side
- an error in the socket accept part

Jan 26, 2012 at 1:06 PM

Hi - I've also seen this behaviour.

We are configuring the server to allow 500K connections on a quad-core machine, and the CPU usage jumps from 1% to 30% and maintains that rate whilst NO connection are being made.

We successfully connected 256K connections (no send / receive though - just connection) and during that time the CPU jumped to 60% (expected) and once the connections we established dropped back down to 30% (again expected).

I didn't expected the server to consume 30% whilst idle - that is, without me understanding the processes that are loaded on start of the server.

Any insight into why the CPU consumption is so high while idle would be greatly appreciated.


Jan 27, 2012 at 8:40 AM
Edited Jan 27, 2012 at 8:43 AM

If I were to take a wild guess I would believe you use a two core machine, mdenkmaier, and you, Alex, one with four cores?

(Oh I've just noted you explizitly stated using a quad-core machine.)

I think I've identified an unexpected behavior in WebSocketServer.cs:

It reads:

            if (!int.TryParse(config.Options.GetValue("handshakePendingQueueCheckingInterval"), out m_HandshakePendingQueueCheckingInterval))
                m_HandshakePendingQueueCheckingInterval = 60;// 1 minute default

            if (!int.TryParse(config.Options.GetValue("handshakeTimeOut"), out m_HandshakePendingQueueCheckingInterval))
                m_HandshakeTimeOut = 120;// 2 minute default

If no value for "handshakeTimeOut" is configured, m_HandshakePendingQueueCheckingInterval will be zero.

Later a Timer is created:

m_HandshakePendingQueueCheckingTimer = new Timer(HandshakePendingQueueCheckingCallback, null, m_HandshakePendingQueueCheckingInterval * 1000, m_HandshakePendingQueueCheckingInterval * 1000);

Since 0 * 1000 still is 0, the Timer will fire pretty much as fast as it can.

There is another issue:

In the timer's callback the timer will be disabled temporarily, and then startet again using:

m_HandshakePendingQueueCheckingTimer.Change(m_HandshakePendingQueueCheckingInterval, m_HandshakePendingQueueCheckingInterval);

Since the value of is not multiplied with 1000, the timeout interval specified in seconds will be interpreted as milliseconds, which will cause the event to fire more frequently than expected even if a value for m_HandshakePendingQueueCheckingTimer has explicitly been set.

Edit: Not address Alex by his username; Add comment about "quad-core"

Jan 27, 2012 at 2:46 PM

Ah-ha! The old cut and paste bug!!! Happens to everyone!

I've implemented the change and the CPU has dropped from an average of 30% (Quad-Core) to 0.03 whilst idle on startup - (MaxConnections = 100000)

Thanks for the prompt response guys.

Alex (ChubbyArse)

Jan 28, 2012 at 3:52 AM

Sorry, there might be some critical issue of SuperWebSocket caused by recently changes, I'll fix it ASAP after I come back from vacation.

Jan 28, 2012 at 4:02 AM

Thank you, you save me!

Jan 28, 2012 at 5:51 AM

I have setup new release to fix it!