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