Chart FX-Chart Return Mechanisms and Web Farms
Return Mechanisms
To improve the level of responsiveness as well as enhancing support for different server architectures, Chart FX provides two ways of processing and returning charts to the browser. These mechanisms are provided by 2 methods: RenderControl and RenderToStream.
When a user hits a page containing the RenderControl method, a chart file is saved to disk and a HTML tag (IMG, OBJECT) is returned so the browser can know the location of the chart file on the web server. Finally, a second trip back to the server is necessary to pull the chart from the server and display it on the page as a static image or an active component. One of the greatest benefits for using RenderControl is that charts can be easily integrated into your existing web pages and allows support for automatic browser detection. However, saving a file to disk can have its toll on server performance.
On the other hand, the RenderToStream method prevents the chart file from being saved to disk by bit-streaming the chart directly to the browser; this process leads to fewer round-trips between the client and the server. However, integration to the web page is awkward because you must point to another file that returns the bit stream to the browser. Also, limited browser detection is provided using this methodology preventing your application from making "smart" decisions based on the user's browser capabilities.
In terms of performance, although the RenderToStream method is processor intensive, it allows developers to boost performance and scalability and permits the use of Chart FX on intricate server architectures such as web farms.
Web Farms (Server Clustering)
Once you hit a certain threshold, cost-effective scalability requires the use of multiple processors spread across multiple servers. In other words, you'll need a Web Farm.
We mentioned that when using the RenderControl method a chart file is saved to disk. The one problem on web farm architectures is that when the browser comes back to the server to retrieve such file; the HTTP request could be directed to another web server on the farm on which the chart was not originally saved, resulting in an empty chart placeholder on the page.
While changing the server affinity setting, which lets you instruct the service to route HTTP requests over the same physical server once the first request has gone through, may solve this issue, affinity slows the system down by requiring it to maintain a user-to-server mapping and perform a lookup upon each request. In other words, changing server affinity compromises scalability and the benefits of request-based load balancing are lost. For this reasons, Chart FX provides configuration mechanisms that will take care of this issue, allowing the servers to know exactly where the chart files are.
However, generating a chart file that will be saved on disk poses many server performance and scalability problems on a Web Farm. Therefore, the use of the RenderToStream method bit-streams the chart directly to the browser, preventing many of the above mentioned issues and providing a more natural integration to a web farm is more suitable in this environment.