Emilio,

 Thanks! I tried your suggestion and restarted pound. Unfortunately, the
change had no effect.

 Before I turned off logging I was getting messages in my syslog saying:

 Apr 30 06:24:50 DNS pound: (b7b3fb90) connect_nb: error after getsockopt:
Connection refused

Currently I have two IPs setup for the website in a failover situation. If
you pump either of the IPs into a browser and try to load the site that
way, the site comes right up. No delay. But when you try to resolve the
name via DNS it takes forever to load.

 And as mentioned, this problem completely goes away when you take pound
out of the equation.

 

On Thu, 30 Apr 2009 13:53:42 +0200, Emilio Campos
<emilio.campos.martin(at)gmail.com> wrote:[...]
number[...]
the[...][...]
when[...]
loads[...]
terrible.[...][...]
[...]

Hi Tim,

I'm not sure if it's a mistake or not, but Service sections should
really be inside ListenHTTP or ListenHTTPS directives.

You may also want to change your 'Alive' value to something like '10' or
'15'. 2 seconds is a bit too short an interval, IMO.

Regards

John

On Thu, 2009-04-30 at 11:42 +0100, Tim Dunphy wrote:[...]

Nathan,

 Thank you for your input. Let me just mention that this is an alpha site
set to debut on May 15. As far as I know there is no real traffic going to
the site as of yet. Do you still think after hearing this that it could be
a connection limit issue? If so I will try your suggestion.

On Thu, 30 Apr 2009 05:03:49 -0700, Nathan Schmidt <nathan(at)pbwiki.com>
wrote:[...]
/etc/pound.cfg)[...][...]
pound[...]
two.[...]
up.[...][...]
[...]

Tim, can you resolve without problems with your dns in the host? i think
this is not a pound problem. DNS or route  configuration problem? you can
put in /etc/hosts the virtualhost and ip resolution and try for example

this is a dummy try but; can you try to connect via telnet from pound server
to web servers and see if you can connect to port,  and server  return the
web?

A lot of kiss for everybody :P

2009/4/30 Tim Dunphy <bluethundr(at)nylsd.com>
[...]

Emilio,

 Thank you. This is the result of telnet:

telnet> open 192.168.1.6
Trying 192.168.1.6...
telnet: Unable to connect to remote host: Connection refused
telnet> open web2
telnet: could not resolve web2/telnet: Name or service not known

It should be noted that internal DNS is _mostly_ configured properly. You
can ssh from box to box to box using the dns name and you don't have to use
the ip address once you are on the network. 

However, this is what I get when I try to ssh from the dns box itself:

bluethundr(at)DNS:~/Pound-2.4.4$ ssh web2
ssh: Could not resolve hostname web2: Name or service not known

yet ssh to ip works from dns:

bluethundr(at)DNS:~/Pound-2.4.4$ ssh 192.168.1.6
bluethundr(at)192.168.1.6's password: 


Could this be causing the slowness? Also it was suggested that I recompile
pound against PCRE....

thanks!




On Thu, 30 Apr 2009 15:28:01 +0200, Emilio Campos
<emilio.campos.martin(at)gmail.com> wrote:[...]
the[...][...][...]
[...]

Thanks, John! I will give that a try...

On Thu, 30 Apr 2009 13:00:44 +0100, John Snowdon
<J.P.Snowdon(at)newcastle.ac.uk> wrote:[...][...]
when[...]
loads[...]
terrible.[...][...]
[...]

John Snowdon wrote:[...]

Actually that's not a mistake.  Global service directives, i.e. ones 
outside of ListenHTTP/HTTPS directives work fine.  I use a lot of them.

[...]

Tim Dunphy wrote:[...]

Telnet to port 80, not the default port.  We're not actually interested 
in whether or not you have telnet working!  :-P
[...]

Just make sure that the machine running pound can properly resolve 
whatever is in your pound.cfg file.  If you have IPs in your pound.cfg, 
then its not a DNS issue.

What happens if you type the pound machine's IP into your browser?

Regards,[...]

Hello,

When in doubt, you should always use "tail -f" on the log files:

1. "tail -f /var/log/messages" and watch the pound traffic
2. "tail -f /var/log/httpd/blah.log" and watch your back end traffic

If pound is the culprit, then you will see a quick connection in #1 and a slow
connection in #2.

Of course, you should run these on separate machines, right? #1 is for the
pound machine, and #2 is for one of your back end servers.

If you see a slow connection in #2, then pound is having a hard time figuring
out where to send packets. Maybe you have a bad ARP on your route for the
second server? Are these two BEs on a DMZ, or are they solely behind a
firewall? Where is pound? Also behind the firewall, or on the DMZ?

If you see #1 fast and #2 fast, then you have a definite routing problem where
the firewall is killing packets because it thinks they belong on the inside
instead of the outside.

There are a bunch of reasons that could be why this routing problem is
occurring. 

PCRE will not help you with this problem. In some cases, I've heard of PCRE
making pound slower. So, use that with a grain of salt.

Another fun tool to use is "traceroute". Try that on your pound machine against
one of your BE IP addresses.

If you are running all of your servers on the DMZ, then you are likely
encountering routing problems caused by the firewall. You are essentially using
a drop-in firewall in your network and that is no good. The firewall would
filter packets as they occur on the wire for every response, and in some cases,
it will reflect the packets back because they can't be routed. I've seen this
before in one of my configurations where we dropped in a firewall parallel to
the pound server and it started to do the same thing that you describe.
[...]

Guys!


Just a heads up. It was actually an internal DNS issue. Fixed resolv.conf
on the dns server and the site came to life.

Thanks for playing! ;-)

Tim

On Thu, 30 Apr 2009 10:35:12 -0400, Dave Steinberg
<dave(at)redterror.net>
wrote:[...][...][...]
[...]