Hi, I have no idea whether this could help but I had trouble with CGI in the past because of headers being renamed or rewritten.
An RFC sample: The header data may be presented as sent by the client, or may be rewritten in ways which do not change its semantics. If multiple headers with the same field-name are received then they must be rewritten as a single header having the same semantics. http://tools.ietf.org/html/draft-robinson-www-interface-00 So basically, I had trouble with headers not being seen because they were renamed, and thus ignored by the application which changed its behavior. Best Regards, Dridi On Wed, Feb 27, 2013 at 8:51 AM, Daniel Schledermann <[email protected]> wrote: > Den 27-02-2013 01:52, Stephen Strickland skrev: > > When I was using mpm-preform varnish worked great with a high hit rate, but > the server kept getting oom errors. > > > Yes, mpm_prefork can be pretty memory intensive with modern CMS'es. > > > > > From: nick tailor [mailto:[email protected]] > Sent: Tuesday, February 26, 2013 7:50 PM > To: Mark Strickland > Cc: [email protected] > Subject: Re: Varnish with mod prefork vs mpm worker with mod-fcgid > > > > I have heard of others having similar issue with same setup. > > > > Generally they use mpm-prefork or mod fcgi with varnish. I have heard using > Nginx with varnish is the way to go. > > > > What I would do, is disable modfcgi and see if it changes. If it does you > know the problems lies in the settings. > > > > > > It sounds like you should sanitize the output headers from Apache. You might > have a high number of hit_for_pass. That is the only reasonable way that the > low level server setup should be able to influence caching performance. > > But a better advide might be to use both Apache with mpm_prefork and NGINX > on the site. Configure varnish to split the traffic and use NGINX for static > files and Apache mpm_prefork for PHP requests only. That way you can > configure the prefork with real conservative settings to only have a limited > number of apache-processes, and maybe set MaxRequestsPerChild to avoid > excessive ballooning of PHP memory. The majority of the request will go to > NGINX, which do not use much memory in any case. That way you can keep > maximum compatibility with PHP-code and at the same time avoid oom problems. > > _______________________________________________ > varnish-misc mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc _______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
