Hello,

for some reason when we browse our website on our local webserver (test environment) the pages load very slow.

There is no lack of memory, no lack of disk space, no lack of CPU power and as far as I know our network is very fast.

Don't know where to begin looking, any suggestions ?

First thing is to check your network connection - try hitting your homepage directly on the machine (that is not via the network). Thereafter verify that system resources are not being exhausted on the server. Since its a test environment, it may be a good idea to bounce your web server as well and see what that does.

- Which webserver are you running? Post your configuration file?
- Try to browse via IP address instead of domain name
- Try to sniff some packets from server and client with tcpdump

With Linux these problems are easy to solve: you can trace every part of the process.

I suspect that your issue is DNS related. However, don't take my word for it.

You can run strace -p <pid-of-process-to-trace> If you can watch this live, you can see where it stops to wait for something.

You can trace your browser program (if that's graphical this will be difficult because it will be doing stuff with your screen all the time (e.g. animating rotating foxes)) or your webserver.

If there is a network involved you can also trace the packets on the network using tcpdump as suggested above.

Hi,

Did you try changing the browser?

May be your browser has some problem.Try if other site opens properly on the same browser.

Also can you try hosting virtual site on the same webserver and see if it loads correctly.

Config :

<VirtualHost *:80>
ServerName webby.jocan.local
DocumentRoot /var/www/vhosts/webby/html
</VirtualHost>

How can I visit this VirtualHost on IP-address ?

Which pid is it that I need to monitor ?

[root@webserver ~]# ps aux | grep httpd
apache 9636 0.0 2.7 31244 6908 ? S 11:30 0:00 /usr/sbin/httpd
root 9802 0.0 0.2 4212 696 pts/0 S+ 16:10 0:00 grep httpd
root 26328 0.0 5.1 31112 13184 ? Ss Oct27 1:14 /usr/sbin/httpd
apache 32500 0.0 3.2 31376 8172 ? S Oct31 0:02 /usr/sbin/httpd
apache 32502 0.0 3.0 31244 7796 ? S Oct31 0:00 /usr/sbin/httpd
apache 32505 0.0 3.0 31244 7788 ? S Oct31 0:00 /usr/sbin/httpd
apache 32507 0.0 3.0 31244 7800 ? S Oct31 0:00 /usr/sbin/httpd
apache 32510 0.0 3.0 31244 7796 ? S Oct31 0:00 /usr/sbin/httpd
apache 32512 0.0 3.0 31244 7800 ? S Oct31 0:00 /usr/sbin/httpd
apache 32514 0.0 3.2 31376 8172 ? S Oct31 0:00 /usr/sbin/httpd
apache 32516 0.0 3.0 31244 7808 ? S Oct31 0:00 /usr/sbin/httpd

Avoid to keep access_log, error_log with huge size( about more than 2Gb).

The biggest logfile on the webserver is about 7,5MB...

I want to add that I also have problems when using ftp to upload changes to the webserver. I use NetBeans and it takes "abnormal long" to upload changes.

From your client machine (i.e. NOT the webserver) run ping -a FQDN (where FQDN is your fully qualified domain name, in your case webby.joneas.com or whatever)

It should give you an ip with the bounce back.

Go into your web browser and type http://ipaddress where obviously ipaddress is the actual ip address, not the word

Does it load faster? I bet it does. If so, you likely have apple talk on your network. Other than ripping that shit out, you're SOL. If it's still slow, there's something drastically wrong with your networking. Is your client machine windows or *nix? If it's windows, try going into the configuration for the network adapter and changing the duplexing from being auto-sense/auto-link to 100Mb/Full or 1000Mb/Full, whatever your network supports. You can also go into teh advanced properties and disable all checksum offloading.. that will help boost performance.

If after all of this, you are still slow as hell, download and install ethereal on your client machine and ettercap on your linux box. Start a network trace on both machines AT THE SAME TIME and then load the webpage. Stop the trace and examine... what you are looking for is a ton of retransmits, dropped packets, anything weird.

Good luck.

_O_

Like I said, I have several virtual hosts on the machine (Apache on CentOS 5.5). Just replacing the FQDN with the IP-address of the webserver does not load anything.

That's my question: how to reach the virtual host on IP-address ??

Pinging the host on IP-address or FQDN has the same (fast) results. So don't think it's a DNS problem.

I run Firefox on Fedora 12.
I have this in my /etc/hosts :

To reach a virutal host on an IP address try the following...
(hit return twice after the "host: " command.... )

Or does the IP address resolve to the virtual local server??

I'm preparing a new server for my webserver, so it is currently local, and the official names still resolve to the IP address on the internet....

[Jonas@jonas ~]$ telnet 192.168.1.151 80
Trying 192.168.1.151...
Connected to 192.168.1.151.
Escape character is '^]'.
GET / HTTP/1.0

and it stays that way...

Did you hit return twice? (i.e. enter an empty line?)


[edit] Rereading... Did you think the "host:" line was the answer from the server? You can omit the host line at first, you should at least get SOME reply if you hit enter twice after the "GET" line....

You have to send a request header. A header can consist of many separate lines, and the server only starts processing it once it gets a complete header. The end of the header is signified with an empty line.

Once you have it working manually, you can do: (reduce the time of the "sleep" once you have this working. You said it was slow. )

Next you can put this in a script that might take the URL as an argument....

Another way to reach the virtual hosts on the local webserver is to mess with the networking setup. Note that this will deliberately create an invalid networking setup, so it's not for the faint-hearted.

Setup your test-server with the official IP address(es).
next, on your Linux workstation do: route add <officialIPaddress> eth0
Now your linux workstation can no longer reach the official webserver for your domain! it will look for that IP address on the local network and find it there!

Note that for example sending and receiving mail might end up going wrong in this setup. It's very likely that you'll mess up more than you're supposed to. So only try this if you really know what you're getting into.

This the output :