存档

2008年8月 的存档

今天网站备案终于下来了

2008年8月29日 admin 没有评论

今天网站备案终于下来了，很高兴 ^_^

哎，整个备案用了53天，或许是奥运放假的原因，但今天还是蛮高兴的。

Popularity: 13% [?]

分类: 杂谈 标签:

ASP.NET 26个常用性能优化方法

2008年8月22日 admin 没有评论
  1. 数据库访问性能优化
    数据库的连接和关闭
    访问数据库资源需要创建连接、打开连接和关闭连接几个操作。这些过程需要多次与数据库交换信息以通过身份验证，比较耗费服务器资源。 ASP.NET中提供了连接池(Connection Pool)改善打开和关闭数据库对性能的影响。系统将用户的数据库连接放在连接池中，需要时取出，关闭时收回连接，等待下一次的连接请求。连接池的大小是 有限的，如果在连接池达到最大限度后仍要求创建连接，必然大大影响性能。因此，在建立数据库连接后只有在真正需要操作时才打开连接，使用完毕后马上关闭， 从而尽量减少数据库连接打开的时间，避免出现超出连接限制的情况。
    使用存储过程
     存储过程是存储在服务器上的一组预编译的SQL语句，类似于DOS系统中的批处理文件。存储过程具有对数据库立即访问的功能，信息处理极为迅速。使用存 储过程可以避免对命令的多次编译，在执行一次后其执行规划就驻留在高速缓存中，以后需要时只需直接调用缓存中的二进制代码即可。另外，存储过程在服务器端 运行，独立于ASP.NET程序，便于修改，最重要的是它可以减少数据库操作语句在网络中的传输。
    优化查询语句
     ASP.NET中ADO连接消耗的资源相当大，SQL语句运行的时间越长，占用系统资源的时间也越长。因此，尽量使用优化过的SQL语句以减少执行时间。比如，不在查询语句中包含子查询语句，充分利用索引等。
  2. 字符串操作性能优化
    使用值类型的ToString方法
    在连接字符串时，经常使用”+”号直接将数字添加到字符串中。这种方法虽然简单，也可以得到正确结果，但是由于涉及到不同的数据类型，数字需要通过装 箱操作转化为引用类型才可以添加到字符串中。但是装箱操作对性能影响较大，因为在进行这类处理时，将在托管堆中分配一个新的对象，原有的值复制到新创建的 对象中。使用值类型的ToString方法可以避免装箱操作，从而提高应用程序性能。
    运用StringBuilder类
    String类对象是不可改变的，对于String对象的重新赋值在本质上是重新创建了一个String对象并将新值赋予该对象，其方法 ToString对性能的提高并非很显著。在处理字符串时，最好使用StringBuilder类，其.NET 命名空间是System.Text。该类并非创建新的对象，而是通过Append，Remove，Insert等方法直接对字符串进行操作，通过 ToString方法返回操作结果。 　　其定义及操作语句如下所示：

    int num;
    System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串
    str.Append(num.ToString()); //添加数值num
    Response.Write(str.ToString); //显示操作结果
  3. 优化 Web 服务器计算机和特定应用程序的配置文件以符合您的特定需要
    默认情况下，ASP.NET 配置被设置成启用最广泛的功能并尽量适应最常见的方案。因此，应用程序开发人员可以根据应用程序所使用的功能，优化和更改其中的某些配置，以提高应用程序的性能。下面的列表是您应该考虑的一些选项。
    仅对需要的应用程序启用身份验证。
    默认情况下，身份验证模式为 Windows，或集成 NTLM。大多数情况下，对于需要身份验证的应用程序，最好在 Machine.config 文件中禁用身份验证，并在 Web.config 文件中启用身份验证。根据适当的请求和响应编码设置来配置应用程序。ASP.NET 默认编码格式为 UTF-8。如果您的应用程序为严格的 ASCII，请配置应用程序使用 ASCII 以获得稍许的性能提高。
    考虑对应用程序禁用 AutoEventWireup。
    在 Machine.config 文件中将 AutoEventWireup 属性设置为 false，意味着页面不将方法名与事件进行匹配和将两者挂钩(例如 Page_Load)。如果页面开发人员要使用这些事件，需要在基类中重写这些方法(例如，需要为页面加载事件重写 Page.OnLoad，而不是使用 Page_Load 方法)。如果禁用 AutoEventWireup，页面将通过将事件连接留给页面作者而不是自动执行它，获得稍许的性能提升。
    从请求处理管线中移除不用的模块。
    默认情况下，服务器计算机的 Machine.config 文件中节点的所有功能均保留为激活。根据应用程序所使用的功能，您可以从请求管线中移除不用的模块以获得稍许的性能提升。检查每个模块及其功能，并按您的 需要自定义它。例如，如果您在应用程序中不使用会话状态和输出缓存，则可以从列表中移除它们，以便请求在不执行其他有意义的处理时，不必执行每个模块的进 入和离开代码。
  4. 一定要禁用调试模式
    在部署生产应用程序或进行任何性能测量之前，始终记住禁用调试模式。如果启用了调试模式，应用程序的性能可能受到非常大的影响。
  5. 对于广泛依赖外部资源的应用程序，请考虑在多处理器计算机上启用网络园艺
    ASP.NET 进程模型帮助启用多处理器计算机上的可缩放性，将工作分发给多个进程(每个CPU一个)，并且每个进程都将处理器关系设置为其 CPU。此技术称为网络园艺。如果应用程序使用较慢的数据库服务器或调用具有外部依赖项的 COM 对象(这里只是提及两种可能性)，则为您的应用程序启用网络园艺是有益的。但是，在决定启用网络园艺之前，您应该测试应用程序在网络园中的执行情况。
  6. 只要可能，就缓存数据和页输出
    ASP.NET 提供了一些简单的机制，它们会在不需要为每个页请求动态计算页输出或数据时缓存这些页输出或数据。另外，通过设计要进行缓存的页和数据请求(特别是在站点 中预期将有较大通讯量的区域)，可以优化这些页的性能。与 .NET Framework 的任何 Web 窗体功能相比，适当地使用缓存可以更好的提高站点的性能，有时这种提高是超数量级的。使用 ASP.NET 缓存机制有两点需要注意。首先，不要缓存太多项。缓存每个项均有开销，特别是在内存使用方面。不要缓存容易重新计算和很少使用的项。其次，给缓存的项分配 的有效期不要太短。很快到期的项会导致缓存中不必要的周转，并且经常导致更多的代码清除和垃圾回收工作。若关心此问题，请监视与 ASP.NET Applications 性能对象关联的 Cache Total Turnover Rate 性能计数器。高周转率可能说明存在问题，特别是当项在到期前被移除时。这也称作内存压力。
  7. 选择适合页面或应用程序的数据查看机制
    根据您选择在 Web 窗体页显示数据的方式，在便利和性能之间常常存在着重要的权衡。例如，DataGrid Web 服务器控件可能是一种显示数据的方便快捷的方法，但就性能而言它的开销常常是最大的。在某些简单的情况下，您通过生成适当的 HTML 自己呈现数据可能很有效，但是自定义和浏览器定向会很快抵销所获得的额外功效。Repeater Web 服务器控件是便利和性能的折衷。它高效、可自定义且可编程。
  8. 将 SqlDataReader 类用于快速只进数据游标
    SqlDataReader 类提供了一种读取从 SQL Server 数据库检索的只进数据流的方法。如果当创建 ASP.NET 应用程序时出现允许您使用它的情况，则 SqlDataReader 类提供比 DataSet 类更高的性能。情况之所以这样，是因为 SqlDataReader 使用 SQL Server 的本机网络数据传输格式从数据库连接直接读取数据。另外，SqlDataReader 类实现 IEnumerable 接口，该接口也允许您将数据绑定到服务器控件。有关更多信息，请参见 SqlDataReader 类。有关 ASP.NET 如何访问数据的信息，请参见通过 ASP.NET 访问数据。
  9. 将 SQL Server 存储过程用于数据访问
    在 .NET Framework 提供的所有数据访问方法中，基于 SQL Server 的数据访问是生成高性能、可缩放 Web 应用程序的推荐选择。使用托管 SQL Server 提供程序时，可通过使用编译的存储过程而不是特殊查询获得额外的性能提高。
  10. 避免单线程单元 (STA) COM 组件
    默认情况下，ASP.NET 不允许任何 STA COM 组件在页面内运行。若要运行它们，必须在 .aspx 文件内将 ASPCompat=true 属性包含在 @ Page 指令中。这样就将执行用的线程池切换到 STA 线程池，而且使 HttpContext 和其他内置对象可用于 COM 对象。前者也是一种性能优化，因为它避免了将多线程单元 (MTA) 封送到 STA 线程的任何调用。使用 STA COM 组件可能大大损害性能，应尽量避免。若必须使用 STA COM 组件，如在任何 interop 方案中，则应在执行期间进行大量调用并在每次调用期间发送尽可能多的信息。另外，小心不要在构造页面期间创建任何 STA COM 组件。例如下面的代码中，在页面构造时将实例化由某个线程创建的 MySTAComponent，而该线程并不是将运行页面的 STA 线程。这可能对性能有不利影响，因为要构造页面就必须完成 MTA 和 STA 线程之间的封送处理。

    <%@ Page Language=”VB” ASPCompat=”true” %>
    <script runat=server>
    Dim myComp as new MySTAComponent()
    Public Sub Page_Load()
    myComp.Name = “Bob”
    End Sub
    </script>
    <html>
    <%
    Response.Write(myComp.SayHello)
    %>
    </html>

    首选机制是推迟对象的创建，直到以后在 STA 线程下执行上述代码，如下面的例子所示。

    <%@ Page Language=”VB” ASPCompat=”true” %>
    <script runat=server>
    Dim myComp
    Public Sub Page_Load()
    myComp = new MySTAComponent()
    myComp.Name = “Bob”
    End Sub
    </script>
    <html>
    <%
    Response.Write(myComp.SayHello)
    %>
    </html>

    推荐的做法是在需要时或者在 Page_Load 方法中构造任何 COM 组件和外部资源。永远不要将任何 STA COM 组件存储在可以由构造它的线程以外的其他线程访问的共享资源里。这类资源包括像缓存和会话状态这样的资源。即使 STA 线程调用 STA COM 组件，也只有构造此 STA COM 组件的线程能够实际为该调用服务，而这要求封送处理对创建者线程的调用。此封送处理可能产生重大的性能损失和可伸缩性问题。在这种情况下，请研究一下使 COM 组件成为 MTA COM 组件的可能性，或者更好的办法是迁移代码以使对象成为托管对象。

  11. 将调用密集型的 COM 组件迁移到托管代码
    .NET Framework 提供了一个简单的方法与传统的 COM 组件进行交互。其优点是可以在保留现有投资的同时利用新的平台。但是在某些情况下，保留旧组件的性能开销使得将组件迁移到托管代码是值得的。每一情况都是 不一样的，决定是否需要迁移组件的最好方法是对 Web 站点运行性能测量。建议您研究一下如何将需要大量调用以进行交互的任何COM 组件迁移到托管代码。许多情况下不可能将旧式组件迁移到托管代码，特别是在最初迁移 Web 应用程序时。在这种情况下，最大的性能障碍之一是将数据从非托管环境封送到托管环境。因此，在交互操作中，请在任何一端执行尽可能多的任务，然后进行一个 大调用而不是一系列小调用。例如，公共语言运行库中的所有字符串都是 Unicode 的，所以应在调用托管代码之前将组件中的所有字符串转换成 Unicode 格式。另外，一处理完任何 COM 对象或本机资源就释放它们。这样，其他请求就能够使用它们，并且最大限度地减少了因稍后请求垃圾回收器释放它们所引起的性能问题。
  12. 在 Visual Basic .NET 或 JScript. 代码中使用早期绑定
     以往，开发人员喜欢使用 Visual Basic、VBScript. 和 JScript. 的原因之一就是它们所谓“无类型”的性质。变量不需要显式类型声明，并能够简单地通过使用来创建它们。当从一个类型到另一个类型进行分配时，转换将自动执 行。不过，这种便利会大大损害应用程序的性能。Visual Basic 现在通过使用 Option Strict 编译器指令来支持类型安全编程。为了向后兼容，默认情况下，ASP.NET 不启用该选项。但是，为了得到最佳性能，强烈建议在页中启用该选项。若要启用 Option Strict，请将 Strict 属性包括在 @ Page 指令中，或者，对于用户控件，请将该属性包括在 @ Control 指令中。下面的示例演示了如何设置该属性，并进行了四个变量调用以显示使用该属性是如何导致编译器错误的。

    <%@ Page Language=”VB” Strict=”true” %>
    <%
    Dim B
    Dim C As String
    ‘ This will cause a compiler error.
    A = “Hello”
    ‘ This will cause a compiler error.
    B = “World”
    ‘ This will not cause a compiler error.
    C = “!!!!!!”
    ‘ But this will cause a compiler error.
    C = 0
    %>　　Dim B
    Dim C As String
    ‘ This will cause a compiler error.
    A = “Hello”
    ‘ This will cause a compiler error.
    B = “World”
    ‘ This will not cause a compiler error.
    C = “!!!!!!”
    ‘ But this will cause a compiler error.
    C = 0
    %>

    JScript.NET 也支持无类型编程，但它不提供强制早期绑定的编译器指令。若发生下面任何一种情况，则变量是晚期绑定的：被显式声明为 Object，是无类型声明的类的字段，是无显式类型声明的专用函数或方法成员，并且无法从其使用推断出类型。 　　最后一个差别比较复杂，因为如果 JScript. .NET 编译器可以根据变量的使用情况推断出类型，它就会进行优化。在下面的示例中，变量 A 是早期绑定的，但变量 B 是晚期绑定的。

    var A;
    var B;
    A = “Hello”;
    B = “World”;
    B = 0;

    为了获得最佳的性能，当声明 JScript. .NET 变量时，请为其分配一个类型。例如，var A : String。

  13. 使请求管线内的所有模块尽可能高效
     请求管线内的所有模块在每次请求中都有机会被运行。因此，当请求进入和离开模块时快速地触发代码至关重要，特别是在不使用模块功能的代码路径里。分别在使用及不使用模块和配置文件时执行吞吐量测试，对确定这些方法的执行速度非常有用。
  14. 使用 HttpServerUtility.Transfer 方法在同一应用程序的页面间重定向
    采用 Server.Transfer 语法，在页面中使用该方法可避免不必要的客户端重定向。
  15. 必要时调整应用程序每个辅助进程的线程数
    ASP.NET 的请求结构试图在执行请求的线程数和可用资源之间达到一种平衡。已知一个使用足够 CPU 功率的应用程序，该结构将根据可用于请求的 CPU 功率，来决定允许同时执行的请求数。这项技术称作线程门控。但是在某些条件下，线程门控算法不是很有效。通过使用与 ASP.NET Applications 性能对象关联的 Pipeline Instance Count 性能计数器，可以在 PerfMon 中监视线程门控。当页面调用外部资源，如数据库访问或 XML Web services 请求时，页面请求通常停止并释放 CPU。如果某个请求正在等待被处理，并且线程池中有一个线程是自由的，那么这个正在等待的请求将开始被处理。遗憾的是，有时这可能导致 Web 服务器上存在大量同时处理的请求和许多正在等待的线程，而它们对服务器性能有不利影响。通常，如果门控因子是外部资源的响应时间，则让过多请求等待资源， 对 Web 服务器的吞吐量并无帮助。为缓和这种情况，可以通过更改 Machine.config 配置文件节点的 maxWorkerThreads 和 maxIOThreads 属性，手动设置进程中的线程数限制。
    注意：辅助线程是用来处理 ASP.NET 请求的，而 IO 线程则是用于为来自文件、数据库或 XML Web services 的数据提供服务的。分配给这些属性的值是进程中每个 CPU 每类线程的最大数目。对于双处理器计算机，最大数是设置值的两倍。对于四处理器计算机，最大值是设置值的四倍。无论如何，对于有四个或八个 CPU 的计算机，最好更改默认值。对于有一个或两个处理器的计算机，默认值就可以，但对于有更多处理器的计算机的性能，进程中有一百或两百个线程则弊大于利。注 意进程中有太多线程往往会降低服务器的速度，因为额外的上下文交换导致操作系统将 CPU 周期花在维护线程而不是处理请求上。
  16. 适当地使用公共语言运行库的垃圾回收器和自动内存管理
    小心不要给每个请求分配过多内存，因为这样垃圾回收器将必须更频繁地进行更多的工作。另外，不要让不必要的指针指向对象，因为它们将使对象保持活动状 态，并且应尽量避免含 Finalize 方法的对象，因为它们在后面会导致更多的工作。特别是在 Finalize 调用中永远不要释放资源，因为资源在被垃圾回收器回收之前可能一直消耗着内存。最后这个问题经常会对 Web 服务器环境的性能造成毁灭性的打击，因为在等待 Finalize 运行时，很容易耗尽某个特定的资源。
  17. 如果有大型 Web 应用程序，可考虑执行预批编译
    每当发生对目录的第一次请求时都会执行批编译。如果目录中的页面没有被分析并编译，此功能会成批分析并编译目录中的所有页面，以便更好地利用磁盘和内 存。如果这需要很长时间，则将快速分析并编译单个页面，以便请求能被处理。此功能带给 ASP.NET 性能上的好处，因为它将许多页面编译为单个程序集。从已加载的程序集访问一页比每页加载新的程序集要快。批编译的缺点在于：如果服务器接收到许多对尚未编 译的页面的请求，那么当 Web 服务器分析并编译它们时，性能可能较差。为解决这个问题，可以执行预批编译。为此，只需在应用程序激活之前向它请求一个页面，无论哪页均可。然后，当用户 首次访问您的站点时，页面及其程序集将已被编译。没有简单的机制可以知道批编译何时发生。需一直等到 CPU 空闲或者没有更多的编译器进程(例如 csc.exe(C# 编译器)或 vbc.exe(Visual Basic 编译器))启动。还应尽量避免更改应用程序的 bin 目录中的程序集。更改页面会导致重新分析和编译该页，而替换 bin 目录中的程序集则会导致完全重新批编译该目录。在包含许多页面的大规模站点上，更好的办法可能是根据计划替换页面或程序集的频繁程度来设计不同的目录结 构。不常更改的页面可以存储在同一目录中并在特定的时间进行预批编译。经常更改的页面应在它们自己的目录中(每个目录最多几百页)以便快速编译。Web 应用程序可以包含许多子目录。批编译发生在目录级，而不是应用程序级。
  18. 不要依赖代码中的异常
    因为异常大大地降低性能，所以您不应该将它们用作控制正常程序流程的方式。如果有可能检测到代码中可能导致异常的状态，请执行这种操作。不要在处理该 状态之前捕获异常本身。常见的方案包括：检查 null，分配给将分析为数字值的 String 一个值，或在应用数学运算前检查特定值。下面的示例演示可能导致异常的代码以及测试是否存在某种状态的代码。两者产生相同的结果。

    try
    {
    result = 100 / num;
    }
    catch (Exception e)
    {
    result = 0;
    }
    // …to this.
    if (num != 0)
    result = 100 / num;
    else
    result = 0;
  19. 使用 HttpResponse.Write 方法进行字符串串联
    该方法提供非常有效的缓冲和连接服务。但是，如果您正在执行广泛的连接，请使用多个 Response.Write 调用。下面示例中显示的技术比用对 Response.Write 方法的单个调用连接字符串更快。

    Response.Write(”a”);
    Response.Write(myString);
    Response.Write(”b”);
    Response.Write(myObj.ToString());
    Response.Write(”c”);
    Response.Write(myString2);
    Response.Write(”d”);
  20. 除非有特殊的原因要关闭缓冲，否则使其保持打开
    禁用 Web 窗体页的缓冲会导致大量的性能开销。
  21. 只在必要时保存服务器控件视图状态
    自动视图状态管理是服务器控件的功能，该功能使服务器控件可以在往返过程上重新填充它们的属性值(您不需要编写任何代码)。但是，因为服务器控件的视 图状态在隐藏的窗体字段中往返于服务器，所以该功能确实会对性能产生影响。您应该知道在哪些情况下视图状态会有所帮助，在哪些情况下它影响页的性能。例 如，如果您将服务器控件绑定到每个往返过程上的数据，则将用从数据绑定操作获得的新值替换保存的视图状态。在这种情况下，禁用视图状态可以节省处理时间。 默认情况下，为所有服务器控件启用视图状态。若要禁用视图状态，请将控件的EnableViewState 属性设置为 false，如下面的 DataGrid 服务器控件示例所示。
    <asp:datagrid EnableViewState=”false” datasource=”…” runat=”server”/>
    您还可以使用 @ Page 指令禁用整个页的视图状态。当您不从页回发到服务器时，这将十分有用：
    <%@ Page EnableViewState=”false” %>
    注意:@ Control 指令中也支持 EnableViewState 属性，该指令允许您控制是否为用户控件启用视图状态。若要分析页上服务器控件使用的视图状态的数量，请(通过将 trace=”true” 属性包括在 @ Page 指令中)启用该页的跟踪并查看 Control Hierarchy 表的 Viewstate 列。有关跟踪和如何启用它的信息，请参见 ASP.NET 跟踪。
  22. 避免到服务器的不必要的往返过程
    虽然您很可能希望尽量多地使用 Web 窗体页框架的那些节省时间和代码的功能，但在某些情况下却不宜使用 ASP.NET 服务器控件和回发事件处理。通常，只有在检索或存储数据时，您才需要启动到服务器的往返过程。多数数据操作可在这些往返过程间的客户端上进行。例如，从 HTML 窗体验证用户输入经常可在数据提交到服务器之前在客户端进行。通常，如果不需要将信息传递到服务器以将其存储在数据库中，那么您不应该编写导致往返过程的 代码。如果您开发自定义服务器控件，请考虑让它们为支持 ECMAScript. 的浏览器呈现客户端代码。通过以这种方式使用服务器控件，您可以显著地减少信息被不必要的发送到 Web 服务器的次数。
    使用 Page.IsPostBack 避免对往返过程执行不必要的处理
    如果您编写处理服务器控件回发处理的代码，有时可能需要在首次请求页时执行其他代码，而不是当用户发送包含在该页中的 HTML 窗体时执行的代码。根据该页是否是响应服务器控件事件生成的。
    使用 Page.IsPostBack 属性有条件地执行代码
    例如，下面的代码演示如何创建数据库连接和命令，该命令在首次请求该页时将数据绑定到 DataGrid 服务器控件。

    void Page_Load(Object sender, EventArgs e)
    {
    // Set up a connection and command here.
    if (!Page.IsPostBack)
    {
    String query = “select * from Authors where FirstName like ‘%JUSTIN%’”;
    myCommand.Fill(ds, “Authors”);
    myDataGrid.DataBind();
    }
    }

    由于每次请求时都执行 Page_Load 事件，上述代码检查 IsPostBack 属性是否设置为 false。如果是，则执行代码。如果该属性设置为 true，则不执行代码。注意 如果不运行这种检查，回发页的行为将不更改。Page_Load 事件的代码在执行服务器控件事件之前执行，但只有服务器控件事件的结果才可能在输出页上呈现。如果不运行该检查，仍将为 Page_Load 事件和该页上的任何服务器控件事件执行处理。

  23. 当不使用会话状态时禁用它
    并不是所有的应用程序或页都需要针对于具体用户的会话状态，您应该对任何不需要会话状态的应用程序或页禁用会话状态。 　　若要禁用页的会话状态，请将 @ Page 指令中的 EnableSessionState 属性设置为 false。例如:
    <%@ Page EnableSessi %>
    注意:如果页需要访问会话变量，但不打算创建或修改它们，则将@ Page 指令中的 EnableSessionState 属性设置为ReadOnly。还可以禁用 XML Web services 方法的会话状态。有关更多信息，请参见使用 ASP.NET 和 XML Web services 客户端创建的 XML Web services。若要禁用应用程序的会话状态，请在应用程序 Web.config 文件的 sessionstate 配置节中将 mode 属性设置为 off。例如:
    <sessionstate mode=”off” />
  24. 仔细选择会话状态提供程序
    ASP.NET 为存储应用程序的会话数据提供了三种不同的方法：进程内会话状态、作为 Windows 服务的进程外会话状态和 SQL Server 数据库中的进程外会话状态。每种方法都有自己的优点，但进程内会话状态是迄今为止速度最快的解决方案。如果只在会话状态中存储少量易失数据，则建议您使用 进程内提供程序。进程外解决方案主要用于跨多个处理器或多个计算机缩放应用程序，或者用于服务器或进程重新启动时不能丢失数据的情况。有关更多信息，请参 见 ASP.NET 状态管理。
  25. 不使用不必要的Server Control
    ASP.net中，大量的服务器端控件方便了程序开发，但也可能带来性能的损失，因为用户每操作一次服务器端控件，就产生一次与服务器端的往返过程。因此，非必要，应当少使用Server Control。
  26. ASP.NET应用程序性能测试
    在对ASP.NET应用程序进行性能测试之前，应确保应用程序没有错误，而且功能正确。具体的性能测试可以采用以下工具进行：Web Application Strees Tool (WAS)是Microsoft发布的一个免费测试工具，可以从http://webtool.rte.microsoft.com/上 下载。它可以模拟成百上千个用户同时对web应用程序进行访问请求，在服务器上形成流量负载，从而达到测试的目的，可以生成平均TTFB、平均TTLB等 性能汇总报告。 Application Center Test (ACT) 是一个测试工具，附带于Visual Studio.NET的企业版中，是Microsoft正式支持的web应用程序测试工具。它能够直观地生成图表结果，功能比WAS多，但不具备多个客户 机同时测试的能力。服务器操作系统”管理工具”中的”性能”计数器，可以对服务器进行监测以了解应用程序性能。

结论：
对于网站开发人员来说，在编写ASP.NET应用程序时注意性能问题，养成良好的习惯，提高应用程序性能，至少可以推迟必需的硬件升级，降低网站的成本。

Popularity: 37% [?]

分类: .NET 标签:

律师游云庭:番茄花园比QQ珊瑚虫侵权更严重

2008年8月21日 admin 没有评论

对于番茄花园版的Windows XP作者洪磊因侵权被抓一事，法律专家游云庭认为，因为Windows XP涉及收费问题，因此番茄花园侵权比QQ珊瑚虫事件更严重。游云庭表示，此 次番茄花园事件与QQ珊瑚虫事件之间质的区别即在于，微软的Windows XP收费，而腾讯的即时通讯软件QQ是免费的。番茄花园网站在网上提供软件下载，或多或少都会给微软造成财产损失，而对于腾讯公司不仅QQ软件本身是免费 的，自己也 曾推出过珊瑚虫版的QQ。比较来看，番茄花园的社会危害性要大于珊瑚虫版QQ事件。

至于在法律的判决上，游云庭律师认为，番茄花园版的作者洪磊也将面临比珊瑚虫QQ作者陈寿福更严厉的制裁。在陈寿福案件中，法院认定其侵犯了著作权，判处有期徒刑三年，罚金120万元，并对非法所得117万予以追缴。

Popularity: 13% [?]

分类: JAVA 标签:

IE8将具备’色情网站’专用浏览模式

2008年8月21日 admin 没有评论

IE8 beta2的倒计时开始了。因为微软给消费者承诺的是在8月进行此次测试，算一算，只剩下11天8月就结束了。
当然，微软不可能一口气把所有功能都放出来。但是据Istartedsomething的Long Zheng称，IE8可能会包含一个叫做‘私人浏览’的模式，当然你可以简单的将其当作‘色情网站专用模式’。
这个模式Mozilla也有，但是从Firefox3开始它们就放弃了这项技术，而Safari从2005年开始就拥有这个功能了。
私人浏览模式允许用户在浏览某类网站时，自动清楚所有痕迹，包括浏览历史、cookie、以及任何你输入的信息。
而微软的官方发言人也称，IE8在个人隐私控制方面将全面加强。
其实这项功能也是目前很多优化软件所具备的功能，看来微软还是会满足用户的呼声的。

Popularity: 10% [?]

分类: 互联网 标签:

LiveCycle Data Services 安装简介

2008年8月21日 admin 没有评论

本文是经过翻译整理以后的文章，只选取了其中关于Tomcat 6的配置

介绍：http://labs.adobe.com/technologies/livecycle_dataservices2_6/

下载：http://labs.adobe.com/downloads/livecycle_dataservices2_6.html

在下载页面有以下的版本可以下载，以下载windows平台下的版本为例来说明

l Download Installer for Windows (EXE, 181 MB)

l Download Installer for Linux (BIN, 189 MB)

l Download Installer for Solaris (BIN, 192 MB)

l Download Installer for Java (JAR, 156 MB)

1 安装LiveCycle Data Services 2.6 Beta2

2 LiveCycle Data Services ES 和 Apache Tomcat 应用服务器的整合

3 在LiveCycle Data Services ES 和 Apache Tomcat 应用服务器的整合平台上运行TestDrive

4 LiveCycle Data Services ES 的JavaEE 应用(如果你下载的是jar包请看，否则跳过)

5 添加具体的服务器配置（以Tomcat为例）

以下是官方信息：

Download LiveCycle Data Services ES

To complete the trial download process, please use this trial serial number: 1306-4038-4494-1343-9848-7117.

  • LiveCycle Data Services ES, Single-CPU License (for production environments)
  • LiveCycle Data Services ES, Trial Developer License (1+ CPUs)

English | AIX (159 MB)
English | HP_UX (159 MB)
English | Linux (192 MB)
English | Solaris (196 MB)
English | Windows (185 MB)
System Requirements

1.安装LiveCycle Data Services 2.6 Beta2

adobe LiveCycle Data Service ES 就像 JavaEE Web 应用一样，每个安装都允许你从配置文件选择

* LiveCycle Data Services ES 与整合过的 Apache Tomcat 应用服务

* LiveCycle Data Services ES Web应用

LiveCycle Data Services ES 为一下的平台提供安装版

* Windows

* Linux

* Solaris

* Java(跨平台的安装版)

LiveCycle Data Services ES 支持以下服务器

* Apache Tomcat 6.0.x

* JBoss Application Server 4.0.3 SP1+, 4.2.x

* BEA Weblogic 9 and 10

* IBM WebSphere Application Server 6.1.x

* Fujitsu Interstage 9

* Hitachi Cosminexus 7

* NEC WebOTX

* Oracle 10G AS (10.1.3)

* SAP NetWeaver CE 7.1 SP3

* Adobe JRun 4 Updater 7

注意：LiveCycle Data Services ES 不包括任何Flex编译器，包含web层编译器在以前的版本中有包含。设置你的编译环境的信息，请看Setting up an SDK,compilers,and Flex builder for LiveCycle Services ES 2.6 。也请注意，你整合标准单独的LiveCycle Data Services ES server 和 ColdFusion. 更地盘的信息请看整合 LiveCycle Data Services ES 与 ColdFusion 8.

这些安装都指向根路径，install_root 指向的是你安装 LiveCycle Data Services ES 的根路径

这些安装包括以下web应用的存档(war)文件

* lcds.war 最重要的war文件，使用这个文件可以作为你建立Sample LiveCycle Data Services ES 应用的起点

* lcds-samples.war 简单的Sample LiveCycle Data Services ES 应用

* ds-console.war 对Sample LiveCycle Data Services ES 简单的监听应用程序

每个war文件都是分离的独立的应用。如果你想建立一个JavaEE 的web应用程序配置，你必须有一个现成的JavaEE应用服务器或者是可以解释web应用程序的Servlet容器。如果你没有一个现成的JavaEE 服务器或不熟悉war文件的部署，那么就使用整合过的Tomcat配置即可开始

2.LiveCycle Data Services ES 和 Apache Tomcat 应用服务器的整合

该LiveCycle Data Services ES 和集成的Apache Tomcat应用服务器

该LiveCycle Data Services ES 与集成的Tomcat安装选项包含下列文件和目录下安装的根目录：

readme.htm 包含概述信息

lcds.war LiveCycle Data Services ES web应用模板,为新的应用做新的起点.

lcds-samples.war  LiveCycle Data Services ES 实例应用.

ds-console.war 为 LiveCycle Data Services ES 简单的监听应用的部署.

license.txt 许可信息

/tomcat  一个安装的Apache Tomcat 包括 lcds, lcds-samples, 应用程序扩展部署的默认控制台

/resources 包括 Flex SDK 源代码, 全部注释配置文件, 用于security, clustering, Flex Ajax Bridge, 和 WSRP的目录和文件. Flash Player 的安装是在 flex_sdk_3.zip 文件里。

在集成的Tomcat配置上安装LiveCycle Data Services ES

1. 阅读LiveCycle Data Services ES 发布说明和最新的咨询

2. 启动安装程序。根据你的操作系统执行下列操作之一。

1) # Windows版本 -双击安装程序文件（ l cds26- w in.exe） 。

2) # UNIX 或 Linux – 设定的工作目录到目录包含安装程序文件，然后输入以下命令并指定安装程序文件，为您的操作系统;

3) 例如：

4) ./lcds26-lin.bin -i console

3. 接受许可协议

4. 在序列号的界面，单击“下一步”跳过

5. 指定安装目录或者接受默认设置

6. 选择LiveCycle Data Services的Tomcat选项

7. 完成余下的步骤

8. 开始LiveCycle Data Services，请打开一个命令窗口，浏览到你的install_root/tomcat/bin ，并输入catalina 然后巧回车。对于Unix 和 Linux 输入.catalina。在windows下你可以浏览到install_root/tomcat/bin下，然后双击 catalina.bat 。

9. 该LiveCycle Data Services使用了HSQLDB hsqldb数据库是安装在Install_root/sampledb目录下。启动实例数据库：

1) 打开一个命令窗口并且转到Install_root/sampledb目录下

2) 运行startdb.bat(windows) 或者 startdb.sh(unix)

3.运行testdrive与集成的Tomcat安装

在这里有个安装好的tomcat6.0.14 与 LCDS,其中有很多测试驱动

1. 启动tomcat (startup.bat or starup.sh)

2. 打开浏览器http://localhost:8400/lcds-samples

4.LiveCycle Data Services ES 的JavaEE web应用

( 如果你下载的是jar包请看，否则跳过 )

以下是目录结构

readme.htm

lcds.war

lcds-samples.war

ds-console.war

license.txt

/resources

安装LiveCycle Data Services ES 的web应用程序

1. 阅读LiveCycle Data Services ES 发布说明和最新的咨询

2. 启动安装程序。根据你的操作系统执行下列操作之一。

1) # Windows版本 -双击安装程序文件（ l cds26- w in.exe） 。

2) # UNIX 或 Linux – 设定的工作目录到目录包含安装程序文件，然后输入以下命令并指定安装程序文件，为您的操作系统;

3) 例如：

4) ./lcds26-lin.bin -i console

3. 接受许可协议

4. 在序列号的界面，单击“下一步”跳过

5. 指定安装目录或者接受默认设置

6. 选择LiveCycle Data Services的Tomcat选项

7. 完成余下的步骤

8. 开始LiveCycle Data Services，请打开一个命令窗口，浏览到你的install_root/tomcat/bin ，并输入catalina 然后巧回车。对于Unix 和 Linux 输入.catalina。在windows下你可以浏览到install_root/tomcat/bin下，然后双击 catalina.bat 。

9. 该LiveCycle Data Services使用了HSQLDB hsqldb数据库是安装在Install_root/sampledb目录下。启动实例数据库：

5) 打开一个命令窗口并且转到Install_root/sampledb目录下

6) 运行startdb.bat(windows) 或者 startdb.sh(unix)

10. 以J2EE web应用 被 Java installer (any platform)使用的样式安装

7) 阅读LiveCycle Data Services ES 发布说明和最新的咨询

8) 运行安装程序，打开命令提示符窗口，浏览到(lcds26-install.jar)的目录下，接着输入 java_home/bin/java -jar lcds26-install.jar -i console

9) 接着完成步骤3-9

5.添加具体的服务器配置

l Tomcat

l WebSphere

l Jboss

l OC4J

l Running_from_a_compressed_WAR

以下以tomcat为例子来说明

在使用LCDS和Tomcat之前，你必须安装Java Transaction API (JTA) 和你将来计划使用的部署之后的war文件。这些步骤对整合的tomcat安装来说不是必须的。

1. 停止 tomcat

2. 安装JTA,推荐俺使用Java Open Trasaction Manager(JOTM)

1) 下载jotm从http://jotm.objectweb.org/

2) 复制jar文件从jotm-root/lib 到[tomcat-root]/common/lib.

3) 建立一个context文件，使用Transaction标签为你的web应用程序注册一个JOTM 例如 :

<Contextdoc Base=”${catalina.home}/webapps/samples” privileged=”true” antiResourceLocking=”false” antiJARLocking=”false”>

<Transaction factory=”org.objectweb.jotm.UserTransactionFactory” jotm.timeout=”60″/>

</Context>

注意：如果已经存在此文件，哪么就在<context>下添加<Transaction>标签

4) 设置JVM最小内存为512M ，在java_opts 的值改为 -Xmx512m

3. (可选)使用自定义身份验证，

4. (可选)使用JMS中间件如ActiveMQ 或者 OpenJMS

5. 重新启动tomcat

官方使用注册码：
To complete the trial download process, please use this trial serial number: 1306-4038-4494-1343-9848-7117

以下是我收集的注册码：
LiveCycle Data Services注册码：
1306-4100-8708-9432-2243-5880
1306-4867-8501-8670-3893-7864

Popularity: 51% [?]

分类: DevelopTools, Flash 标签: ,

浏览器最新趋势报告:Firefox有望明年夏天超越IE

2008年8月18日 admin 没有评论

如今微软一直霸占着操作系统和浏览器第一的地位，但是毕竟那都是收俺们RMB的啊。于是开源软件越来越受欢迎了。前段时间的《操作系统(OS)占有率报告》中了解到Linux系统呈现上升的趣事。今天得到的浏览器占有率报告的同样是开源（Firefox）继续呈现上升的趋势，更有预言：Firefox有望明年夏天超越IE。
预言是有根据的：
先来看看浏览器的2008年的趋势(VIA)

明显可以看出firefox保持着良好的上升趋势从一月的36.4%到七月的42.6%。来看看Monkey_bites所做的趋势图。

http://howto.wired.com/mediawiki/images/Browser-timeline.png

按照这样的趋势图，如果这样发展的话，明年的夏天Firefox将会超越IE。

虽然在6个月中和一年当中IE7都有所上升，但是相对于IE6的急剧下降，总得来说Firefox慢慢蚕食着IE的市场，所以这样的预言完全是有可能的！于是有人这样幻想：会不会有一天浏览器市场将会是开源的天下呢？

我想：有可能！

Popularity: 12% [?]

分类: 互联网 标签: ,

拥抱Web 3.0

2008年8月18日 admin 没有评论

Web 3.0的最大价值不是提供信息，而是提供基于不同需求的过滤器，每一种过滤器都是基于一个市场需求。如果说Web 2.0解决了个性解放的问题，那么Web 3.0就是解决信息社会机制的问题，也就是最优化信息聚合的问题。

《纽约时报》商业栏目记者John Markoff曾在一篇文章中写道：“人们对Web 3.0或者说是语义网的商业兴趣正在凸现。”这句话虽未对Web 3.0给出明确定义，但不管怎样，语义网这一概念在《New York Times》商业栏目中的出现，我们也看到了未来的发展趋势。

语义网（Semantic Web）之路

简单地说，语义网是一种能理解人类语言的智能网络，它不但能够理解人类的语言，而且还可以使人与电脑之间的交流变得像人与人之间交流一样轻松。

语义网将使人类从搜索相关网页的繁重劳动中解放出来。因为网中的计算机能利用自己的智能软件，在搜索数以万计的网页时，通过“智能代理”从中筛选出相关的有用信息。而不像现在的万维网，只给你罗列出数以万计的无用搜索结果。

目前，在RDF（Resource Description Framework，资源描述框架）和OWL（Web Ontology Language，网络实体语言）的支持下，语义网已经成为能够牢牢嵌入现有网页并且能完善RDF知识储备的新科技，而其理念雏形可追溯至10年之前。

1998年，Tim Berners-Lee就提出了语义网的理念。一些人认为它是关于AI（人工智能）的，另一部分人认为它更多是关于语言学的，还有一些人则认为它是关于数据注释的。而维基百科对语义网给出了这样的定义：一种使用可以被电脑理解的方式描述事物的网络。其实，作为AI的一部分，语义网涉及的范围应该是围绕着对自我的理解和对与我们相关数据的理解。所以，人们可以在开发Web或研究AI的过程中不断地学习和理解语义网。

在Web上，我们已经看到了一些成功的商业模式，如Netscape建成的一个资源互享环境，Amazon和eBay的市场优势，以及Yahoo和 Google的网站广告模式。资源共享带给我们前所未有的改变，不过这种分享精神也可能导致所谓的长尾现象。举个买书的例子，在各大网站显要位置推荐的都不会是最好卖的书籍，但过段时间，这些书的销量就会直线飙升，甚至远远超过一些畅销书籍。在这一过程中，链接是真正让搜索引擎工作的发动机，AI应用程序必须与其他事物联系起来才能为我们创造财富。如果仅将其视为一种工具，将很难得到用户青睐。因此，对AI来说，智能设备具有划时代意义，而如何使用这些工具将变得更加重要。

也许很多人认为Web 2.0已乏善可陈，但Web 2.0的动向曲线中还是可见不少有趣现象。总的来说，Web 2.0是网络科技的社会进化，它去掉了网络上合作性质的信息发布，加入了Tagging（标签）和Microformats（微缩过程）的技术，使得信息的产生和选择升级至一个新阶段，这是Web 2.0的本质。可以预见，在未来几年中，Web 2.0将完成向Web 3.0，即语义网的转变。

web3.0带来新体验

在过去一年中，语义网概念更加深入人心，这得益于RDF语言和能够支持RDF语言的科技的成熟。

与传统结构的数据库相比，RDF数据库拥有诸多优势。针对这些优势，微软于2006年12月在其连接服务框架（Connected Services Framework 3.0）开发者指导中指出，RDF数据库让用户能够灵活地在计划图表中存储当初设计图表时没有考虑到的数据。不仅如此，RDF还可以帮助开发者拉近Web 与数据之间的距离，而这些都是传统的关系数据库做不到的。随着人们对RDF更多的认可，RDF自然成为了最重要的标准查询语言。

在所有服务中最重要的无疑就是信息搜索服务，作为对RSS高度整合的Web 3.0，搜索也被高度整合。人们只需要输入自己的需求，就可以迅速得到所需信息，甚至一套完整的解决方案。例如，在计算机中输入：“我想带我11岁的孩子去一个温暖的地方度假，我的预算为3000美元。”计算机能自动给出一套完整方案，这一方案可能包括度假路线图、适合选择的航班、价格适宜的酒店等。可以预见，承接Web 2.0的以人为本理念，Web 3.0模式中将会出现各种高度细分领域的平民专家。

即将到来的时代

中国互联网自进入Web 2.0时代后，在近3年内获得了高速发展，这种发展呈现出两种趋势，第一种趋势是基于用户的一个需求点，力图在一个平台上整合所有互联网服务。如博客中国向综合门户阵营的靠拢，腾讯转型为综合门户。但这些转变更多的只是为了增加流量和提高用户黏性。

第二种趋势是在用户个别的需求点上进行深度挖掘，纵深发展。如淘宝、奇虎和Donews等。这类公司目前仅仅是业务领域的细分，并没有根据人群进行细分，因此为了提升关注度，他们同样在做综合门户所做的事情，于是纷纷被打上Web 2.0标签，但信息依然散乱，用户依然海量而缺乏细分，而广告主依然因不知该在哪里投放广告而大伤脑筋。可以说，即便借助Web 3.0，这些公司的运作模式依然还是2.0思维。

真正的Web 3.0不仅止于根据用户需求提供综合化服务，创建综合化服务平台，关键在于提供基于用户偏好的个性化聚合服务。在Web 3.0时代，同一模式化的综合门户将不复存在，如人们看到的新浪新闻首页将是个人感兴趣的新闻，而那些他不感兴趣的新闻将不会显示。当然，这种个性化的聚合必须依赖强大的智能化识别系统，以及长期对于一个用户互联网行为规律的分析和锁定，它将颠覆传统的综合门户，使得Web 3.0时代的互联网评价标准不再是流量和点击率，而是到达率和用户价值。

因此，Web 3.0时代能够赢得用户青睐的公司，一定是基于用户行为、习惯和信息的聚合而构建的，人性化、友好界面、简单易用一定是其核心元素，基于用户需求的信息聚合才是互联网的趋势和未来。

文/中国计算机报

Popularity: 24% [?]

分类: WEB基础, 杂谈 标签: ,

Google黑洞

2008年8月18日 admin 没有评论

YouTube当年被Google以1,650,000,000买下来的时候不少网站都热血沸腾起来，被Google收购成了无数起步网站的梦想，但是，但是嫁入豪门以后就是幸福的生活吗？不一定的……
Sergey和Larry刚刚买了我的公司。哦.
上个月月底TechCrunch的Michael Arrington报道说Google已进入收购Digg谈判的最后阶段。几天后Arrington援引不愿透漏姓名的消息来源报道了最新情况：不知出于什么援引Google放弃了这笔交易。Digg这次玩弄 Google完全在意料之中-就像最近几年里每个大的科技公司都有收购Digg的传闻一样-但是对于一些Digg迷来说这次交易的失败确实是一个不小的打击，“Google是唯一我能想到的能改进Digg的公司，”一条评论这样写道。

这条评论表明-在IT爱好者眼里卖给Google并不是卖了出去。在硅谷Google是创业者的乐园，不是因为免费食物也不是因为那些奇妙的厕所。凭着他们平行的内部结构组织和给员工在开发业余项目上的自由，Google被认为还是像一个刚起步的公司那样运作：一个愿意把金钱和开发资源投在永不安分的开发者身上的公司，他们的目标就是创造下一个传奇。

另一方面，我还是把Jaiku拿出来看看，去年Google收购这一微型博客后-一款被认为是Twitter对手的服务-很快就不再对新用户开放了。再看看JotSpot，一家刚起步的为办公用户提供wiki协作工具的公司。Google在2006年十月份买下了这家公司，十六个月后推出一款版本完全不同的服务，Google Sites，非常不受JotSpot老用户欢迎，他们觉得被无情的抛弃了。

Jaiku 和JotSpot是我称之为Google黑洞现象的代表。尽管Google一向以促进新公司的发展而闻名于世，不少投入这家山景城公司欢迎的怀抱的服务就从人间蒸发啦。其中的规律：公司被收购。用户们欢呼。公司休耕几个月。用户有点不耐烦了。公司的员工被寄养到别的Google项目上。接下来的几个月公司继续休耕。用户更不耐烦…

想想Dodgeball的命运吧，非常有创意的移动服务公司，Twitter，Jaiku和不少依附在iPhone上的定位程序的前辈。公司2003年开始运营，利用他们提供的服务用户可以发送定位自己所在位置的文字信息。作为回应，你也会收到一些信息，显示附近出现的你的朋友（或朋友的朋友）。2005年Dodgeball的创建者，Dennis Crowley和Alex Rainert，刚刚完成在纽约大学的研究生学业，正在寻找看好他们服务的投资者，当时他们的服务在曼哈顿的IT人士中间很受欢迎。在所有可能的投资者中，Google提出的要求是最少的。Google付给Dodgeball一小笔钱和股票-具体的数目没有披露-然后Crowley和Rainert就搬进了Google设在纽约的办公室。

Dodgeball 的创始人很快就发现他们新的公司的头根本就不对这次收购怎么看好。Google花了六个月才安排了一位软件工程师到Dodgeball。过了一段时间公司的头头们开始催Crowley和Rainert去做其他的事。两位创始人才明白Google买下Dodgeball只是看重了他们在移动社交型网络商业方面的理解力，而不是他们所提供的服务。这两个人在2007年五月份离开Google，Dodgeball网站还在，但是没有人在打理。

从许多方面说Google收购Dodgeball一事只是一个特例。他们是Google上市之初收购的一批公司中的一家，Crowley对我强调说当时转手 的钱非常非常的少。（Google拒绝对Dodgeball进行评论。）但是这个故事的一些方面也发生在了其他一些Google的收购上。 Dodgeball面临的一个问题就就是技术上的：要把Dodgeball相对简单的代码库移植到Google复杂的内部基础架构上来需要花很长的时间- 在移植后，系统的代码会变的非常的复杂，复杂到Dodgeball的创始人无法理解的地步。此外还有官方的障碍。作为一个刚起步的公司Dodgeball 已经习惯于每个星期增加一些新的功能的做法；在Google，两个创始人被告知首先要得到各层主管的认可（尽管负责Dodgeball的小组已经开始背着高层领导偷偷地插入一些小的功能上的改动）。

技术问题也在困扰着最近收购的一些公司。去年十月份Jaiku宣布被Google收购的时候公司创始人说他们的网站在短时间内将不会在对新用户开放以配合 Google工程师的工作。三个月后，新用户申请还是无法用，Jaiku在博客上发出一条更新：“实话说，前期我们的大部分时间都花在了解Google上了，”创始人之一Jyri Engeström写道。四月份的时候Jaiku说他们的问题基本上都得到解决。五月份的时候一些用户抱怨Jaiku速度太慢Engeström又一次保证说他们的服务会好起来的。“我们也感受到了短时间内的痛苦，”他写道。“十分感谢和我们在一起！”现在收购已经过去十个月了，Jaiku还是没有对新用户开放。在这段时间内Twitter（它也被自己颇具传奇色彩的技术问题所困扰）和Friendfeed，另外一个这就是在做的事的起步公司，新的用户都在增加。两家碰巧都是前Google员工创建的。

Google一位发言人向我保证说Jaiku的延迟和收购没有任何关系；他认为这是任何尝试做热门服务的公司都会遇到的问题。在一次采访中Google负责收购的副总裁David Lawee大略的介绍了一下Google在买下公司之后采取的严格措施。所有预期的交易都会得到Google执行管理团队的同意，每次收购都会有专人负责整合相关资源-设计，公关，销售等等-保证新公司在Google的基础架构上正常运行的一切。

Lawee 也承认把一家新的公司搬到Google的系统里非常费劲，他也表明Google在预测移植技术难度方面是非常精确的。Lawee提到一般的移植要花三到六个月的时间，但是移植带来的效益也是巨大的：YouTube，作为Google的大宗收购之一，现在每分钟会收到12个小时的视频，如果单靠 YouTube自己这个速度是根本想都想不到的。

Lawee还反对Google黑洞的说法-尽管公众不会在短时间内看到结果，被收购的公司在大的方面对Google还是有所影响的，他讲到。早在2006年Google收购了Measure Map，一款颇受博客用户欢迎的查看自家网站流量的工具；这项服务从收购之日起就不再对新用户开放了。但是Google不是为了Measure Map才收购Measure Map，Lawee说。他们收购这家公司这样他们可以把上面的功能用在另一款Google查看流量的程序上了，Google在线流量分析-“并且我们真的这样做了。”Google也在为JotSpot做同样的转型打算，据Lawee描述，“这家公司正在进行的开发计划非常令人振奋。”JotSpot用户可能不喜欢对这项服务的改动，他说，但是在台下，JotSpot的员工正在Google努力的工作。

想想Google的历史，Digg迷应该为交易的失败高兴而不是失望。迫切期望看到Diggoogle的Digg用户说相对于被微软或者是别的科技巨头收 购，这种境遇要好的多。但是这种说法没有任何根据。TechCrunch的Arrington报道说Google打算把Digg整合到Google新闻里 -这意味着大G并不想让Digg保留原来的样子。

需要注意的是收购消化不良问题不只发生在Google一家：一般说来把一家刚起步的公司整合到一家公司引起的问题比解决的问题更多。我打电话给Jason Fried，37 Signals的头，非常成功的网络公司，主要业务是为小公司制作软件，他们就坚定不移的要保持独立。“你招到非常不错的人，然后你把他们放到大公司里，但是那些政策就把他们给搞晕了，”Fried解释说。“把小公司放到大公司里他们本来的好东西也都给抹杀了。”

这就是发生在Jaiku身上的事吗？他们正在做一个超级秘密的可以一下打倒对手的社交型网站-还是成了没人问没人管的苦孩子了？还有那家Google一年前买下的挺不错的刚起步的电信公司GrandCentral-为什么还不对新用户开放？没有人知道真正的答案。现在所有的细节都牢牢地粘在黑洞里了。

Popularity: 18% [?]

分类: WEB基础, 杂谈 标签:

SQL server数据页页头参数列表

2008年8月18日 admin 没有评论

SQLserver每个数据页面的页头都是固定的96字节，另外就是真正的数据行以及行偏移矩阵。
掌握页面元数据也是对SQLserver内部组织的一个了解。
其中nextpage 和 prepage参数只有在相应表有聚集索引的时候，才会将页面以链表的形式组织起来，不然，仍然是靠的表扫描（先扫描IAM页）
LSN用于事务管理
行偏移矩阵是用作跟踪数据在磁盘上的真正位置，以及与逻辑位置的对应关系。顺便说一下即使表有聚集索引，行存储的物理位置仍然不是按照索引顺序，真正的物理位置顺序由操作系统决定。只是建立了聚集索引，表数据行的逻辑顺序才跟索引顺序一致。
使用DBCC PAGE可以对其进行查看。

字段 包含

pageID 该页面在数据库中的文件编号和页码

nextPage 如果该页面处于一个页面链中，那么该字段表示下一个页面的案件编号和页码

prevPage 如果该页面处于一个页面链中，那么该字段表示上一个页面的案件编号和页码

objID 该页面所属的对象的ID

lsn 用于更改和更新该页面的日志序列号（LSN）值

slotCnt 该页面中所用的总的槽（行）数

level 该页面在索引中的级别（对于叶页通常为0）

indexId 该页面的索引ID（对于数据页面通常为0）

freeData 该页面中的第一个自由空间的字节偏移量

pminlen 行的固定长度部分的字节数

freeCnt 页面中的自由字节数

reservedCnt 由所有事务预留的字节数

xactresenved 由最近启动的事务预留的字节数

tornBits 每个扇区1位，用于检测残缺页的写

flagBits 包含关于页面其他信息的2字节位图

顺便说一句，从这个链接
http://www.1huifu.com/Get/dr-doc/09_32_25_1917.htm
的一篇文章类似sqlserver2005技术内幕之存储引擎的第209页的内容极度重合，后搜到作者相关书籍：
http://www.golden-book.com/booksinfo/52/522761.html
哎，天下文章一大抄。

Popularity: 14% [?]

分类: DataBase, Sql Server 标签: ,

MSSQL优化之 1.3 存储架构之 页

2008年8月18日 admin 没有评论

数据库的页构成

页

SQL Server中的页是最基本的数据单位组成，他有8KB，也就是8192个字节（mssql7.0以前是一个页面2KB），而sql server的一个页面，由页头，数据行，和slot table组成（行偏移的位置的记录数组。

页头

页头是一个固定的96字节的大小，他是一个页面的元数据，记载与本页相关的许多信息，具体的参数，大家可以参看我很久以前写的一篇文章，SQL server数据页页头参数列表，这篇文章没有太细致的对参数进行讲解，我在这里仔细说一下：

PAGEID：

页面的ID，在mssql中，唯一定位一行数据（包括索引）的，靠的是mssql里面的一个我把它称之为的三段式表达式：FPS ID，即 file id,page id,slot id。File ID 为文件ID，找到行所在的文件，pageID找到行所在的页面，slot ID为插槽ID，即这一行位于这个页面的第几个插槽。插槽的概念会在稍后提到。1:1:2表示这行数据位于第一个文件的第一个页面的第二个插槽。

Nextpage：

这个参数在页面处于页面链的时候，指示这个页面的下一个页面地址，这个的表达格式是 fileid：pageid，比如：1：2，请注意一下，这个页面指针并不是完全指向物理磁盘上的页面地址，因为外部碎片的存在！如果是堆表，那么这两个参数会是null。

objID：

在sysobjects 表内的对应的ID

Lsn：

Log sequence number ，日志序列号，他用来记录当这个页面行数据发生改变时的日志记录号，和此前版本的lsn，这个对于事务的管理非常重要，他将指示数据是否被回滚，或者被重做。

Slotcnt：

页面插槽总数。也就是这个页面有多少行。一个萝卜一个坑，一行数据一个槽。

Level：

在索引页中的级别，0为子叶节点。

Indexed：

0为普通数据页面（堆表），1为聚集索引页面，大于1都为非聚集索引。

Pminlen：

每行数据的固定长度，比如一行数据有3个int字段，1个char5的字段，2个varchar字段，那么固定长度是17.这个参数在mssql定位字段数据时起到至关重要的作用。

freeCnt：

页面空闲的字节数，在每次需要插入数据时就检测这个值，空间是否够用。

m_ghostRecCnt：

页面含有的幻影行的数目。幻影行是sql server在删除数据时，并不及时删除数据，而是仅仅将他标记为幻影行，并不对磁盘中的数据进行清空。这样做有非常大的好处。如果数据回滚，那么只需要将标记去掉即可。数据库会在空闲的时候将页面进行整理，去掉幻影行，而没有必要即时性的整理页面。

Slot table

插槽表是用于记录行在页内的逻辑顺序和物理顺序的对应数组。比如逻辑上是第一行的数据可能在这个页面内是物理上位于第二行。而这个物理上的位置，指的是在这个页面的8KB的空间内的位置，slottable有记录行的逻辑顺序数，物理顺序数，还有相对页头的偏移量，以便数据查找定位。在这里衍生的一个问题就是，逻辑上的行顺序可能存储在磁盘上的物理顺序也不会是一个顺序！（当然还有可能页面存在lob数据，成为一个页指针）

猜想：Slottable实际上是对空间的一个利用，当然也涉及到了当数据行进行增删改查时，对页面的破坏，最后在设计上导入了slot table。假设一个场景，当一个页面全部被填充满了，freecnt为0的时候，删除一个数据（页面存储100个数据，删除其中的第2个），那么如果根据正常的逻辑，应该是将2到第100行的数据全部移动，然后整理出末尾还剩一行的数据。这样现实吗？那样页面所有数据都要移动，似乎不大现实。所以mssql在设计上引入了slot table ,这样，物理上和逻辑上的顺序由slot table 映射起来，存储引擎负责向slot table 要数据位置，slot table负责映射其真正的物理位置，slottable在其中搭建起一个桥梁，降低了他们之间的耦合，使得当逻辑顺序发生变化的时候，物理位置却不需要相应的变化，哈哈，相信这个也是一个典型的设计上的解耦的例子吧～～

Popularity: 21% [?]

分类: DataBase, DevelopTools, MySql 标签: , ,