Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^4: apache/perl caching problem

by ksublondie (Friar)
on May 01, 2010 at 16:43 UTC ( [id://837942]=note: print w/replies, xml ) Need Help??


in reply to Re^3: apache/perl caching problem
in thread apache/perl caching problem

It looks like mod_perl is installed...When reloading apache, I see:
"Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny8 with Suhosin +-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0 confi +gured -- resuming normal operations"
in the logs.

Of course I know nothing about mod_perl and very little about how the server is configured. I've inherited the server from a previous co-worker.

I'm going to try to do a little research on mod_perl, but in the meantime, is there anything I should look for if this is the problem? i.e. configuration?

Replies are listed 'Best First'.
Re^5: apache/perl caching problem
by ig (Vicar) on May 02, 2010 at 19:28 UTC

    Mod_perl improves performance by loading the perl interpreter and your program once and then keeping these in memory and using them to respond to several requests. Configuration parameters determine how many requests each process or thread handles.

    If your server has a pool of processes/threads handling requests, each started at a different time, then each might have a different version of your program loaded. When a new request arrives at the server, it will be passed to one of the available processes/threads. If the server is busy, which process/thread handles the next request will be quite random. Thus, it will sometimes be handled by a process/thread running a recent version of your program and sometimes by one running an old version.

    If you stop the server, all processes/threads will be stopped. When you restart it, all new processes/threads will load the then current version of your program. Thus a full shut down and restart of the apache server should solve your problem.

    If your users can't tolerate the service disruption, then you can do a "graceful" restart. This allows current processes/threads to finish handling their current requests but then they stop and new processes/threads are started and these will load the current version of your program.

      I restarted the server and it doesn't look like it solved the problem. :-( I'm assuming then, that this is not related to mod_perl. Correct?

      "...Is your script a standard CGI script?..."

      Umm, as opposed to...??? Yes, I'm using CGI if that was your question. I'm sorry, I'm afraid you're a little over my head here. Everything I've learned about perl was on my own and doesn't extend much farther than coding and installing modules.

      "...You might verify this by having your script log its start time, process ID, version and the full path and modification time of the file loaded. Log this every time your script handles a request..."

      Is this different than the access logs? I was able to find an apache .pid file, but that simply contains the number "3067" and isn't changing.

      I'm checking out CGI::Log and CGI::LogCarp. Is something like that what you were referring to? Sorry if this is a stupid question: if I modify my code to include logging and I have a problem with my code caching, how would I be able to log my old script that doesn't log but is still in the cache?

      I don't know if this is helpful information, but I've been working on this site for well over a year. The problem started slowly at first. Gradually over time, this has been increasing. Now, I'm getting more of my old script versions than of the current versions. This site is the intranet and internal home page of my company of approximately 180 employees, so it gets a lot of hits throughout the day.

        If you have stopped and restarted your apache server and are still receiving responses from old versions of your script, then the problem is not a simple case of mod_perl holding old versions in memory.

        By "standard CGI script" I mean a script that is read from disk and executed once for each request. An implication (or perhaps I should say assumption of mine) is that a perl interpreter is started for each request. This is in distinction to a script running in the context of mod_perl, FastCGI or some other context which transforms or encapsulates it in a persistent process that handles several requests before terminating.

        For "quick and dirty" logging (i.e. to be removed when debugging is done, as opposed to logging that is to become a permanent part of the scripts) I usually print to STDERR. Output to STDERR should show up in your sites error log. This allows you to see information that is not available in the access logs.

        You could use CGI::Log or CGI::LogCarp.How you get information into the logs is less important than what information is recorded there.

        You are correct that adding logging to new versions of your script will not change older versions. None the less, it would be good to add some logging. Your current versions will soon become old versions. You might produce a few versions that differ only in the version numbers they log, just to make some versions with enhanced logging into old versions.

        The HTTP protocol is one of request and response. The browser sends a request and the server sends a response. While the requests and responses can be complex, the relationship between them is usually very simple: one request receives one response.

        You have "bad" responses being received at the browser. The challenge is to determine where these "bad" responses are coming from and why they are being produced. The first step is to determine where they are coming from. Keep focused on this simple aspect of the situation and avoid being distracted by the complexities.

        When your browser sends a request, where does it go? Does it get to your server? You may find that some of the requests are not going to the server you think they are going to: some other server may be responding.

        Server logs and network sniffers can be very helpful, along with your understanding of the HTTP protocol and careful attention to the details of what is happening. It can be painstaking work but ultimately isn't very difficult if you have access to the systems and understand the fundamentals.

        If there is someone there more familiar with the infrastructure (network, proxy servers, web servers, etc.) I would review the symptoms with them.

        It is possible that your infrastructure includes a "transparent" proxy server. This is a proxy server that intercepts and potentially modifies communications that aren't explicitly directed to it. In some cases, they provide a response to the client that appears to have been sent by the server when in fact the proxy server has blocked the communication with the server and produced the response itself. They can include caches, so the response they provide might be from an old version of your script. But they would typically be dealing only with the HTTP requests and responses and would not be able to execute an old version of your script with new query parameters (if such is relevant to your script).

        If there is a transparent proxy server in your environment, your infrastructure folks should be able to tell you about it, but sometimes such devices are installed without being well understood or the person who knew what it was doing leaves while it carries on. You can detect a transparent proxy by careful comparison of what happens at the browser with what happens at the server. In the absence of proxy servers (transparent or otherwise) there should be a one-to-one correspondence of requests and responses at both ends and neither requests not responses should be modified in transit.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://837942]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2024-03-28 10:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found