小编Pit*_*DBA的帖子

我们的前端MVC3 Web应用程序正在使用AsyncController,因为我们的每个实例都在为数百个长时间运行的IO绑定进程提供服务.

由于Azure会在一些预先确定的时间间隔后终止"非活动"http会话(这似乎取决于您阅读的网站),我们如何保持连接活动？

我们的客户必须保持联系,我们的流程将持续30秒到5分钟或更长时间.我们如何保持客户端连接/活动？我最初想过在Async方法上有一个超时,只是用几个字节的输出来命中Response对象,有点像分块响应,然后再返回等待一些.但是,我不认为这会起作用,因为MVC3正在处理IIS线程与异步响应的连接,异步响应在那时已经呈现了一个视图.

我们如何在AsyncController上运行一个非常长的进程,但是Azure负载均衡器不能断开客户端的连接？向呼叫者发送立即响应,并要求呼叫者轮询或检查其他资源URL是不可接受的.

我需要在发布服务器和订阅服务器之间建立双向通信.这是为了方便前端MVC3应用程序使用关联过滤器定义订阅,然后将消息放到主题上.最后,MVC3控制器调用SubscriptionClient上的BeginReceive(),并等待响应.

问题似乎是创建和删除这些Subscription对象.开销很大,并且会使应用程序变慢.这并不是说要解决的各种限制,例如主题上的订阅数量不超过2000个.

在发布者和订阅者之间建立这种双向通信的最佳实践是什么？我们希望MVC3应用程序发布消息,然后等待对该确切消息的响应(通过CorrelationId属性和CorrelationFilter).我们已经缓存了NamespaceManager和MessagingFactory,因为它们在资源方面也非常昂贵,并且还因为我们被告知Service Bus使用显式配置模型,我们需要在角色启动期间预先创建大部分这些内容.

因此,这给我们带来了将请求与响应相关联的挑战,以及创建和删除订阅的巨大开销.还有什么更好的做法？我们应该保留SubscriptionClient的缓存,并每次交换过滤器吗？其他人都做了什么？我需要通过Web角色群集获得每秒5到10,000个MVC3请求的请求吞吐量.我们已经在使用AsyncController并在SubscriptionClient上使用异步BeginReceive().它似乎是数以千计的订阅的创建和删除,此时系统正在窒息.

UPDATE1: 根据此处提供的好建议,我们更新了此解决方案,以便在每个Web角色实例上保留SubscriptionClient对象的缓存.此外,我们已迁移到面向MessageSession的方法.

但是,这仍然没有缩放.似乎AcceptMessageSession()是一个非常昂贵的操作.MessageSession对象是否也应该被缓存并重新使用？每个打开的MessageSession对象是否都使用与服务总线的连接？如果是这样,这是否与订阅的并发连接配额相对应？

非常感谢.我想我们到了那里.Web上的大多数示例代码显示:在客户端上创建Topic(),然后是CreateSubscription(),然后是CreateSubscriptionClient(),然后是BeginReceive(),然后拆除所有对象.我只能说,如果你在现实生活中这样做,你的服务器就会被粉碎,你最快就能连接起来了.

我们需要通过这个东西每秒发出数千个请求,很明显这些对象必须被高速缓存和重用.那么,MessageSession还有另一个要缓存的项目吗？我将获得有趣的缓存,因为我们必须实现一个引用计数机制,其中一次只能给出一个对MessageSession的引用,因为这是针对http请求特定的请求/响应,我们不能有其他订阅者同时使用MessageSession对象.

UPDATE2: 好的,将MessageSession缓存以供重用是不可行的,因为它们只与订阅时的LockDuration一样长.这是一个无赖,因为最大LockDuration是5分钟.这些似乎是短期的pub/sub,而不是长期运行的分布式进程.看起来我们需要回到轮询Azure表.

摘要/评论 我们试图建立Service Bus,因为它具有规模潜力及其持久性和交付语义.但是,似乎有些情况下,它们之间的大量请求/响应不适合它.发布部分工作得很好,并且在后端拥有竞争的消费者是很好的,但是有一个前端请求等待定义的单一消费者响应,根本不能很好地扩展,因为MessageSessions需要太长时间才能完成通过AcceptMessageSession()或BeginAcceptMessageSession()创建,因为它们不适合缓存.

如果有人有另一种观点,我很乐意听到.

我们已经实施了Google OAuth2,它在ASPNetUsers表中创建了用户.这工作正常,我们可以通过User.Identity.GetUserName()查看经过身份验证的用户.

如果我们通过AspNetRoles和AspNetUserRoles表将此用户添加到角色,例如"MyCustomRole",则使用以下方法保护的任何方法:

[Authorize(Roles="MyCustomRole")]

无法访问.应用程序将经过身份验证的用户转发到Login控制器.

将这些经过外部验证的用户添加到角色的正确机制是什么,哪些角色可以访问[Authorize(Roles ="")]属性？

如果开发人员在自己的计算机上使用RSAProtectedConfigurationProvider加密连接字符串app.config部分,并随后将其部署到用户的工作站,那么该用户的工作站(或服务器)是否可以自动解密连接字符串？

是否需要某种关键的出口/安装？这是如何运作的？我意识到它不是防弹的.我正在寻找关于部署是否容易和/或使用这种加密连接字符串的建议.

我有一个MDI应用程序.当我使用MessageBox.Show()显示一个消息框时,当我关闭消息框时,整个应用程序在我打开的所有窗口后面消失.

代码没有做任何特别的事情.实际上,这是从MDI子窗体中调用消息框的行:

MessageBox.Show(String.Format("{0} saved successfully.", Me.BusinessUnitTypeName), "Save Successful", MessageBoxButtons.OK, MessageBoxIcon.Information, MessageBoxDefaultButton.Button1, MessageBoxOptions.DefaultDesktopOnly)

Me.BusinessUnitTypeName()是一个只读属性getter,它返回一个字符串,具体取决于成员变量的值.这家酒店没有副作用.

有任何想法吗？

正如标题所暗示的那样,Azure云中我们的MVC3应用程序的第一个"冷"POST非常慢.一旦它"旋转",正常的请求就会快速发展.短暂休息后的第一次旋转需要几秒钟.后续请求可以以毫秒为单位进行测量.

我们怎样才能让这件事保持清醒？

我们的项目使用Entity Framework Code First.我们希望有一个实例,其中一个非常简单的POCO表示数据库中的许多表.它是SQL Azure中水平分区策略的一部分.SQL Azure不支持文件组,因此它不支持典型的分区.将会有非常多的表,因此使用UNION ALL视图作为基表上的CHECK CONSTRAINTs的分区视图是不可行的.

因此,我们更愿意在运行时根据需要执行映射.但是,这发生在DbContext类的OnModelCreating事件中,例如

modelBuilder.Entity<EntityName>().ToTable("foo", "bar");

.我们可以在工厂内执行此映射吗？我们更愿意向工厂提供元数据,然后让它使用Fluent API,而不是通过ModelBuilder在POCO和表之间进行一对一的映射.

当Azure平台决定关闭我的一个Web角色实例时,它是如何完成的？

例如,它是否停止发送新请求,但允许现有请求完成？我无法想象它只会终止日常维护的活动连接.这将是极具破坏性和代价高昂的.

任何洞察这个小黑盒子都会很棒,特别是如果你知道MSDN或Azure CAT链接.

我们的REST API之一将导致执行长时间运行的进程.我们宁愿立即回复,而不是让客户等待很长时间.

因此,让我们考虑一下这个用例:申请人提交申请,最终会有结果.由于这是一个非常高规模的平台,我们不能将应用程序持久存储,而是必须将其放入队列进行处理.

在这种情况下,返回应用程序最终存在的URI是否可以接受,例如http://example.com/application/abc123？

同样,作为应用程序资源表示的一部分,返回结果文档的URI(表示有关应用程序的决策)是否可以接受？结果文档将在几分钟内不会创建,并且对其URI(或应用程序的URI)的HTTP GET将导致404,直到它们被持久化.

在这种情况下,最佳做法是什么？为资源分发"未来"URI是否可以接受？

我需要在Windows Azure中查询2亿个实体的商店.理想情况下,我想使用Table Service而不是SQL Azure来完成此任务.

用例是这样的:包含新实体的POST将从面向Web的API传入.我们必须查询大约2亿个实体,以确定我们是否可以接受新实体.

实体限制为1,000:这是否适用于此类查询,即我必须一次查询1,000个并执行我的比较/业务规则,或者我可以一次查询所有2亿个实体？我认为在后一种情况下我会超时.

想法？

Azure文档说,Web角色上的内部端点不会进行负载平衡.这有什么实际影响？

示例:我有一个包含20个实例的Web角色.如果我为该Web角色定义内部端点,那么内部实现是什么？例如,所有20个实例是否仍然可以为此终点服务？我可以为每个实例获取特定的端点吗？

我们有一个独特的回调要求,可以通过利用公共端点上的正常负载平衡行为很好地服务,但让每个实例都公开一个内部端点.根据公布的端点限制数量,这是不可能的.那么,在定义内部端点时,它是"每个实例1个",还是什么？是否所有角色实例都为端点提供服务？微软在说内部端点没有负载均衡时意味着什么？是否所有流量都流向一个实例？那没有意义.