{INCLUDE _LOGOS.HTM}

Coyote Web Server

A Comparison of the Coyote Coyote Web Server with Pick System's D3 FlashConnect

July 6, 1998
Douglas B. Dumitru, doug@modsoft.com
Modular Software Corporation

Pick Systems has recently released a new product called FlashConnect to provide a mechanism where D3 applications can be retrofitted with an HTML or web user interface.  Modular Software has received a number of queries about how Coyote and specifically the Coyote web server component of Coyote compares to FlashConnect.  This paper tries to compare what FlashConnect is and attempts to accomplish and how Coyote approaches the same problems.

Information about FlashConnect comes from reviewing Pick's literature, attending some of their short seminars, and talking with others who have used FlashConnect in a development setting.  Modular Software does not currently have FlashConnect running in-house and no Coyote elements are in any way based on any FlashConnect code.

The General Architecture

The Coyote Coyote web server is a complete HTTP/1.0 web server with a tightly integrated application environment.  With Coyote, the Pick environment is not a slave of external internet servers, but instead implements a high-performance, fully functional web server completely within Pick.  FlashConnect is a set of Pick and native host programs that sit behind a non-Pick HTTP server allowing Pick applications to interact with a web user interface.

At first, it may appear that both Coyote and FlashConnect accomplish the same tasks.  This is true in general, but the manner in which these tasks are approached is very different.  Coyote is completely self contained.  With the exception of configuring IP addresses in the underlying host O/S, all Coyote functions run in Pick.  There are no external servers to purchase, configure, and maintain.  The opposite is true for FlashConnect.  FlashConnect runs as a slave application to an external web server by running as a CGI (Common Gateway Interface) application within the host operating system.  This implementation, while functional, is much more complicated than Coyote's Coyote web server and introduces operational limitations and severe performance penalties that Coyote simply does not need to concern itself with.

The Complexity of Setting up the Server Environment

The first distinction between Coyote's Coyote web server and FlashConnect is the complexity in installation.  With Coyote, you configure TCP/IP "listen" addresses and tell the web server where web content is located. Because Coyote is self contained, this is all that is required.

FlashConnect requires that you first configure the external web server. This process by itself is the equivalent of configuring Coyote without even touching the Pick environment.  After the external web server is running, you must then configure the CGI directory, compile and configure the interconnection API application.  Finally, you are ready to configure the Pick software including setting up the process pool, security parameters, and other issues that FlashConnect requires.  If you read Pick's FlashConnect documentation, more than half of it is devoted to configuring and installing FlashConnect.

How the Environment Impacts Performance

Pick's FlashConnect (and other vendors web integration packages) often imply that using an external web server provides a performance advantage. This is just not the case.  The performance of Coyote processing full HTTP transactions is actually faster than the performance of external web servers running CGI requests that do absolutely nothing (Microsoft benchmark showing 50 hits/second for CGI.  Machine is assumed to be a quad-proc Pentium PRO which is what Microsoft usually uses for benchmarks. Coyote clocks at over 50 active-page hits/second on a dual-proc P-200 running D3.).  It turns out that the true overhead of integrating Pick with the web is not interpreting the web's HTTP protocol at all. HTTP is actually a very simple, completely text based protocol that is very easy to process entirely in Pick code.  The real overhead is in creating an efficient mechanism to move data to and from the Pick process space. By doing all of the processing within Pick, Coyote just avoids this problem entirely.

Another approach that Pick Systems and other vendors uses to help web integration performance is to talk about "scalability".  This is achieved by running multiple systems, some with web servers and some with Pick data engines.  Again, Coyote makes these so-called solutions unnecessary by making the underlying engine as much as an order of magnitude more efficient.

The reasons that Pick's FlashConnect's performance is not optimal is because of the presence of independent layers operating in multiple environment. Instead of enhancing performance, these layers actually extract a performance penalty which can be significant.  Each layer has it's own processing overhead and each step of moving data from layer to layer only adds more CPU cycles and processing latencies.  The result is an approach that does function, but at a performance level that is far from optimal and that requires far more hardware to service a given level of requests.

If you want to look at how each of these layers takes their toll consider the process of handling a single web request.  The web server receives an HTTP request.  If must receive the request, parse the header fields, and then pass the data off to the CGI interface.  It is here that things start to slow down.  CGI, by it's very nature, requires that the web server create a new host process (or at least link to an existing process).  This is a quite slow task.  In Pick terms this would be the equivalent of logging a port on, running a program, and then logging the port off for each page access.  The overhead does not stop there. After the CGI process is started, Pick's FlashConnect transport application has to load, initialize, and open a TCP/IP connection to the D3 multiplexer application that is running either on the local machine or across the network.  Once this connection is open, data is transferred from the CGI application to Pick.  Once in Pick, the page hit is compared with a table of current "web applications" and the data is sent to the Pick process so that you application code can actually run.  Of course, once your code has generated some data for output, that data must flow along the same path to finally end up in the external web server and eventually get transmitted to the user's browser over the network connection.

If this convoluted path sounds complex and inefficient, it is. Pick Systems does not quote reproducible performance figures, but the number thrown around in their FlashConnect classes indicates that they fell comfortable with handling several hundred page requests per minute.  In web server terms 200 pages/minute is less than 4 hits/second which is really quite dismal.

If you are now thinking that FlashConnect's logic is somewhat contorted, you will be happy to learn that Coyote is amazingly simple and elegant. Instead of layer upon layer built outside of Pick, a pool of Pick phantom processes silently waits for TCP/IP connections, processes HTTP requests, and run your application code.  There are no host processes created on the fly as is the case with CGI and interprocess communication and latency are completely avoided.  The result is that Coyote can process active application page hits at over 50 pages/second or 3000 pages/minute. This is ten times the reported speed of FlashConnect.

Coyote D3 Performance Test Environment

Host PC running Windows NT Server
Hardware Dual Pentium 200 MMX
128 Megabyte of main memory
6.4 Gigabyte IDE disk drive
Fast Ethernet
D3 Version D3/NT version 7.1
Benchmark Application Sun Microsystems WebStone application running on Windows NT workstation
This benchmark system is far from the fastest D3 system you can build and is still capable of driving a full internet T-1 line to saturation from a single host.  Of course if you must have the buzzwords, Coyote is implemented as a fully event-driven, multi-threaded state machine that takes full advantage of your multi-processor hardware and fast disk drives. The important point to remember here is that simplicity leads to efficiency.

The Applications Programming Interface

It is in the applications programming interface where FlashConnect is most compelling.  In essence, FlashConnect allows you to write web applications in the top-down environment that terminal applications are accustomed to while using HTML forms as large PRINT and INPUT "pseudo statements". Your application program is running on a real port making subroutine calls to FlashConnect functions to build HTML pages on the fly and gather input from posted HTML forms.

Coyote builds a similar applications programming environment, but there are differences.  You still write programs top-down, but the execution environment and some of the rules vary.

Application Persistence

A common "problem" with web interfaces is maintaining application persistence. Persistence is a description of an application program "remembering" where it is.  With Pick programs, persistence consists of: Both Coyote and FlashConnect provide transparent support for web application persistence, although in different ways.  FlashConnect implements persistence by devoting a Pick process on a live user port to each web application.  This allows you to use normal Pick/BASIC programming structures.  Coyote does not dedicate a Pick process for each web application, so persistence is handled a little differently.  Coyote keeps track of program execution location and external subroutine return stacks plus the contents of those Pick variables that you define as persistent. If you are looking at only persistence, FlashConnect does an excellent job and perhaps a somewhat more complete job than Coyote.  There are costs for this level of persistence in terms of performance, scalability, and cost.  In either case, both Coyote and FlashConnect allow you to write standard Pick/BASIC web applications in a top-down structure without having to manually write code to implement persistence.

The Web Interface

The interface for a web application to communicate with a user is through HTML web pages.  The best way of viewing an HTML page in a web application is as a series of Pick/BASIC PRINT and INPUT statements.

With FlashConnect, you build the web page's HTML by first loading a "template" and by then merging your custom HTML code into that template. FlashConnect provides subroutine calls to "initialize" the template and then replace your strings into that template.  This mechanism is workable, but inefficient in several areas.  First, the mechanics of reading the template and then performing insertions is somewhat cumbersome with a lot of subroutine calls involved.  Second, it is your applications responsibility for maintaining HTML data formats including converting ASCII characters like < into the &lt; sequences that HTML expects. Finally, the process of building HTML input fields is also quite manual requiring a lot of Pick/BASIC source code to handle even simple program logic.  The result is a programming environment that does not meld the features of HTML very well with the features of Pick/BASIC.

Coyote also gives you the ability to generate web pages based on templates with your own data inserted.  Instead of requiring a long process to initialize the template and then making subroutine calls to replace your data, Coyote lets you directly include the Pick/BASIC insertion code directly into your HTML "template" pages.  This hybrid HTML/BASIC document makes the task of laying out dynamic HTML pages much easier. Building INPUT logic is also much easier.  With Coyote, you can create an HTML page with form <input ...> statements and simply declare the input statements with names that match the Pick/BASIC variables or dynamic array references that are to receive the data.

The end result is that Coyote lets your programmers do more real work and less busy work managing the web environment.  HTML documents are authored as HTML documents and Pick programs are authored as Pick programs. In fact, Coyote lets you use different personnel to author programs than you use to build HTML layouts.

Run-time Performance

There are two major areas where the run-time performance of the actual Pick application environment differ between FlashConnect and Coyote. The first has to do with process space.  Even though FlashConnect is very efficient at handling persistence by dedicating a Pick process to each web application, this can result is performance problems when the system is heavily loaded.  Just imaging a system running 500 or 5000 concurrent web "users" and having to log on 500 or 5000 Pick ports. This is exactly what FlashConnect must do to support this number of users. Coyote can support 500 or 5000 web "users" by maintaining a single file with 500 (or 5000) state items that represent your application's persistent variables, program execution location, and return stack.  This drastically lowers the overhead on the system when the web environment is heavily used.

The second area where Coyote is more efficient than FlashConnect is in how HTML documents are produced by merging templates with application variables.  FlashConnect approaches this task by performing a series of string searches and replaces with variable data.  Coyote takes a different approach.  Instead of searching strings for insertion points, Coyote is more like a code-generating 4GL.  For each HTML document, Coyote generates a running Pick/BASIC subroutine and insertion points are actually a part of the generated Pick/BASIC logic.  The result is that Coyote generates dynamic HTML pages faster than most hand-tuned programs could.

Deployment Costs

One of easiest areas to differentiate Coyote with FlashConnect is in the analysis of deployment cost or how much money you have to spend to support a given user community.  The FlashConnect environment requires a licensed Pick process for each web process.  If you need to support 100 web "users", FlashConnect would cost $36,000 to deploy assuming $1000 for the FlashConnect license and $350 each for Pick user licenses.  Of course, Pick says that you can run FlashConnect in "non persistent" mode, but then you lose all of the compelling features that make FlashConnect viable for top-down application development.  Even so, you still need to license a sizeable block of Pick ports.

The Coyote run-time environment is different.  Instead of using a dedicated Pick process for each web application, a small number of Pick phantom processes share the workload for all web users.  Because these processes are running on Pick phantom ports, they actually meter as zero Pick licensed users.  If you were to configure the same 100 user web application with Coyote, the cost would be $5995 total assuming a full T-1 bandwidth requirement for Coyote.  This is 83% less than the cost to deploy FlashConnect at 100 users and would actually support many more users at this bandwidth.  Here is an estimation of costs for a number of user sizes:

Users FlashConnect Coyote
10 $4,500 $2995 (fractional T-1)
100 $36,000 $5995 (full T-1)
200 $71,000 $5995 (full T-1)
500 $176,000 $10495 (multiple T-1s)
1000 $351,000 $10495 (multiple T-1s)
2000 $701,000 $14995 (multiple T-3s)
Of course, the underlying Pick application environment will run out of steam long before you hit the high-end of this chart.  I suspect that FlashConnect is not viable much over 100 users and Coyote will begin to saturate at somewhere over 500 users.  I also suspect that Pick Systems would gladly discount 500 user licenses well below $175K but I doubt they would reduce this by 80%+.

Using FlashConnect in a Public Web Site Environment

The FlashConnect costs associated with user licenses can make using FlashConnect in public web sites nearly impossible.  Not only do you have to pay for each user, but you must have a pre-allocated pool of licenses to run with.  If you are building a public web site, it can be impossible to predict just how many user licenses you will need.  With Coyote, you only need to buy a sufficient license to handle your internet connection bandwidth.  You still have to predict your bandwidth needs, but at least the software will act predictably regardless of your user load. This means that your public users will never get "no connection available" messages, but just that you connection will slow due to traffic saturation.

Scalability

A large part of Pick's product literature for FlashConnect involves being able to configure the system to be scalable.  The literature talks about a dizzying array of multiple web servers with multiple back-end D3 application host systems.  The idea here is to build an environment that is "scalable" and that can run from small to large applications. It is good that FlashConnect is scalable in this manner because a single system really does not perform all that well.  The problem with creating scalability in this manner is that you are creating a very complicated environment involving a lot of systems and associated points of failure.

Coyote deals with scalability with a more straight forward approach. For most users, their current Pick host system is more than adequate for deployment of web applications.  Remember that Coyote is as much as 10 times as efficient at processing web requests as FlashConnect. This means that nearly any current Pick host can drive an internet T-1 line to saturation without any additional effort.  This is adequate for the vast majority of Pick applications.  If you application is larger than this, you can still use traditional web scalability solutions including reverse proxy servers and parallel Pick hosts.  Just remember that these steps are usually not necessary for most application environments.

Conclusion

There are aspects of FlashConnect that I really like.  FlashConnect's application programming environment and implementation of application persistence is far superior than any of the other web integration products like Liberty Web Connect, RedBack, or other home-brew solutions that I have seen. The real problem with FlashConnect's persistence is that it requires not only dedicated Pick processes which are a real overhead on the host if you need a lot of them, but that these processes must be licensed as interactive users which is prohibitively expensive for public internet uses. And if you opt to not use the persistence model, you must also opt out of all of the features of FlashConnect that make its programming interface desirable. Of course, we think that Coyote offers all of the functionality of FlashConnect application persistence with an even easier to use programming model that seamlessly merges Pick/BASIC with HTML.  So even though FlashConnect's programming interface is what really makes it shine in comparison to other offerings, it still has a lot of room for improvement.

Otherwise, FlashConnect is best viewed as just another tool kit that lets external web servers call Pick.  Not that using an external web server is unworkable, it just adds several layers of complexity, overhead, and inefficiency that are best done without.  By bringing the entire HTTP engine into Pick, Coyote and Coyote end-run all of the complexity and performance bottlenecks by keeping all of the processing local to the Pick virtual machine.  The result is a single system that is fast, flexible, and performs as much as ten times faster than competing product offerings.

Comparitive Summary

FlashConnect Coyote Coyote
Web Server    
    Web Server Architechure Requires external HTTP server Integrated HTTP Server in Pick
    Server Logging and
    Control
External.  Beyond the reach of Pick applications Internal to Pick.  Easily controlled with Pick data files and applications.
    Supported web content As supported by the external web server User definable MIME content types including HTML, TXT, GIF, JPG, audio, Java, Javascript, archives, and others.
    Web content storage
    location
External to Pick in host directories. Either within Pick data files or in host directories.
Web Application Persistence    
    Variable persistence Automatic Requires definition.  No support for dimensioned arrays or file variables.  Both local and common variables are supported.
    Execution location and
    return stack
Yes Yes.  External and local subroutines are supported.
    Lock support Yes, with timeout semantics Yes, with timeout semantics
    Process usage High.  One licensed process for each web persistent state maintained. Very Low.  Two phantom Pick processes for each system CPU regardless of the number of persistent states maintained.  Zero Pick user licenses consumed.
Web HTML Generation    
    Support for standard
    HTML editors
Yes Yes
    HTML template location Pick files only Pick files or host accessible directories
    Data insertion points Fair.  Requires subroutine calls for each insertion point Excellent.  Pick/BASIC source code embedded at insertion point is directly executed.
    HTML data "quoting" Manual.  Application program must insure that HTML characters such as "<" are converted to quoted strings. Automatic
    HTML page creation
    performance
Poor.  Pages are create created interactively using string search and replace operations within external subroutines. Excellent.  Pages are created using on-demand generated code that eliminates string search and replace operations.
    Layout Programming
    Environment
Fair.  Lack of HTML/BASIC integration requires too much busy work in Pick/BASIC to manipulate HTML structures. Excellent.  Pick/BASIC source code at insertion points eliminates most formatting code from Pick source documents by moving them to the display layouts.
Web HTML FORM Processing    
    Input field layout Use any HTML editor Use any HTML editor
    Input field processing Poor.  Requires extra code to retrieve form values Seamless.  Automatic transfer of values to named Pick/BASIC variables or dynamic arrays.
    Input field formatting Poor.  Manual processing required for ICONV/OCONV. Automatic.  ICONV/OCONV processing specified as a part of the HTML page layout.
    Submit button processing Poor.  Requires manual code to retrieve form values Seamless.  Automatic setting of boolian value for submit button variables.
Performance    
    Active Page Hits/second 3-4 50+
Cost    
    100-user sample site $36,000 $5995
Portability    
    Supported platforms D3 only D3, mvBase, AP/Pro, Mentor PRO, Universe, Unidata, others
{INCLUDE _GEN_FTR.HTM}