Link to home
Start Free TrialLog in
Avatar of Yann Shukor
Yann ShukorFlag for France

asked on

Slow Web access

Hi

My client has switched his users from a local server to a remote one located in a data center

They have an in-house PHP web app which is quite simple and essentially text based that runs  on Apache for Windows server 2008 - low bandwidth usage - they use SSL to secure the user access

Ever since switching the users to the remote server they have begun to notice occasional latencies
as if an exchange would suddenly grind to a halt, and a few seconds later, would bounce back into action
(a few seconds can sometimes reach 5)
Apparenty the initial GET connection is being responded to approx 500ms later, while the rest of the exchanges occur at around 150ms

I'll try to get more info, but so far that is all I have
Nothing in the windows event logs
And the Server performance indicators don't show any worrying levels

any ideas ?
thanks
yann
Avatar of FarWest
FarWest

please verify memory limits in Apache, low bandwidth requirement do not always mean  that PHP requires low memory to render it
good luck
Avatar of Ahmed Merghani
This issue can be caused at different parts. Initially from the network part, how your client connect to the remote Data Center? Is it a global IP that have been rooted to exact machine at Data Center ? - I faced a similar issue and conclude with that rooting  is the problem-.

Or it can be caused by web server part. The processor or memory - as fryezz said- can be the problem and need to be some tuning.

Or it can be at DB server part if your client are using DB.

While the application was working properly, then - I think- the problem will NOT be from the application.
I'm not a betting man, but in this case, I'd be willing to bet quite a bit of money that the problem is due to code that is accessing a database server either inefficiently or incorrectly.

Unless your in-house app disables compression and takes steps to explicitly start sending output to the user before the entire script is finished (using flush), then PHP will exhibit its normal behavior, which is to finish running the script first and THEN send all the resulting output to the user. This means that all the PHP code has to finish running first (database queries and connections, for example) before the initial GET will come back to the user.

So if your code is connecting to a remote database now (e.g. the database server hasn't moved, but the app has, so it no longer has the advantage of being close to home and having super-fast connection speeds to the server), then any inefficient queries or code will start to show their true colors. For example, some scripts will do a SELECT * query and they'll pull back a lot of extra data that's unnecessary to the script (maybe even some binary blobs). When the app and the database server are in the same network, the transfer of that data is extremely speedy, but when they're remote from each other, it may take a hundred milliseconds (for example) to download the same data now.

Databases are just one common cause, but it's truly more about the network connection. A script could talk to ANY other server, and if the speediness of that exchange changes because of the location change, then it will result in PHP taking longer to render the page.
There are many variables that may contribute to slowness including client's machine, client's isp, hosts' isp, hosts' server, etc.
Check the Server performance. Look in log any suspicious, memory check, configuration files, update the server ..etc.


Here's a site with worldwide tests, at least they claim that:
http://www.uptrends.com/aspx/free-html-site-page-load-check-tool.aspx

Uptrends web performance monitoring do; full page monitoring such as http, https, connect, ping, SMTP, POP3, FTP, MySQL, Microsoft SQL, Webservice http, Webservice https, DNS and more. Try it to have a full image about your issue.

Pingdom is also a popular choice to keep an eye on server
http://tools.pingdom.com/fpt/
from a local server to a remote one located in a data center...
Is it a shared server, by any chance?  There may be load sharing / balancing issues that give rise to the temporary and transient performance issues.  Might be worth asking the server administrators to see if they can identify anything.
Avatar of Yann Shukor

ASKER

Wow, thank you for all your responses.

Gr8gonzo, I think you are on the right track; I have suggested the use of Flush to my client.
Funnily enough I had already suggested disabling 'output-buffering'

Is there any way that we could monitor this behaviour ?
Possibly without slowing things down any further ?

The thing is we are haven't actually been able to
reproduce this behaviour. It did happen once
during our tests and lasted 15 secs.

As often happens it was the users that signaled
this new phenomenon, which seemingly is more
random than systematic.

thanks
yann
ASKER CERTIFIED SOLUTION
Avatar of gr8gonzo
gr8gonzo
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks gr8gonzo, I'll pass it along
I think they developed some javascript routine that runs before and after the script to record in order the time
Javascript runs on the browser / client-side. It won't be able to measure the specific lines of code - only the start/end times of the entire request.