IT教程: 来，给Entity Framework热热身

本邮件内容由第三方提供，如果您不想继续收到该邮件，可点此退订。

来，给Entity Framework热热身 - dudu 阅读原文»

先来看一下Entity Framework缓慢的初始化速度给我们更新程序带来的一种痛苦。

我们手动更新程序时通常的操作步骤如下：

1）把Web服务器从负载均衡中摘下来

2）更新程序

3）预热（发出一个请求，完成程序的初始化）

4）把完成更新的Web服务器挂上负载均衡

在预热阶段，我们一般是向首页（www.cnblogs.com）发出请求（首页的加载没有用到Entity Framework）。

如果仅这样预热后就将Web服务器上线，将会给部分用户带来糟糕的用户体验——比如，第1位在发布后推荐博文的用户将会等待7秒钟左右（推荐功能中使用了Entity Framework Code First）。

为了避免这样的糟糕体验，我们不得不在预热时发出推荐博文的请求，等EF完成初始化后再发布。这不是一个好的解决方法，因为每个定义的DbContext类型都要进行这个初始化操作。

昨天，我们找到了一个更好的缓解这个问题的方法，在这篇博文中向大家分享一下。

为什么Entity Framework的初始化速度慢如蜗牛呢？

对于在应用程序中定义的每个DbContext类型，在首次使用时，Entity Framework都会根据数据库中的信息在内存生成一个映射视图（mapping views），而这个操作非常耗时。

using (var dbcontext = new CnblogsDbContext())
{
//...
}

比如上面的代码，在第1次调用CnblogsDbContext进行数据库操作时会进行缓慢的mapping views生成操作，后续的CnblogsDbContext操作会共享已经生成的mapping views，不受这个问题影响。但是要注意的是你定义的每一个DbContext都会面临这个问题。

而我们的缓解之道则是在应用程序初始化时一次性触发所有的DbContext进行mapping views的生成操作——调用StorageMappingItemCollection的GenerateViews()方法。

代码如下：

using (var dbcontext = new CnblogsDbContext())
{
var objectContext = ((IObjectContextAdapter)dbcontext).ObjectContext;
var mappingCollection = (StorageMappingItemCollection)objectContext.MetadataWorkspace.GetItemCollection(DataSpace.CSSpace);
mappingCollection.GenerateViews(new List<EdmSchemaError>());
}

//对程序中定义的所有DbContext逐一进行这个操作

对于ASP.NET应用程序，可以将上面的代码放在Application_Start或者PreApplicationStartMethod中执行。

我们采用这个方法之后，在程序更新时只需发一个请求让程序启动起来，比如访问首页（www.cnblogs.com），就可以直接发布。而第1位进行推荐博文操作的用户，等待时间由原来7秒减少到0.5-0.6秒。

【参考资料】

Pre-Generated Mapping Views

本文链接：http://www.cnblogs.com/dudu/p/entity-framework-warm-up.html，转载请注明。

计算机网络纲要 - 潇一 阅读原文»

题记：貌似生命又要进入一个转折点了，所以须努力呀须努力，今天主要写计算机相关的一些读书笔记，写的很泛，希望大家不甚厌烦。

计算机网络模型：

概要：

国际标准组织中把网络体系分为了七层：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。但是在各生产厂家中，实际上一般分为四层，也就是我们常说的TCP/IP模型了：网络接口层，网际层，传输层，应用层。网络接口层就相当偏硬了，接触的会相对来说少一些。

这里先讲两个概念，端到端，点到点分别指的是什么？

端到端一般指的是计算机应用程序到应用程序，可以简单的理解从端口到端口；而点到点就是电脑到电脑了。电脑是硬件，程序是软件。所以在各个层次中，传输层是第一个端到端的，也就是进程到进程。

好了，这里又提到了进程，那么就有必要提线程。其实这两个概念是操作系统中的。

进程是系统分配资源的基本单位，线程是Cpu执行的基本单位，线程拥有一些资源，但是非常非常的少，比如计数器之类的；一个进程可以创建多个线程，各个线程相互协同工作可以更好的提高用户体验，同时提高程序运行速度。具体可以参考相关文章。

传输层是我们进行打交道的层次了。最经典的socket就是此层了。

传输层及TCP UDP

UDP是用户数据报协议，用户和服务器之间无连接，客户可以利用一个数据报发给一个服务器后，立马向另外的服务器发送数据。它不保证数据一定能够传输到，也不保证数据报能够按照一定的先后顺序传输。

TCP是传输控制协议，提供了可靠的传输，因为它是面向连接的。连接的时候会有三次握手，断开连接的时候会有四次挥手，这种确认机制保证了其可靠性，但是同时也注定了它的传输速度要低于UDP。TCP会有以下几种机制：确认服务器或另一端收到才继续发，数据报会排序，流量控制（保证另一端能够接受的过来）。

TCP连接的建立：三次握手

假设A是客户端，B是服务器。

首先A向B发送一个连接请求，B收到请求后确认，并给A发送一个确认信号，A再一次对B确认。这样三次握手就建立了。

那么对于A来说，要发送数据需要做哪些工作呢？

首先建立一个socket也就套接字，里面包括端口号，IP等基本信息，然后connect到B服务器，在send信息或者read信息，最后close.

反之，对于B也要做一系列的工作，才能保证运行的顺利执行。

首先B建立一个socket套接字，然后bind()，然后再不断的监听是否有客户连接进来listen，监听完毕之后就要accept了。只有当accept之后才能进行send，read操作。最后就是close操作。

既然TCP要保证可靠的传输，那么怎么确定数据发送完毕，并且双方都关闭呢？

这里就要讲四次挥手了。

一般来说客户端A主动向B发送一个关闭请求，B收到后进行确认，确认完毕后对A回复一个确认信号，(注意此时的A要进入一段等待时间要保证之前的信息B都能收到呀)，过了一段时间之后，B向A报告收到的最后一个数据报的序列号N，A收到后，比照之前发送的数据报，如果的确是N。那么A再向B发送确认信号。这样，关闭就完成了。