This document shows you how to go from "fast and flexible" to "blinding speed" , all depending on your needs for Rapid Application Development or for execution speed or somewhere in the middle.  Whatever your needs, they can be met with RoAccess.  What you will find is that you have a wide range of options with RoAccess.

No computer systems today seem to run as fast as we would like.  On reason is that software today is becoming increasingly complex, which means a large amount of code and execution time is spent to support the greatly expanded functionality.   Also, since today's WEB applications tend to overlap as many operations in parallel to improve throughput, typical stress monitoring tests have a difficult time comparing CPU activity with fastest end user response time, which are at odds with each other. 

Another is that computing is becoming more and more distributed, where a single task may actual invoke a series of processes, some on different machines, each quite complex in themselves.  A third is that machines are being used as servers and multiple people are sharing this resource.  Even if you have a fast system today, as the software becomes more sophisticated, larger in memory and execution time also more users will be competing for these resources, and the system will get slower and slower.  Remember when a 80286 IBM AT was considered really fast and could address a lot of memory?  If you tried to run windows applications on it, response time would be unacceptable.  The problem was solved with memory and speed and overlapped processing.

Performance techniques differ from platform to platform.  Even different Unix machines will have different best performance approaches.  But there is a tradeoff between performance and programming flexibility.  What is most convenient for program developers is most probably not the fastest for users. 

There are a couple of areas that may lend themselves to study to determine what enhancement strategy is the best for you.  There are several areas that should be investigated: 
 

Perl compile time can be determined by taking your application, using ppp.pl to make a monolithic file, and put a print "hello world\n"; at the end.  You might have to delete a line or two at the top to make sure nothing other than your line is outside subroutines so those lines won't get executed.  Then merely run the application.  On Unix, the command would be "application.pl".  On Windows 95/NT, the command would be "perl application.pl".  Measure the compile times. 

To run a large test perl file, with 3500 lines, it took 0.2 seconds on a 200 Mhz UltraSPARC and 0.05 seconds on a 600 Mhz Pentium III.  From a performance point here, there is a big difference based on processor speed.

A RoAccess perl application can be automatically converted into an executable.  This means there is fast load time and not time is spend on compiling the perl.  The "perl2exe" utility is free on the WEB.

Perl is the most widely used WEB scripting language in use today.  Because of that, there is a Perl-to-C compiler.  It reads your perl application and generates a true executable.  We can generate them for you if we have access to your CPU type, or you can generate them yourselves by installing the publicly available "perl2c".  This way, you can customize RoAccess or create your own applications and turn them into executables.  It performs best if your input to perl2c is the monolithic version of your application.  Otherwise, the perl filel you compile will be pre-compiled, but any other common libraries included at run-time will have to be compiled, and the advantage will be lost.  The monolithic file has everything, almost, in one file, so all your application will be pre-compiled.  The "almost" means that the configuration files, like AConfig.pl and rochade.ini are not pre-compiled into the applications because they may change, and you would have to re-generate the executables. 

We have noticed that perl compile times vary widely on different platform for no obvious reasons.  To help reduce the compile times, perl2c compiles the program in advance.  So, if your platform happens to have long perl compile times, the compile step can be completely by-passed, and the overall execution time reduced accordingly. 

On Unix is extremely fast because of the fast executable load and the perl program is already pre-compiled.  From our experiences, RoAccess applications execute in the same amount of time. 

A downside is each executable takes disk space considerable larger then the smaller perl files. 
 
 

 Since some machines take "longer" to compile perl than others, we developed a "perl server" which keeps a number of applications pre-compiled and sitting in memory waiting to be executed.  In one test we ran where an application took 3 seconds to compile and .4 seconds to run, the entire execution took only .45 seconds!  This shaved off about 3 seconds off the overall response time.  So, if your system takes a "long" time to compile a perl script, this enhancement may be of value. 

We have placed the description of the RoBridge server in another document. Click here to view it.

RoAccess communicates with the Rochade server via the "Rochade client". 

Normally, each query starts the rochade client, and when finished, the Rochade client exits.

With the Constant Connect Server, a single Rochade client is started and keeps a pre-opened connection to the Rochade server.  All Rochade accesses go through that one Rochade client, in a serialized fashion.  You can have 100 simultaneous WEB  accesses, and all the Rochade accesses are serialized.

This situation is useful in several situations.  If your system is tight on memory or process slots (operating system parameter), this uses fewer processes.  Since the Rochade client is already loaded and connected, this eliminates this time, because no process startup time or Repository connect time is necessary.

It is also useful if you wish to reduce the number for Rochade Client Licenses you need to support all your users.  A Constant Connect Server utilizes only one license, so everyone in your organization can use the 1 license.  This is a big cost savings if you want to save money and you wish your number of Rochade users to increase dramatically over time.