Scut 上線後遇到的問題

1. 上線後的大併發問題：

                var sem = new Semaphore(_accepts, _accepts);

                while (true)
                {
                    sem.WaitOne();

#pragma warning disable 4014
                    _listener.GetContextAsync().ContinueWith(async (t) =>
                    {
                        try
                        {
                            sem.Release();
                            var ctx = await t;
                            await ProcessListenerContext(ctx, this);

                            return;
                        }
                        catch (Exception ex)
                        {
                            TraceLog.WriteError("Http request unknow error:{0}", ex);
                        }
                    });
#pragma warning restore 4014
                }

　　這段消息監聽的代碼在大併發時遇到了重大的問題，不管初始化多少信號量，都會進入等待消息的狀態，只有完整地接受完一條消息，纔會釋放一個信號量出來。所以，特別是在單個協議較大，或者併發訪問量較大的狀況下，服務端很快會陷入大部分信號量被鎖死在等待接收消息的狀況。

　　解決方案則是在「創建鏈接-接收消息」上不作限制，而在消息處理階段進行過濾；

 

2. .NET 嵌入 lua 虛擬機：

　　同事用 Lua 編寫了一個靜態的戰鬥邏輯處理器，可想而知，大量對這個處理器的使用，會致使各類各樣的內存佔用與GC問題。

　　所以對 Lua 虛擬機資源，仍是要進行池化處理，進行資源管理。

 

3. Scut 對接受完整消息、邏輯處理、發送完整消息的超時控制缺失，這樣會由於用戶不穩定的消息傳遞、錯誤的邏輯代碼致使資源被佔用，必定要對各階段進行超時控制，防止資源被超長時間佔用。

 

4. Scut 的協議部分，在常規協議以外還支持追加更多消息，以其規定的分隔符進行分隔，但其採用的是「字符串匹配」的方式查找分隔符，而不是直接在包頭中指定追加消息的起始索引，當常規協議的包身很是大時，字符串匹配會消耗較多的性能。