Chart FX-图表返回机制与Web农场 返回机制

Chart FX-图表返回机制与Web农场返回机制

为了提高响应速度并加强对不同服务器架构的支持，Chart FX 提供了两种处理图表并将其返回给浏览器的方法。这两种机制分别由两种方法实现：RenderControl 和 RenderToStream。

 

当用户点击包含 RenderControl 方法的页面时，图表文件会被保存到磁盘中，并返回一个 HTML 标签（IMG、OBJECT），以便浏览器知道图表文件在网络服务器上的位置。最后，还需要再次返回服务器，以便从服务器中提取图表，并以静态图像或活动组件的形式显示在页面上。使用 RenderControl 的最大好处之一就是可以轻松地将图表集成到现有的网页中，并支持浏览器自动检测。不过，将文件保存到磁盘可能会影响服务器性能。

 

另一方面，RenderToStream 方法通过直接将图表以比特流的方式传输到浏览器，避免了将图表文件保存到磁盘；这一过程减少了客户端和服务器之间的往返次数。但是，要与网页集成却很麻烦，因为您必须指向一个以比特流方式返回浏览器的文件。此外，采用这种方法时只能使用部分浏览器检测功能，因而您的应用程序无法根据用户使用的浏览器性能做出 “明智”的决定。

 

就性能而言，虽然 RenderToStream 方法需要大量处理器，但它允许开发人员提高性能和可扩展性，并允许在复杂的服务器架构（如Web农场）上使用 Chart FX。

 

Web农场（服务器群集）

一旦达到一定的阈值，要实现经济高效的可扩展性，就需要在多个服务器上使用多个处理器。换句话说，您需要一个Web农场。

 

我们提到过，使用 RenderControl 方法时，图表文件会保存到磁盘中。Web农场架构存在的一个问题是，当浏览器返回服务器检索该文件时，HTTP 请求可能会被指向农场中的另一个网络服务器，而该服务器上的图表并非最初保存的，从而导致页面上的图表占位符为空。

 

通过更改服务器的亲和性设置，您可以下达指令，将HTTP请求在第一个请求被通过后定向到同一台物理服务器上，这可能会解决这个问题，但亲和性要求系统必须保持用户到服务器的映射，且每次请求时都会执行lookup，这会减慢系统的运行速度。换句话说，改变服务器亲和性会影响可扩展性，失去基于请求的负载平衡的好处。而Chart FX 提供的配置机制可以解决这个问题，让服务器确切知道图表文件的位置。

 

然而，生成一个保存在磁盘上的图表文件会给 Web 农场带来许多服务器性能和可扩展性问题。因此，在这种环境下，更合适的方式是使用 RenderToStream 方法将图表直接以比特流方式传输到浏览器，这可以避免上述许多问题，也可实现更流畅的与Web农场的集成。