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
Yann ShukorOwnerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

FarWestCommented:
please verify memory limits in Apache, low bandwidth requirement do not always mean  that PHP requires low memory to render it
good luck
0
Ahmed MerghaniSoftware EngineerCommented:
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.
0
gr8gonzoConsultantCommented:
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.
0
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

madunixCommented:
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/
0
Ray PaseurCommented:
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.
0
Yann ShukorOwnerAuthor Commented:
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
0
gr8gonzoConsultantCommented:
Unfortunately, flush() is just one piece of the equation. There are a few different components that might be involved in output buffering. Web servers often have it turned on so that they're compressing data before sending it (to save bandwidth and speed up the overall transmission at the expense of some CPU), so even if PHP has it disabled and you're using flush(), you may still have the web server doing it.

Disabling output buffering or compression isn't usually a good fix. Bandwidth is a more precious commodity than CPU, so it's usually a good thing to let the web server do its compression.

The better fix is to identify the parts of the script that are taking up the largest amounts of time. For example, if the script performs 5 queries, see if they all take a minimum amount of time to execute, or if one is much longer than another. A quick way to measure performance of queries (or ANY network calls) is to simply log the output of microtime(true) before and after each query / network call. For example:

Original:
$results = mysql_query("your query here..."); 

Open in new window


Updated:
$start = microtime(true);
$results = mysql_query("your query here..."); $line = __LINE__;
$end = microtime(true);
file_put_contents("query_time.log",basename(__FILE__)."\t".$line . "\t" . ($end-$start) . "\n",FILE_APPEND | LOCK_EX);

Open in new window


That should create a tab-delimited file called "query_time.log" with output like this:
index.php      123      0.005312
index.php      234      0.012911
otherpage.php      456      0.007211

...where the first two fields indicate the file and line of code with the query that was run, and the third field is the number of seconds it took to -fully- run the query (make the request to the database server, wait for the server to finish processing the query, and then download the results into memory). For example, the query on line 234 in file index.php took 0.012911 seconds to fully run. My guess is that your run numbers will be a bit higher than the examples above.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Yann ShukorOwnerAuthor Commented:
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
0
gr8gonzoConsultantCommented:
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.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Apache Web Server

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.