http://www.perlmonks.org?node_id=999328


in reply to Re: Question on design for FastCGI
in thread Question on design for FastCGI

As I only have a beginning grasp of FastCGI, there are some concepts that I'm still grappling with.

Let's say I go with Approach 1 with the modules imported before the start of the loop. Then later in loop, one of the subroutines in say, Module2, is called. Am I right to say that because the code in Modole2 persists between responses, calling the subroutine is faster than if it were plain CGI?

Replies are listed 'Best First'.
Re^3: Question on design for FastCGI
by Anonymous Monk on Oct 17, 2012 at 00:48 UTC

    Am I right to say that because the code in Modole2 persists between responses, calling the subroutine is faster than if it were plain CGI?

    Yes, its faster because the module is already loaded and ready to run, no time needs to be spent on loading it

    CGI starts a new process for each HTTP request, so program/modules/loaded, then program ended, memory freed

    This takes time. Compilation takes time, finding the modules, loading the modules, allocating memory ... freeing memory all take time.

    So for 1000 requests CGI takes , if it takes 1 second for program/modules to load/unload, and 1 second to run, that is half the time spent just loading/unloading the program, 2000 seconds total

    To a user of your website, this translates to a slow website. It doesn't matter if you and your users have super fast internet connections, if you're running a load balancing proxy... if your HTML is optimized to render quickly and your program is super fast, its always going to take at least 1 extra second for every single request

    With FastCGI, its 1001 seconds, 1000 seconds for 1000 HTTP requests, and 1 second to load the program/modules once

    To put another way, boy/girl-scouts/pioneers are taught not to walk with their knives or leave them laying around but to stow-away their knives (back into the sheath) when they're not cutting -- basically like CGI -- great for safety , acceptable when responsiveness isn't a priority

    But this wouldn't work for a chef, it would be way to slow. Which is why a chef has a work-space with a chopping block to leave his knife -- knife comes out of the sheath at start of day, and only goes back into sheath at the end of the day -- this is FastCGI

[reply]

      Thanks for the clear explanation.

      FastCGI is harder than I had imagined at this point. I supposed I'm too accustomed to how non-persistent code works. Now, when I try to recode parts of the site to use FastCGI, I keep running into problems. For instance, with plain CGI + sessions, after a user logs out and tries to access a logged in page, my old plain CGI code works against it, so he's prevented from being logged in.

      When I try to change that bit to use FastCGI, I discovered that by accessing a previously logged-in page after having logged out, a user can become logged in again - found out that it was probably due to the session being restored or something.

      I've this nagging question and hope you can help enlighten me. Suppose I've some variables that hold different values depending on who's logged in e.g. no of points in a game. Am I right to say I should not set variables like this before the FastCGI loop, but to get their values for each response within the loop? Because if - what I think is happening - I set them before the loop, their values are retained due to the persistence and so different users may see the same values - or something to that effect. How do I prevent bugs like this from happening?

[reply]
[reply]

In Section Seekers of Perl Wisdom