Avatar of Yann Shukor
Yann Shukor
Flag for France asked on

Slow Web access


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 ?
Apache Web ServerPHPWeb Servers

Avatar of undefined
Last Comment

8/22/2022 - Mon

please verify memory limits in Apache, low bandwidth requirement do not always mean  that PHP requires low memory to render it
good luck
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.
Your help has saved me hundreds of hours of internet surfing.

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:

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
Ray Paseur

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.
Yann Shukor

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.

Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
Yann Shukor

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.