From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:e7e1pVWxKHA.948(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>>
>> I can't take the several minutes of CGI process spawn
>> time for my application, (it has to load gigabytes of
>> data into memory before it begins) thus conventional CGI
>> is infeasible.
>
>
> Peter, FASTCGI vs CGI, the different is in load time. In
> the past, that was an ISSUE, not today. You won't be
> saving any time whatsoever with FASTCGI.

<sarcasm>
Ah so I can load 4 GB of data from disk in less than a
millisecond, great then I will go with regular CGI.
</sarcasm>

Each transaction will only take a few milliseconds iff (if
and only if) the 4 GB DFA is already loaded into memory. If
I have to load it every time, then each transaction will
take infeasibly long.

>
> If your transaction residence time is over 20-30 seconds,
> you got other problems with HTTP uploads - i.e. browser
> uploads.
>
> You will need a special client to support a keep alive
> concept otherwise the browser will think something happen.
>
> You would also be do this via AJAX (jQuery with FORMS
> pluggin) and work in a "progress bar" but unless you
> Ping/Poll hit the server, you have will timeout issues.
>
> --
> HLS


From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:O$zu$VWxKHA.948(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>
>> FastCGI is portable across platforms, and most often
>> faster than alternatives.
>
> You are trusting the WIKI's too much.
>
> --
> HLS

Not just Wikis, I have examined at least one book from
Amazon too. All That I need is a minimal cost way to keep my
4.0 GB of data loaded into memory. FastCGI is based on
Sockets.


From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:O$zu$VWxKHA.948(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>
>> FastCGI is portable across platforms, and most often
>> faster than alternatives.
>
> You are trusting the WIKI's too much.
>
> --
> HLS

There are also several very successful commercial products
that are based on FastCGI.


From: Hector Santos on
Peter Olcott wrote:


> Fastest speed is highest priority, secondary to this is
> portability, it looks like FastCGI provides both. Another
> very high priority is minimal development costs. As far as I
> can tell FastCGI is good here too.

Dude, FastCGI is not a "Language." Its an idea, a methodology that
was designed with EARLY needs to speed up loading time. You won't
have that problem today. Its nonsense to think this is "answer" to
your problem. In addition, if you worry about processing speed,
native C/C++ is your choice, so all you are doing is writing a CGI
application, a console application that reads standard input.

If you want productivity, learn PHP. Simple, well supported. Then if
you really find out that FASTCGI is needed for your slow OS and
machine, PHP supports it.

The point is your SOLUTION is not FASTCGI, it is the actual
application that does the work.

--
HLS
From: Peter Olcott on

"Liviu" <lab2k1(a)gmail.c0m> wrote in message
news:uJsQOVWxKHA.5036(a)TK2MSFTNGP02.phx.gbl...
>
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote...
>>
>> I can't take the several minutes of CGI process spawn
>> time for
>> my application, (it has to load gigabytes of data into
>> memory
>> before it begins) thus conventional CGI is infeasible.
>
> And you expect that to work on a "dedicated Linux server
> with 3.0 Ghz
> and 2.0 GB RAM, $56.00 per month a GoDaddy.com" exactly
> how?
>
> With all due respect, but after reading some of your
> recent posts,
> including naive confusion on how to manage the lifetime of
> GDI
> objects in a DC... I would honestly advise that you team
> up with
> someone more versed in those pesky implementation details
> (and
> before you wonder, no, I wouldn't ever apply). Assuming
> you _had_
> a glorious idea, better share the glory than run it into
> oblivion alone.
>
> Just my 2c,
> Liviu
>
>
>

Oh yeah apparently Microsoft lied, that made finding the
correct answer about the lifetime of GDI objects a little
more tricky. Also although it may be common knowledge that
a CBitmap object has a default value of a single black
monchrome pixel, this common knowledge is no longer in the
textbooks.