码迷,mamicode.com
首页 > 其他好文 > 详细

Scut 上线后遇到的问题

时间:2016-12-27 23:21:18      阅读:147      评论:0      收藏:0      [点我收藏+]

标签:lua   etc   res   ble   访问   class   continue   request   占用   

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 上线后遇到的问题

标签:lua   etc   res   ble   访问   class   continue   request   占用   

原文地址:http://www.cnblogs.com/Daniel-Liang/p/6227638.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!