小编DJA*_*DJA的帖子

我受到了视频" 使用ASP.NET SignalR扩展实时Web "的启发,时间为56分11秒.

想象一下使用SignalR与服务器通信的基于Web的聊天客户端.客户端连接时,其端点信息存储在Azure表中.

聊天客户端可以通过SignalR向另一个聊天客户端发送消息,SignalR查找感兴趣的目标客户端的终点(可能在不同的实例上),然后使用Web API通过SignalR将消息发送到客户端的另一个实例.

为了演示我已经将示例应用程序上传到github.

当存在单个Azure实例时,这一切都有效.但是,如果存在MULTIPLE azure实例,则从服务器到客户端的SignalR的最终调用将无效.它就像动态代码不存在或者它从"坏"线程中消失或消息以某种方式被发送到错误的实例或者我刚刚犯了一个蠢的错误.

任何想法将不胜感激.

网页设置为此

<input type="radio" name='ClientId' value='A' style='width:30px'/>Chat client A</br>
<input type="radio" name='ClientId' value='B' style='width:30px'/>Chat client B</br>
<input type='button' id='register' value='Register' />
<input type='text' id='txtMessage' size='50' /><input type='button' id='send' value='Send' />

<div id='history'>
</div>

和JS是

<script type="text/javascript">
    $(function () {

        // Declare a proxy to reference the hub. 
        var chat = $.connection.chatHub;

        chat.client.sendMessageToClient = function (message) {
            $('#history').append("<br/>" + message);
        };


        // Start the connection.
        $.connection.hub.start().done(function () …

Winforms程序需要将一些运行时信息保存到XML文件中.该文件有时可能是几百千字节.在beta测试期间,我们发现一些用户会毫不犹豫地随机终止进程并偶尔导致文件被写入一半并因此被破坏.

因此,我们将算法更改为保存到临时文件,然后删除实际文件并执行移动.

我们的代码目前看起来像..

private void Save()
{
    XmlTextWriter streamWriter = null;
    try
    {
        streamWriter = new XmlTextWriter(xmlTempFilePath, System.Text.Encoding.UTF8);

        XmlSerializer xmlSerializer = new XmlSerializer(typeof(MyCollection));

        xmlSerializer.Serialize(streamWriter, myCollection);

        if (streamWriter != null)
            streamWriter.Close();

        // Delete the original file
        System.IO.File.Delete(xmlFilePath);

        // Do a move over the top of the original file 
        System.IO.File.Move(xmlTempFilePath, xmlFilePath);
    }
    catch (System.Exception ex)
    {
        throw new InvalidOperationException("Could not save the xml file.", ex);
    }
    finally
    {
        if (streamWriter != null)
            streamWriter.Close();
    }
}

这几乎在所有时间都在实验室和生产中使用.该程序在12台计算机上运行,​​平均每5分钟调用一次该代码.每天大约一两次我们得到这个例外:

System.InvalidOperationException: 
Could not save the xml …

我刚开始写线...

if (!e.PeriodicData.Keys.Contains(process))
{
}

但在"!"上做了一个错字 然后点击"@".例如

if (@e.PeriodicData.Keys.Contains(process))
{
}

我期待intellisense翻转,但事实并非如此.所以我编译并成功编译.

它不是运营商,那么什么是"@"？它有什么作用？

我们有一个存储过程,它返回属于地理空间区域("地理位置")的所有记录.它使用CTE(带),一些联合,一些内连接并将数据作为XML返回; 没有争议或前沿,但也不是微不足道的.

这个存储过程在SQL Server 2008上已经很好地服务了很多年.它在相对较慢的服务器上运行1秒钟.我们刚刚在具有大量内存和超快速SDD的超高速服务器上迁移到SQL Server 2016.

整个数据库和相关应用程序在这台新服务器上运行得非常快,我们对它非常满意.但是,这一个存储过程在16秒而不是1秒内运行 - 完全相同的参数和完全相同的数据集.

我们更新了此数据库的索引和统计信息.我们还将数据库的兼容级别从100更改为130.

有意思的是,我重写了存储过程以使用临时表和"插入"而不是使用CTE.这使得时间从16秒降低到4秒.

执行计划没有提供任何关于瓶颈可能存在的明显见解.

我们有点卡住了想法.接下来我们该怎么办？提前致谢.

-

我现在花在这个问题上的时间比我承认的要多.我已将存储过程归结为以下查询以演示此问题.

drop table #T 

declare @viewport sys.geography=convert(sys.geography,0xE610000001041700000000CE08C22D7740C002370B7670F4624000CE08C22D7740C002378B5976F4624000CE08C22D7740C003370B3D7CF4624000CE08C22D7740C003378B2082F4624000CE08C22D7740C003370B0488F4624000CE08C22D7740C004378BE78DF4624000CE08C22D7740C004370BCB93F4624000CE08C22D7740C004378BAE99F4624000CE08C22D7740C005370B929FF4624000CE08C22D7740C005378B75A5F4624000CE08C22D7740C005370B59ABF462406F22B7698E7640C005370B59ABF462406F22B7698E7640C005378B75A5F462406F22B7698E7640C005370B929FF462406F22B7698E7640C004378BAE99F462406F22B7698E7640C004370BCB93F462406F22B7698E7640C004378BE78DF462406F22B7698E7640C003370B0488F462406F22B7698E7640C003378B2082F462406F22B7698E7640C003370B3D7CF462406F22B7698E7640C002378B5976F462406F22B7698E7640C002370B7670F4624000CE08C22D7740C002370B7670F4624001000000020000000001000000FFFFFFFF0000000003)

declare @outputControlParameter nvarchar(max) = 'a value passed in through a parameter to the stored that controls the nature of data to return. This is not the solution you are looking for'

create table #T
    (value int)

insert into #T 
select 136561 union 
select 16482 -- These values are sourced from parameters into the stored proc

select …