Linux --> IIS Slowness

[NotSoCunning]

Hi all,

I have relatively little Linux experience and am having great trouble which I though you guys might be able to shed some light on.

We have various web servers running IIS5 and IIS6 which when tested work fine from Windows PCs. However, when we try and connect through a Linux platform (RH Enterprise 4) we get a delay of about 20-30s before connection.

The delay only occurs on Linux machines and we are at a loss to explain it. Firewalls and routing have been ruled out since problems occur outside of the Firewall and from different locations and doesn't effect Windows machines.

We've rebuilt the servers and have built fresh Linux machines and the problem still occurs.

Does anyone have any ideas?

 

[sleipnir214]

What web browser are you using on your Linux box? There are also text-based browsers that will run on Linux -- have you tried one of those?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[thedaver]

I'd also check for the following:

do the web pages have browser sniffing code that renders pages differently for different browsers?

do the web pages have IE specific elements such as ActiveX that are required to render the pages?

do the web pages have Flash, Shockwave, Java or dependencies upon "plugins" that are either not installed on the linux clients or that are otherwise taking time to load to support the page?

do the webpages have Javascript that is trying to do unusual things?

are the webpages HTML compliant and verified?

do the pages make particularly heavy use of tables?

It sounds to me like you have a repeatable period of latency before the pages render on Linux. That could be indicative of a network service timeout related to what the Linux machines have been told about trying to reach the hosts. I'd also check your "route -n" routing tables on the linux machines to make sure they are not trying to reach an inappropriate gateway as their first path to reach the IIS machines... this would explain the feeling of "timing out and moving to Plan B".

Keep us in the loop....

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[lgarner]

Check also the client DNS setting. This can happen if the first server isn't the greatest.

 

[NotSoCunning]

Thanks for your replies.

The problem respresented itself with a Flash loader that took 20-30s to bring up content. Although during testing locally it was instant (near enough).

Having only ssh access to the Linux box myself we simply used Telnet over port 80 to test the access times. We built a new web server and simply enabled the default site and still experienced the delay so the content of the site does not seem to be the issue.

Since I built the new linux box I hadn't tried testing an actual browser which incidently works perfectly when I just tested. It was a text based one and was fine.

A further twist has me even more confused. A telnet direct to the IP address on 80 causes a 20-30s delay a telnet to the FQDN on 80 results in instant access.

The routing table is fine.

Any suggestions ?

 

[RhythmAce]

Did you install linux as a server? If you installed it as a workstation or in otherwise have graphics running, That in itself uses a lot lot of resources. Linux can boot into differn runlevels. The desktop (graphic) mode is called runlevel 5 and server (text) mode is rnlevel 3. You can run 'top' from the command line and see where all your resources are going. Look for X11 or Xorg in particular.

 

[NotSoCunning]

Ok further information, thanks to our ISP we've isolated it further, the problem only occurs on Red Hat based machines. Debian based machines were fine.

Is there something weird or different that needs to be looked at on Red Hat?

 

[thedaver]

Redhat machines probably have a default firewall installed with "Medium" settings.

You might also check if your NICs are set to full/half duplex as a conflict with any switches

Have you checked the routing tables on Redhat machines?

How did the ISP determine the problem was RedHat unique? What measurements, metrics, audits did they perform to reach that conclusion? I would have thought that such research would have lead to a conclusion also.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[NotSoCunning]

All they did was to test the connection from Debian machines which were accessing it normally and compare that to their Red Hat machines.

Debian = fast connection
Red Hat = slow connection

It's interesting because I didn't actually state to our ISP that is was Red Hat that we were using.

 

[NotSoCunning]

Oh forgot to add, I can't see a way of expliciting forcing full duplex from within RH. The firewall is disabled on the machines and the routing table is ok.

 

[thedaver]

Have you narrowed it down to specific applications or all connectivity? Meaning, are you trying to see websites with Mozilla versus lynx or wget? Are you timing pings? traceroute?

You need to help me/us understand if you have an application or machine-level issue.

Still not sure I understand what the ISP did.....

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[NotSoCunning]

The reply from our ISP was as follows:

The only thing we have noticed is that form UNIX machines running Redhat it is slow but any thing running Debian it is quick

Not overly helpful, they were also quick to distant themselves from the issue.

The only issue is connecting to the server via IP from Redhat using Telnet over web ports. Browsers function fine as does dns resolution. Pings and Traceroutes show nothing other than the delay you'd expect. Certainly no 20000ms+ responses.

 

[thedaver]

I'm trying to stick with you here...

Can you restate, as directly as possible, which applications are/not working over which protocols and by what degree?

I'm having trouble keeping your situation in context. Ask a specific questions again. Thanks.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[NotSoCunning]

It's difficult to explain.

A client has an application that makes a connection to a web service apparently in the same way as you'd telnet. It connects directly to the IP on port 80.

A browser connection works fine to the site, as does telneting over port 80 direct to the IP from any windows and so far any linux pc, except Red Hat based machines. Connecting to the web address alias (www. etc) is fine for everything.

The only issue is connecting via telnet (or his app) direct to the IP address over port 80 or 443 from Red Hat machines.

I've put in place a new A record for the web service to hopefully work around the delay but I'm still puzzled why this is a problem.

To summarise:

Clients App >> IP Address of the server = DELAY
Clients Red Hat Telnet >> IP Address of the server = DELAY
Client Red Hat Telnet >> Web Adress (

http://www.)

of the server = FINE
Any Red Hat Telnet >> IP Address of the server = DELAY
Any other PC >> IP Address of the server = FINE
Web Browsers from anywhere >> IP or www. of the server = FINE

Pings = Fine
Traceroutes = Fine
Routing = Fine
Servers = Rebuilt
Firewall = Removed

None made any difference.

Thanks for following .

 

[thedaver]

So you see a meaningful difference in simple telnet response to server port 80 based upon the distribution of the linux client and its telnet?



D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[NotSoCunning]

Yes.

The difference is from instant on Debian or Windows to 20-30s on Red Hat.

 

[thedaver]

And, solving the telnet lag is important?

Can you use wget or lynx to make the call to port 80?

I guess I'm trying to ask, "is it necessary to fix this?"
You didn't really specify what the client's application depends upon.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[NotSoCunning]

Solving the lag is important to the client. We worked around it for the moment with a dns record, but I'd still like to actually solve the problem rather that working around it if you know what I mean.

Afaik the application makes a call to the ip on 80 using it's own connection. I don't know the details other than telnet produces the same results.

elinks makes an instant connection, as does wget.

 

[stevexff]

Might depend on how the addresses are getting looked up. /etc/resolve.conf says whether the resolver looks in /etc/hosts or DNS first. Normally there are a couple of DNS servers in there. ping uses the default resolver settings (I think), nslookup always uses DNS, and if you put in the dotted quad it shouldn't need to go through the resolver at all.

Do you get the delay using nslookup on the name (not the dotted quad) from redhat? Is it perhaps looking on DNS first, waiting for a timeout (possibly from the first listed DNS server), and falling back to /etc/hosts?

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]