Improving response time to network requests

[zazoo]

Hello,
I was wondering if anyone could suggest a way to improve a linux machine's response time to network requests. For example, i have telnet, ftp, and smtp requests going toward the machine's ip address and it can take a good 10 seconds before responding. This really shouldn't happen considering everything's on ethernet (100mb).
so again, if anyone could suggest a way to improve this response time i'd really appreciate it..
btw it's red hat 7.1 (on a 466 celeron).


Zazoo.

 

[poorboy]

Wow, that is really slow. Start by trying to define where the problem actually lies. Is everything up2date?

Can you get a good ping response time (Anywhere from < 100ms to 500ms is pretty normal)?

Is the system overloaded? Enough RAM (no swap storms before responding)?

Do these particular services go through xinetd? Are all of the services slow to respond or just some?

And what are you doing running telnet!?

<i>I used to have a girl, but then I got my CS degree...</i>

 

[zazoo]

i think the last time i updated the whole lot was about 2 months ago.. so things are pretty recent...
my pings are responding at about 350-530ms
memory is freed up and at 128 meg
all the services (to my knowledge) are going through xinetd and it would appear to be affecting all the services.
an interesting observation: when i am connected to the internet on the linux box (dialup) it has that long delay (even when doing "telnet localhost" on the cosole) but when i am not connected to the net it responds faster. At least.. this is true on the console.. i can't remember if the clients get responses faster. (win2k machines btw)
and as for the using of telnet... well... it's pretty much what i need to use.. especially when interacting with windows machines as i mentionnned.
any ideas?



Zazoo.

 

[poorboy]

Well, I did some searching, and the most likely culprit I found was ident looksups.

Check out your /etc/xinetd.d/* files, and see if there is a USERID line in there. If there is, comment it out or delete it.

Apparently Windows workstations don't support it, so when Linux tries to find out who is connecting, it times out before carrying on with the connection. I'm not sure if that's what is going on with the local connctions though.

Reading your note about the net connection speedup, I hope it's not some weird routing problem... Check your routing table to make sure theres no "odd" entries.

Telnet is supposed to be pretty insecure, so ssh or similar might be a better option? If it's just on the local net, then you acn probably get a way with telnet... BTW, the xinetd page suggests using 2.3.3 or better due to a bug.

<i>I used to have a girl, but then I got my CS degree...</i>

 

[zazoo]

i have a bit more information that might help in solving this problem.... remember my remark about the "telnet localhost" being fast when my dial up internet connection is NOT active but slow when the internet is up? well ive verified the specifics and indeed it is immediate on the console when there is no internet active. However, it also applies to the windows machines connected locally. when the internet is off the response is near immediate. One thing i have previously left out was that i have enabled ip forwarding through the linux machine for the windows so that only 1 internet connection is necessary. i suspect that what is happening is this: the network requests are sent through the server before they are directed AT the server. what i mean to say is the connection attempt is tried on the internet first, instead of locally which would be the more correct way to do it. it doesn't seem to make a difference whether i'm using the local or remote ip address of the server, the response is the same.
i guess that makes my new question : do you know of a way where i can indicate that network requests directed at the servers ip 192.168.0.1 be attempted on itself before the internet? except of course for the actual internet traffic... understandably i need that to be maintained.
honestly though i don't know a great deal about how the ipforwarding works, or routing so any help you could offer would be great...
thanks again,



Zazoo.

 

[poorboy]

Ok, it sounds like that's where the problem is then. Maybe traceroute or similar can tell you where the packets are going? Etheral could be usefull to see exactly what's running over your network. Take a look <A HREF="http://home.clear.net.nz/pages/rich_b_nz/" target="_new">here</A> and let me know if this is what your setup is like. Then I can start getting into it.

I found <A HREF="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO/index.html" target="_new">this</A> HOWTO to be enough to get my Lan sorted out. There's a couple of sample scripts in it that might help (need to change them a little though).

Obviously, you can get 'net with your Linux box. I'd suggest turning iptables/forwarding/whatever off, and see what happens to the timeout (apart from no lan<->internet). If that's good, then start up squid and bind, and check you can get a proxied connection. This is just client<->server, server<->internet. If that's still ok, you need to pull you firewall/fowarding scripts to bits, and check your routing script for ppp.

Let me know if the pic on my homepage matches your lan, and we can go from there...

<i>I used to have a girl, but then I got my CS degree...</i>

 

[zazoo]

okay... first off the diagram seems accurate.. it's essentially exactly what i have.. the only thing i am uncertain about is the DHCP configuration. all i have done is set the gateway to the server's ip address on the windows machines. As for ip masquerade, this is all i had to do:
<excerpt from /etc/rc.local>...
echo "1" > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.0.0/24 -j MASQ
...<end>


Zazoo.

 

[poorboy]

The DHCP stuff is minor, especially if you are using the IP address for making the connection. It's mostly there so the windows pcs know the dns server, lan name, etc. If you've got it setting IP, netmask, and router that should be ok.

I'm sort of guessing here, but what happens if you add the device to your ipchains line (/sbin/ipchains -A forward -s 192.168.0.0/24 -i eth0 -j MASQ)? I say this because I'm wondering what happens when a packet comes over lo that thinks it's from 192.168.0.1... If ppp0 is down, then no problem, but if it's up, does it try to forward it down the new default route?(eg the internet)

At any rate, a more secure ipchain/iptable setup would be good. This might be a good start: <A HREF="http://www.linuxdoc.org/HOWTO/Masquerading-Simple-HOWTO/summary.html" target="_new">http://www.linuxdoc.org/HOWTO/Masquerading-Simple-HOWTO/summary.html</A>

Edit: changed the -o to -i, cos it's the input interface.

<i>I used to have a girl, but then I got my CS degree...</i><P ID="edit"><FONT SIZE=-1><EM>Edited by poorboy on 04/07/02 07:03 PM.</EM></FONT></P>

 

[zazoo]

hello again, remember me?
i realize it's been a while since i last wrote regarding this matter... i haven't been very available.
however, the issue is still present.
i have also made a few determinations since our last conversation. basically 2. i added rules in my ipchains so that the forwarding chain ignores any requests whose destinations are 192.168.0.1:21-25. (covering ftp, telnet, smtp)
this didn't solve the delay problem. i then decided to deactivate all ipchains rules. (/etc/init.d/ipchains stop)
still no help... 10 second delay with any incoming connection.
for fun, i again disconnected from the internet and tried a request. instant response. heheh.. surprised? not me.
so i don't know what to do. it seems that mere internet PRESENCE causes this delay, whether or not i have packet forwarding enabled.
i was intrigued by your original suggestion about host name lookups being ignored by windows. i commented out the line in the /etc/xinetd.d/telnet file that had the USERID keyword, and restarted xinetd. it didn't change anything.. assuming i did it right in the first place..
it does seem to be along the right lines though, so did you have any other ideas since i've ruled our the forwarding tables?
thanks again,



Zazoo.

 

[poorboy]

Weird. If it's not wrongly forwarding to the net, and it happens with IP numbers not just resolvable names, then I'm really not sure what's going on. It's not something I've seen before.

<i>I used to have a girl, but then I got my CS degree...</i>

 

[zazoo]

well i have found one solution just recently.
if i manually enter each ip address and a hostname in the /etc/hosts file it skips the IDENT check and so connects immediately. This doesn't help for outside entry, but it does for situations where i know the incoming ip address...
i just had to add for example
192.168.0.2 room32
192.168.0.6 room52

etc etc etc...
so anyways that seems to have solved the problem for all connections except ftp, but that's not such of an issue...

thanks again for all your help, it was much appreciated...


Zazoo.

 

[growchie]

/sbin/ipchains -P forward DENY
try removing this
connect to the network and say ACCEPT on forwarding
i had a problem once
i used DENY as a default policy on 2.4 kernel and the responce slowed down as you described

 

[jlanka]

do your routing tables look correct?

<i>It's always the one thing you never suspected.</i>

 

[mathew75]

Well, this happens very often on bad configured networks, and as you wrote it helps when you put pair host/ip to your /etc/hosts files, this means, you have not set up reverse DNS entries on your DNS servers. All your services tries to resolve IP address to hostname, and because they wait for answer from DNS, you wait for them.