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 的协议部分，在常规协议之外还支持追加更多消息，以其规定的分隔符进行分隔，但其采用的是“字符串匹配”的方式查找分隔符，而不是直接在包头中指定追加消息的起始索引，当常规协议的包身非常大时，字符串匹配会消耗较多的性能。