QuickStart Development

Richard Kreiss rkreiss at verizon.net
Fri Jun 10 13:49:54 PDT 2016


Now to make things clear, I used quickstart since it came available.

Mark is probably correct that network latency has a greater effect on one's
perception of an internet connection. 

The other side of the coin is an application like I have had to create which
uses records in one file to create a report run from a system command which
passes variables to a -v select process.  This output is now up to
generating 300 separate pdf files.  This would require 300 compiles of
dreport where report requires none.  And yes, the client has more than
adequate hardware to throw at this process.

I think that the environment that filePro runs in may also be an issue.
FilePro on a *nix system runs more efficiently (read faster) then on a
Windows system. I think the only way filePro would run comparatively would
be when using RDP to directly the server, unless of course a fiber network
has been installed.

The Windows environment is more costly when it comes to servers as one need
to have more horsepower running it.  Windows is still a memory hog and does
run more efficiently the more memory one uses especially if one is
configuring a RDP server.  On a single computer, 16GB is really the most one
would need. (Gamers may want more).  My client's really only need systems
with 2Gb of RAM but are purchasing 4Gb machines.  One or two of the
employees may be running application which can use that or more memory.

An aside:

I have installed some small SSD's drives at some client sites and set pftmp
to use a directory(folder) on that drive.  It does help performance a bit.
This is like creating a ram disk on a Xenix machine.  In this case, a task
runs on the weekend to delete all of the files that may be left there.  

Richard Kreiss
GCC Consulting


> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Kenneth
Brody
> via Filepro-list
> Sent: Thursday, June 9, 2016 5:01 PM
> To: Brian K. White <brian at aljex.com>; filepro-list at lists.celestial.com
> Subject: Re: QuickStart Development
> 
> On 6/9/2016 4:14 PM, Brian K. White via Filepro-list wrote:
> > On 6/6/2016 1:02 PM, Kenneth Brody via Filepro-list wrote:
> >
> >> It used to make a huge difference in startup speed for large
> >> processing tables.  (For example, the Medical Office System would
> >> take several minutes to start on a Tandy 6000, and only several
> >> seconds with
> >> Quikstart.)  Not so much any more.  The main difference nowadays is
> >> protecting your source code, as you do not need to distribute it to
> >> your clients.
> >
> > But wouldn't that same % difference in efficiency still hold exactly
> > as true, if the table were called a thousand times in a cgi environment?
> >
> > If you have a machine that can do 500 X's per second, then it still
> > holds that the same machine can do 5000 X/10's per second.
> >
> > It still matters, one would think. Or at least in use cases that
> > involve more than a few users.
> 
> While the total time saved in rcabe-vs-dcabe might be significant in such
a
> scenario, the percent of time saved would probably not be that
significant.
> Consider the fact that the amount of time to compile the processing versus
the
> entire time of running the process has shrunk.
> 
> (In my example of the MOS, it was simply starting dclerk versus rclerk.)
> 
> If the CGI environment runs *report thousands of times, what percent of
that
> time is dreport compiling the processing, versus the startup, run, and
shutdown
> of the program?
> 
> If you can save 10 milliseconds needed to compile the processing, and run
it
> 10,000 times, yes you have saved 100 seconds.  But how long did it take in
total
> to run those 10,000 CGI requests?
> 
> --
> Kenneth Brody
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list



More information about the Filepro-list mailing list