http://www.webpagetest.org/result/100727_1XAK/
The above test shows as keep alive not enabled. But as far as I am aware it is. Here is my header out put from firebug
Keep-Alive timeout=4, max=100
Connection Keep-Alive
I have looked through regarding the IE specific settings for turning off keep alive but this is only set within the ssl vhosts and not in any of the main apache config files.
Is there something else I am missing to get keep alives to show as enabled?
Cheers
Nothing in a rogue .htaccess file?
Here are the headers from the test: WebPageTest Test - WebPageTest Details
Connection: close
If you’re getting proper keep-alives in Firefox then there has to be a BrowserMatch setting somewhere in the configs that is breaking stuff. What does the BrowserMatch in the ssl vhost look like? It might be worth narrowing it if it covers ALL IE browsers and only have it apply for IE5 and below to see if that rule is getting hit for some reason (or just remove it temporarily to test).
Hi
Thanks for getting back to me I read through some of the other forum posts regarding this ie issue and amended the ssl vhost to be the following
BrowserMatch “.MSIE [1-5].”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
BrowserMatch “.MSIE [6-9].”
ssl-unclean-shutdown
I have fgrep’d through the apache config files for nokeepalive and found that it had been configured here
./conf.d/compress.conf: SetEnvIf User-Agent “.MSIE.” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
I have amended this now and will retest.
thanks[hr]
Hi
just retested and now get an A for Keep Alives.
cheers
Shaun
Sorry, I read in your article that it is. But how is it implemented? As far as I know separate process or thread is created for each connection. If so, than only one request at a time can be processed.
Or separate process (thread) is created for each request? If so, that there should be some clever techniques to avoid data mixing.
Sorry, I read in your article that it is. But how is it implemented? As far as I know separate process or thread is created for each connection. If so, than only one request at a time can be processed.
Or separate process (thread) is created for each request? If so, that there should be some clever techniques to avoid data mixing.
Sorry, I read in your article that it is. But how is it implemented? As far as I know separate process or thread is created for each connection. If so, than only one request at a time can be processed.
Or separate process (thread) is created for each request? If so, that there should be some clever techniques to avoid data mixing.
I have an Red Hat Apache server that seems to be stuck with Keep-Alive off…even though I’ve gone through this forum and made several changes that solved most similar issues. Here is the site on the server I am using to test:
I’ve made the following changes–note that I didn’t see anything in this site’s .htaccess or celiac.conf files:
I found lines in ssl.conf like this:
#SetEnvIf User-Agent “.MSIE.” \
and changed them to this:
SetEnvIf User-Agent “.MSIE [1-5].”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
SetEnvIf User-Agent “.MSIE [6-99].”
ssl-unclean-shutdown
In httpd.conf I commented out a line like this:
#BrowserMatch “MSIE 4.0b2;” nokeepalive downgrade-1.0 force-response-1.0
and added these:
BrowserMatch “.MSIE [1-5].” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch “.MSIE [6-99].” ssl-unclean-shutdown
I did NOT try this route, as I thought the above should work:
http://www.alexmeyer.com/linux/apachekeepalive.html
Any help you could offer would be greatly appreciated, and I thank you in advance to your help.
If you comment it all out does that fix things? A little trial and error should get you to the specific config that is causing the issues.
Do you use https anywhere on your site? If not, just leave all of them commented out.
Yes, I do use https so need that to continue working…and I’ve not commented them out yet. I’ll give that a try and report back. Would commenting these out for a few minutes be something that you would do during the day on a busy site with an https shopping cart? Sorry, but I just don’t really know what the negative impact could be on an end user…[hr]
PS - would you happen to know the exact ‘grep’ commands needed to track down other hidden sources of BrowserMatch or SetEnvIf User-Agent in my system…or do you think I’ve already mentioned the most probable places to look?
Yeah, I wouldn’t do it live during the day (actually, I probably wouldn’t make ANY changes that required reloading the configs but I’m paranoid).
Did you try grepping for force-response and downgrade?
Is there a load balancer or reverse proxy in front of the Apache that could be getting in the way?
And just a sanity check, do you have “KeepAlive On” and “KeepAliveTimeout X” (where X is some number of seconds) somewhere in your config?
For my own sanity, as I am really a server amateur (even though I’ve been managing this on my own for about 7 years), can I assume a restart of apache is all that is needed to make these config changes go live?
I don’t know the exact grep commands for force-response and downgrade…would you be able to post them here for me (sorry!)?
Load balancer or reverse proxy…I am not sure about this. What would be the best way to determine this?
As for the config setting they are:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
Try this:
grep -Rn 'force-response\|downgrade' *Just be careful not to do it in a huge directory tree because it will recursively scan all sub-directories too (/etc/apache2/ would be a good place to do it if that is where your apache configs are).
An apache restart will take care of it but if you mess up the config apache won’t start so your server will be down until you fix whatever is wrong in the configs.
As far as load balancer goes, usually if you’re not sure then there isn’t one in place. Did you initially configure the server or did someone else do it? If it is a single server (or VPS), apache is listening on port 80 for your website and the server IP is the same as the IP address for your site then it’s pretty safe to say there isn’t one.
Looking at the response headers, it looks like IE is being degraded to 1.0: http://www.webpagetest.org/result/111206_6F_2DRQ5/1/details/#request2 but Chrome is not: http://www.webpagetest.org/result/111206_Y8_2DRRC/1/details/#request2 so I think you’re on the right track with the browser match rules, you just need to find the one that is actually being used.
As for my server, I did not configure it, it was a package offered by OLM. It is my understanding that it is a standalone server that I control, but is set up with it’s own separate IP, and all sites on it can be set up to be either name based or IP based through the Ensim Pro control panel. The site in question is an IP-based site that listens on port 80, but again, the server itself has its own IP.
Below are the results from the grep (I also included those that are commented out):
conf/httpd.conf:889:#BrowserMatch “MSIE 4.0b2;” nokeepalive downgrade-1.0 force-response-1.0
conf/httpd.conf:890:BrowserMatch “RealPlayer 4.0” force-response-1.0
conf/httpd.conf:891:BrowserMatch “Java/1.0” force-response-1.0
conf/httpd.conf:892:BrowserMatch “JDK/1.0” force-response-1.0
conf/httpd.conf:893:BrowserMatch “.MSIE [1-5].” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
conf/httpd.conf.bak:889:BrowserMatch “MSIE 4.0b2;” nokeepalive downgrade-1.0 force-response-1.0
conf/httpd.conf.bak:890:BrowserMatch “RealPlayer 4.0” force-response-1.0
conf/httpd.conf.bak:891:BrowserMatch “Java/1.0” force-response-1.0
conf/httpd.conf.bak:892:BrowserMatch “JDK/1.0” force-response-1.0
conf.d/ssl.conf:216:# their broken HTTP/1.1 implementation. Use variables “downgrade-1.0” and
conf.d/ssl.conf:217:# “force-response-1.0” for this.
conf.d/ssl.conf:220:# downgrade-1.0 force-response-1.0
conf.d/ssl.conf:224: downgrade-1.0 force-response-1.0
grep: logs/fpcgisock: No such device or address
Binary file modules/libphp5.so matches
grep: warning: modules/modules: recursive directory loop
grep: run/saslauthd/mux: No such device or address
grep: run/acpid.socket: No such device or address
grep: warning: run/run: recursive directory loop
grep: run/proftpd/proftpd.sock: No such device or address
grep: run/dbus/system_bus_socket: No such device or address
grep: run/cups/cups.sock: No such device or address
I’d revert your httpd.conf back to:
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0That is the official version of it from Apache that targets JUST the broken version of MSIE and it is safe to do (even better would be to remove it entirely because you will never see IE 4 beta 2 in the wild).
I assume the only other match which is in ssl.conf is the entry you put in there and is the SetEnvIf matching. From reading here: http://blogs.msdn.com/b/ieinternals/archive/2011/03/26/https-and-connection-close-is-your-apache-modssl-server-configuration-set-to-slow.aspx I’d recommend removing that entirely as well unless you feel really dtrongly about supporting pre-IE6 IE browsers (and if so I assume a LOT of other stuff on your site would be broken).
FYI: In the is file conf.d/ssl.conf here is what I did, but obviously it still isn’t correct:
#SetEnvIf User-Agent “.MSIE.” \
SetEnvIf User-Agent “.MSIE [1-5].”
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
SetEnvIf User-Agent “.MSIE [6-99].”
ssl-unclean-shutdown[hr]
ok…I just read your comments and I’ve been operating on the premise that the older code in my config files is outdated, and it needs to be updated to newer, better code, rather than deleted. If it is fine to just remove all this I could do that instead. So should I just comment out any lines that have to do with downgrading the browser response…all those found by my grep? I am assuming that I won’t see any drastic, unintended consequences by doing that…[hr]
To make sure I don’t do something bad…should I just comment out all lines in config?
BrowserMatch “Mozilla/2” nokeepalive
#BrowserMatch “MSIE 4.0b2;” nokeepalive Bdowngrade-1.0 force-response-1.0
BrowserMatch “RealPlayer 4.0” force-response-1.0
BrowserMatch “Java/1.0” force-response-1.0
BrowserMatch “JDK/1.0” force-response-1.0
BrowserMatch “.MSIE [1-5].” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch “.MSIE [6-99].” ssl-unclean-shutdown[hr]
I tried commenting out all lines in ssl.conf and httpd.conf and am still failing:
http://www.webpagetest.org/result/111206_54_2DT6D/
Yes, I would comment them all out. I can’t imagine that you support browsers where it still matters (if there are even any users still on IE 4/5). That will clean up your config as well.
Did you restart the apache after commenting it out?
If so and you are still having problems then there has to be another one hiding somewhere. Is it possible that your apache instance is actually loading it’s settings from somewhere else?
According to OLM, there is not another instance of apache running on my server. Perhaps I can grep the entire server tonight for “downgrade”? Should I grep for other terms as well? Any ideas?
[hr]
Oh…I did restart apache after, and did comment out everything. [hr]
Last–Do you think a server restart might do the trick?
A server restart shouldn’t make a difference assuming the apache restart is actually working. I’d grep the whole machine for both strings just to be safe.
I haven’t greped the entire machine yet, but did discover new instances of this:
SetEnvIf User-Agent “.MSIE.” nokeepalive ssl-unclean-shutdown
in each site file in this directory:
/etc/httpd/conf/virtual/
I commented them out for each site file on the server, restarted Apache and then later the entire server, yet I am still failing…this is strange indeed. I will try greping the machine next.
With the help of an admin at my hosting company we finally figured this out…we found this Apache configuration file: httpd20_app.conf
and commented out this line:
#SetEnvIf User-Agent “.MSIE.” force-no-vary
and I now get an “A” on the keepalive test.
Now to solve my first byte issue…I can’t get past a C. Any ideas?