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: link text
So if you click there, you'll see how slow 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.
You may want to install firebug if you are not using it already (it's a webdeveloper plugin for firefox).
I just checked out the site and the data seems to be loading fast enough but it seems the JS is just terribly slow. A hint that something is wrong is also in the net tab that doesn't seem to be able to determine the size of your ajax calls, if the js has that same problem it could cause it to hang waiting for the stream to end.
Looks like misconfiguration in the php.ini, but without its content it is hard to say anything about it really.
Also, if you try to load the ajax call manually, you'll see that the page loads for a long time, but the data shows up almost instantly, and then the connection is not closed immediately.
If you are sure the commenting out of the bad dll declaration is having a bearing on this issue, you could try moving it down the list till you find out which other dll is causing the problem.
Did you look in the php start up errors?
ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);
Related
I am very very new at PHP programming.
I am making up some code to test my learning but I just discovered a very annoying problem.
I have no idea about the cause, so following I'll describe my situation and I'll leave to you the "honor" to find the problem :)
I use dreamweaver to write my PHP code.
Once I made all the changes, I save the file and refresh the browser page to see the result.
Well, here is the problem. For like 30seconds nothing changes, after this time delay the page actually refreshes. There seems to be a delay between when I save the modified file in dreamweaver and when the browser (Chrome in my case) sees the new file.
I tried different browsers and I also verified that the file is physically changed...I have no clue.
It has nothing to do with Dreamweaver.
You have to disable OPCache
Some software such as MAMP turns on OPCache by default in the php configuration file (php.ini), you can disable it this way
opcache.revalidate_freq=0
I want to share a problem I had, the fix I found and then ask a question about the reason behind the fix.
The problem
After upgrading to wampserver 2.2, one of my webpages consistently didn't work the first time it was loaded in the browser. This happened with internet explorer, chrome, firefox and safari. When reloaded the page worked in all browsers.
the fix
I decided to implement a better debugging solution and while doing so inadvertently fixed my problem. When I set output_buffering =On in php.ini the page worked correctly.
my code
I'm not going to go into detail here. I'm more interested in theory for how output_buffering could be causing problems. Also I think my code will be more of an eyesore than a help.
I used ajax and joomla sessions (external script) to retrieve
information for the page.
I believe that when output_buffering was off, the joomla session
was not able to retrieve values. I'm not able to confirm this yet
though.
My question
In what ways can output_buffering= Off adversely affect code? Why?
Output buffering simply allows you to hold off on displaying data that would otherwise be immediately printed to the browser. These are used largely with templating engines in order to store unrendered templates so that they can be filled in with values. I'm guessing Joomla depends on output buffering to fill in the correct values for its templates, which would explain why you were seeing invalid output.
"I used ajax and joomla sessions (external script) to retrieve information for the page."
That is your problem. You're retrieving a content that varies within a certain time delay.
Refer to this, it may help you understand how it works: https://stackoverflow.com/a/2832179/817419
As it turned out one of the files being called by the webpage was encoded incorrectly. Once I encoded it as UTF8 without BOM my problem was largely fixed. My script would work without output_buffering turned on.
The other part of the problem was that some of the scripts that used Firebug complained of headers already being sent. This stopped the code in its tracks.
I am working on a site now that seems to have an infinite loop for the wp-cron.php file. My host recently limited my account because they said that a certain query to my database was creating 1GB of error logs every 15 seconds. I am not sure why this is happening.
I wanted to know if anyone has encountered and successfully solved this issue. We were working on this site on a dev server with no problems, but now since we've moved to our production environment we've been getting this issue. I am thinking that maybe some files were lost in the transfer, however it does not seem so.
Thanks
OK So I have found a solution for this, and I figure that it would help to let everyone on here know as well.
Basically, after a lot of research, I have found that the MailChimp Archives plugin apparently fires off the naughty cron job in question every time someone visits the site. For whatever reason, it got thrown into an infinite loop which was creating huge log files (64MB in about 3 seconds). Once I discovered exactly where the issue was coming from, I did the following:
Disabled the plugin
Found a Wordpress function that removes selected hook that schedules the runaway cron job (http://codex.wordpress.org/Function_Reference/wp_clear_scheduled_hook).
Used that function to remove the hook in question, by inserting it into my theme's functions.php file, and reloading the page.
Removed the function once I reloaded the page a few times.
Found the corresponding data in the database, which was in the wp_options table. I just searched the name of that same hook that caused the problem, and found that the option value field contained 9.5MB of text in it! Obviously the cause of the massive slowdown, since this 9.5MB of text needed to be loaded and parsed every time someone visited the page. I removed this completely from the database.
Once this was done, I started to notice incremental increases in performance on my Wordpress site over about a half hour or so. I also did another test to see if the log files were accumulating, and they were now only fluctuating between 3-4Kb, which was way better.
I hope this helps. Even though this seems to be a fairly common problem, I don't see many detailed solutions for it, so let this be the first.
Thanks
I believe there was an issue where if the server would go into an infinite loop if you didn't have the wp_cron.php file, since returning the error calls the file again. It's worth checking for in this case.
It's also possible that a variant might be happening - you try to access a file from wp-cron, and the file isn't found.
Even if all the files were copied, their paths might not have been copied correctly.
The cron jobs of Wordpress were causing a high CPU consumption on the server. Even defining define ('DISABLE_WP_CRON', 'true'); does not work. Without using a plugin the way I found it was to include this in the theme's functions.php:
global $wpdb;
$wpdb->update("wp_options", array("option_value"=>""), array("option_name"=>"cron"));
I have a problem with a wordpress site and I really can't figure out what causes it.
All the pages in the site load perfectly fine, they are quite stuffed with content but the load time is ok and so is memory usage as they have no problem with a 32M memory limit set in wp-settings.php.
The problem comes with the home page. It takes several seconds to load (excluding other content, just the main request) and fails (where 'fails' stands for blank page shown) unless I raise the memory limit above 300M.
Possible suggestion 1: check index.php code
Done. I replaced it with a blank page only containing the word TEST, still same slow loading and blank page.
Possible suggestion 2: disable all plugins
Done. Disabled each and every plugin and still same exact behaviour.
My current workaround
The only thing that I could find to temporarily solve the issue, is redirecting (via wordpress' internal rewrite) any request for / to a custom page which is linked to index.php. This way I have the homepage working fine, quickly and under the 32M memory limit.
Now, this works but it's a horribly dirty hack, so how can I find out what wordpress is doing when I ask for the home page before loading the template given that it has nothing to do with plugins?
If you've tried replacing index.php with just plain text then i would definitely check your .htaccess file for errors, extra characters, or some type of invalid configuration. Disable it and see if that helps for starters.
To see if anything comes out try adding WP_DEBUG=true to wp-config.php
Might show you if something else is erroring earlier
But otherwise yes kachegrind or xdebug definately
Also if on unix and you have access try strace command on the apache process
Not easy to tell, but there is a way to find out: use the xdebug profiler, and then use kcachegrind or its windows port to view its results. It will show you lots of data, including a visual chart, which will hopefully be very helpful in identifying where is PHP spending most of its time...
Is the server itself doing any pre/post processing on the homepage?
Turning on PHP errors may shed some light on the process as will looking at the httpd error log.
Out of curiosity, are you positive your site hasn't been hijacked?
I am calling a PHP-Script belonging to a MySQL/PHP web application using FF3. I run XAMPP on localhost. All I get is this:
Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again.
There are a number of possible solutions ... depends on the "why" ... so it ends up being a bit of trial and error. On a fresh install, that's tricky to determine. But, if you made a recent "major" change that's a place to start looking - like modifying virtual hosts or adding/enabling XDebug.
Here's a list of things I've used/done/tried in the past
check for infinite loops ... in particular looping through a SQL fetch result which works 99% of the time except the 1% it doesn't. In one case, I was using the results of two previous queries as the upper and lower bounds of a for loop ... and occasionally got a upper bound of a UINT max ... har har har (vomit)
copying the ./php/libmysql.dll to the windows/system32 directory (Particularly if you see Parent: child process exited with status 3221225477 -- Restarting in your log files ... check out: http://www.java-samples.com/showtutorial.php?tutorialid=1050)
if you modify PHP's error_reporting at runtime ... in certain circumstances this can cause PHP to degenerate into an unstable state if, say, in your PHP code you modify the superglobals or fiddle around with other deep and personal background system variables (Nah, who would ever do such evil hackery? ahem)
if you convert your MySQL to something other than MyISAM or mysqli
There is a known bug with MySQL related to MyISAM, the UTF8 character set and indexes (http://bugs.mysql.com/bug.php?id=4541)
Solution is to use InnoDB dialect (eg sql set GLOBAL storage_engine='InnoDb';)
Doing that changes how new tables are created ... which might slightly alter the way results are returned to a fetch statement ... leading to an infinite loop, a malformed dataset, etc. (although this change should not hang the database itself)
Other helpful items are to ramp up the debug reporting for PHP and apache in their config files and restart the servers. The log files sometimes give a clue as to at least where the problem might reside. If it happens after your page content was finished it's more likely in the php settings. If it's during page construction, check your PHP code. Etc. etc.
Hope the above laundry list helps somebody someday ... probably myself when I run into it again and come back here looking for "how the heck did I fix it last time?" ... :)
It's possible that your script could be caught in an infinite loop. If that doesn't apply, then I'd check the error logs like TimB suggested.
It sounds like the PHP script you're calling is failing without returning a valid response. Depending on the level of logging that you have set up, this should generate an error in the Apache logfile, which will give you some idea of the problem. I'm not familiar with XAMPP, but you should be able to find out where the logs are, and look for an error that occurred at the time you made your request to the PHP script.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
I solved this problem Upgrading the xampp\php\ext\xdebug\php_xdebug.dll
(changed to php xdebug v.2.0.5-5.3-vc9 )
I had the same problem and this is what i did.
I issued the http get command through php cli script, and as it turns out I had declared one class twice somewhere.
By the way , i use AMPPS on an mac
Hope this helps some one!
Try doing the request with Firebug enabled and see what info you can get out of that; I always find that using wget is helpful for seeing the raw HTTP interaction without worrying about Firefox's UI elements interfering.
If you are using certificates for ssl in Windows 2008 Server(iis 7) from old selfssl tool(iis 6), that is the problem. Sometimes Microsoft releases patches which can destruct all these old certificates. The solution is to generate them again.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
Indeed this helped me to solve this problem
The connection to the server was reset while the page was loading.
Incase the issue is not working this did the trick for me.
1. I got a new zip directory for PHP and connected it with apache
2. I searched for the libmysql in the new php and inserted this to the apache/bin
its this libmysql.dll that is needed there and not the one form mySQL/bin.
ok at least thats the one that worked.
I experienced a very similar issue - which doesn't apply to the person who asked this question - but may be of help to others who are reading this page...
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"