首页 > 代码库 > Scut 上线后遇到的问题

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

 

Scut 上线后遇到的问题