Php.ini Causing Ajax To Load Slow?...

[rmpotter]

Strange bug here... ajax has been loading slow on this server since day one... we thought it was the internet connection, until yesterday. I accidentally added an invalid extension into the php.ini file (ie. extension=php_pdf.dll), and then all of a sudden, the ajax loaded extremely fast. When I took out that invalid extension, the ajax loaded slow again. My colleges and I did not create the php config file, so I'm not sure why this is happening... maybe there's a setting turned on in the php config file that is causing the ajax to load slow, and when this invalid extension is included, it skips the setting... not sure. But hopefully someone can help explain this!If anyone can point me in the right direction to why this is happening, I'd appreciate it! Our slow ajax loading won't be fixed until this is sorted out, and the guy who created the php.ini file no longer works here.The site is: http://www.charmscorp.com/inspect/projects.phpSo if you click there, you'll see how load the ajax loads. Please help, I can include the php.ini file if anybody wants to see what settings are enabled.Thanks in advance to any help I receive.

[justsomeguy]

I'm seeing a pretty big difference in the actual ajax request and the interface update. I clicked Open Project and chose Loki, and the ajax request for Open Project only took 223ms according to Firebug, but it didn't update the browser for a couple seconds. The request after choosing Loki only took 150ms, but it again took a couple seconds to update the interface. It sounds more like a Javascript issue.Then again, if I load getprojects_tmpl.php directly in the browser, it does take several seconds for the output to show, even though Firebug still reports less than a second. Maybe Firebug isn't reporting the actual roundtrip time.If you think the problem is in php.ini, feel free to post it in a codebox. It might also be a good idea to add some timers to the PHP code to figure out which part of the code is taking so long. You can time a group of statements using microtime:

$start = microtime(true);// do stuffecho 'time spent: ' . (microtime(true) - $start) . ' seconds';

[rmpotter]

I'm seeing a pretty big difference in the actual ajax request and the interface update. I clicked Open Project and chose Loki, and the ajax request for Open Project only took 223ms according to Firebug, but it didn't update the browser for a couple seconds. The request after choosing Loki only took 150ms, but it again took a couple seconds to update the interface. It sounds more like a Javascript issue.Then again, if I load getprojects_tmpl.php directly in the browser, it does take several seconds for the output to show, even though Firebug still reports less than a second. Maybe Firebug isn't reporting the actual roundtrip time.If you think the problem is in php.ini, feel free to post it in a codebox. It might also be a good idea to add some timers to the PHP code to figure out which part of the code is taking so long. You can time a group of statements using microtime:

$start = microtime(true);// do stuffecho 'time spent: ' . (microtime(true) - $start) . ' seconds';

The reason I don't think it's not the code causing this is because even when doing basic ajsx requests on this server, they take longer than when posted on other server. This lag for ajax has existed since day one, which is why we suspected slow server internet. But then all of a sudden, we mess up the php.ini, add a bad extension, and the site loads up super fast.So.. I may be wrong though, as I'm new to coding, but it seems like a server-side problem. I will gladly upload the php.ini file for you to look at, but sadly I'm not sure exactly which part of the file could be causing this problem. I will try to add the timers into the config file like you mentioned as that sounds brilliant.

[justsomeguy]

I will try to add the timers into the config file like you mentioned as that sounds brilliant.

Not the config file, but the actual PHP script you're running. It might just be the case that it takes 2 seconds to even start and then completes everything else in .1 seconds, that would indicate a startup problem.

But then all of a sudden, we mess up the php.ini, add a bad extension, and the site loads up super fast.

It might have completely ignored the ini file and used the default one. You may want to experiment with the extensions, disable each extension you're using one at a time and see if it makes a difference.

[rmpotter]

Not the config file, but the actual PHP script you're running. It might just be the case that it takes 2 seconds to even start and then completes everything else in .1 seconds, that would indicate a startup problem.It might have completely ignored the ini file and used the default one. You may want to experiment with the extensions, disable each extension you're using one at a time and see if it makes a difference.

Yes, sorry, I noticed right away that I needed to add the timer to the actual script, my bad. Now, I added that timer, and edited the code to time the php, and it was fast. if you go to the site again... http://beta.charmscorp.com/inspect/projects.php and open project, and pick one, and then hit open, and wait, it will show you the time... it was .0068 seconds for me, which is nice and fast. It once again took forever to post though. Not sure what to do from here.I also disabled the extensions one by one.. and when I disabled a crucial one, the site ceased to function, so it is using the ini file that I'm editing. After disabling them one by one, the site didn't go any faster though.. although once again adding the bad extension makes the site as fast as it should be.

[justsomeguy]

hit open, and wait, it will show you the time... it was .0068 seconds for me, which is nice and fast. It once again took forever to post though.

That sounds like a startup problem then. Post the ini file, one thing would also be to enable startup error logging and check if there are any startup errors.

[rmpotter]

That sounds like a startup problem then. Post the ini file, one thing would also be to enable startup error logging and check if there are any startup errors.

I will check to see if error logging is enabled in the php.ini file (this file is relatively new to me), and whatever the case, I'll look into these logs.The php.ini file is: http://rapidshare.com/files/280491999/php.ini.html I appreciate all of this help!

[rmpotter]

I just checked in the php.ini file, and I see various logging settings turned off. Mainly these 2: ; Log errors to specified file.;error_log = filename; Log errors to syslog (Event Log on NT, not valid in Windows 95).;error_log = syslogIf these are the error logging settings you were talking about, I'll uncomment them immediately.

[justsomeguy]

Use the filename version, give an absolute filename for the error log. There will also be a setting about startup errors, make sure startup errors are being reported. It should log all error messages to the error log. Also make sure error reporting is set to E_ALL.

[rmpotter]

Use the filename version, give an absolute filename for the error log. There will also be a setting about startup errors, make sure startup errors are being reported. It should log all error messages to the error log. Also make sure error reporting is set to E_ALL.

Alright, so I did this:; Log errors to specified file.error_log = errorlog.txt; Even when display_errors is on, errors that occur during PHP's startup; sequence are not displayed. It's strongly recommended to keep; display_startup_errors off, except for when debugging.display_startup_errors = Onerror_reporting = E_ALLNo errorlog.txt file is ever created though, even after loading up various ajax/php. Would this mean no error are being generated?

[justsomeguy]

Give it a full path to the file, not just a filename.

[rmpotter]

Give it a full path to the file, not just a filename.

ya, I tried that earlier, I put: error_log = F:\PHP\errorlog.txt, and nothing is written. Hmmm.Were you able to peek at the php.ini file? I've been going over it for the past little bit here, but not being a php/mysql guy, I'm not sure at some of the things I'm looking at. I turned off buffering, thinking that might be it, but no go.I may have to get a PHP pro in here, just to reconfigure the ini file and/or troubleshoot this problem, because it's quite crippling, especially when it's in a file I never created

[justsomeguy]

ya, I tried that earlier, I put: error_log = F:\PHP\errorlog.txt, and nothing is written. Hmmm.

That just might mean there's no errors, you can always create an error to test it though. e.g.:

<?phptrigger_error('test error', E_USER_ERROR);?>

Make sure that shows up in an error log. You may need to create the error log first and give PHP permission to write to it. It looks like your server is running IIS, so to do that first create the text file in the appropriate place and then right-click and choose Security (or Properties, then Security tab). The user account you need to find is the IUSR account, it starts with IUSR_ and then has the computer name. Make sure that user account has permission to write to the error log file.I'll look through the ini file, it's important to look for error messages though.

[rmpotter]

That just might mean there's no errors, you can always create an error to test it though. e.g.:

<?phptrigger_error('test error', E_USER_ERROR);?>

Make sure that shows up in an error log. You may need to create the error log first and give PHP permission to write to it. It looks like your server is running IIS, so to do that first create the text file in the appropriate place and then right-click and choose Security (or Properties, then Security tab). The user account you need to find is the IUSR account, it starts with IUSR_ and then has the computer name. Make sure that user account has permission to write to the error log file.I'll look through the ini file, it's important to look for error messages though.

alright, so the error logging works. I just tried it and it found an error that I purposely gave it. But it finds no errors otherwise...

[justsomeguy]

OK, that sounds like there aren't any startup errors then. This is pretty difficult to troubleshoot remotely. I hate to say it, but if adding an error to php.ini improves performance then that might be a quick fix until the cause can be found. It would be important to make sure that it's actually using the correct settings still though. For that you should create a phpinfo page:

<?php phpinfo(); ?>

When you run that you'll see information about PHP, near the top it will say which php.ini it's using. The best way to compare the before and after is to just run a compare tool on it. Open up the phpinfo page and view the HTML source, and copy that into a new text file. Then make your ini changes and open phpinfo again. First make sure it's still using the same ini file. Second, copy the HTML from that version into another new text file. If you already have a compare tool, run a comparison against the two files to look for changes. If you don't have a tool to do that, there's a link in my signature to download ConTEXT. You can open both files in ConTEXT (if you paste directly into ConTEXT you don't need to actually save the files), and go to Tools->Compare. Select the two files, and it will highlight all of the differences. If you don't see any differences and the performance improves, that might just be the best thing until you can get someone in to look at the server.I've also got a feeling about fast_cgi, run through the ini file and check for fast_cgi settings, enable anything that says it works for IIS.

[rmpotter]

OK, that sounds like there aren't any startup errors then. This is pretty difficult to troubleshoot remotely. I hate to say it, but if adding an error to php.ini improves performance then that might be a quick fix until the cause can be found. It would be important to make sure that it's actually using the correct settings still though. For that you should create a phpinfo page:

<?php phpinfo(); ?>

When you run that you'll see information about PHP, near the top it will say which php.ini it's using. The best way to compare the before and after is to just run a compare tool on it. Open up the phpinfo page and view the HTML source, and copy that into a new text file. Then make your ini changes and open phpinfo again. First make sure it's still using the same ini file. Second, copy the HTML from that version into another new text file. If you already have a compare tool, run a comparison against the two files to look for changes. If you don't have a tool to do that, there's a link in my signature to download ConTEXT. You can open both files in ConTEXT (if you paste directly into ConTEXT you don't need to actually save the files), and go to Tools->Compare. Select the two files, and it will highlight all of the differences. If you don't see any differences and the performance improves, that might just be the best thing until you can get someone in to look at the server.I've also got a feeling about fast_cgi, run through the ini file and check for fast_cgi settings, enable anything that says it works for IIS.

Alright, well thanks for all of your help. We'll try what you said, keep trouble shooting, and worst case scenario, we get someone to come in and look at the server. When we find out the cause and the fix, I'll post here to let you know what it was. Thanks again!

[rmpotter]

unfortunately the fast CGI settings did not help