I run a php script from xampp portable on windows. The script takes over a minute. Recently, the script is having flush() problem, as echo statements are not immediately displayed. The script used to work fine earlier with no buffering problem.
Interestingly, I ran the same script copying the xampp portable to another system and the flush statements were working without any problem. Same code, Same xampp portable.
What could be the reason?
Make the first line of your script ob_implicit_flush();.
or
Change the php.ini file setting implicit_flush = On.
From the documentation:
implicit_flush boolean, FALSE by default. Changing this to TRUE tells
PHP to tell the output layer to flush itself automatically after every
output block. This is equivalent to calling the PHP function flush()
after each and every call to print or echo and each and every HTML
block.
When using PHP within an web environment, turning this option on has
serious performance implications and is generally recommended for
debugging purposes only.
I read other responses and you keep insisting on the fact that your home environment and your work environment are the same. However, you can see that there is a difference. This point of view really help (at least to me) to investigate problems.
Since you did not provide many details about the problem, I would try the following checklist:
Settings
Is your PHP settings really identical? Try to compare results of phpinfo() on both environments.
Data
Do you really test your script on identical data? There are many subtle problems that are described in PHP manual:
Even the browser may buffer its input before displaying it. Netscape, for example, buffers text until it receives an end-of-line or the beginning of a tag, and it won't render tables until the tag of the outermost table is seen.
Some versions of Microsoft Internet Explorer will only start to display the page after they have received 256 bytes of output, so you may need to send extra whitespace before flushing to get those browsers to display the page.
http://php.net/manual/en/function.flush.php
or
http://www.php.net/manual/en/function.ob-flush.php#90529 (commenters point out many problems that you may experience)
Try dummy plaintext data instead of HTML. You may try to output simple lines like current time and check behaviour of your script.
Browsers
Try a few browsers (with cleared cache) to see if the issue is browser-specific or not.
I think it may be your browser. Have you cleaned the temporary settings of Iron Portable browser?
this occurs when you use gzip and there is some output have been send so the browser get confused to solve this , i uses this code always
if (isset($_SERVER['HTTP_ACCEPT_ENCODING']) && strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') !== false)
{ob_start('ob_gzhandler'); ob_start();}
else
ob_start();
You have not mentioned about the versions of windows both the systems running. Are the systems completely identical?
You also said that you are running a portable version of XAMPP , if you are using a pen drive/thump drive there is a chance that data transfer speeds can vary due to USB speeds.
I had a similar issue where the First system had USB legacy ports and the second one I tested has usb 2+ ports or higher.
The speed and processing time changed based on the systems, while one system took 20 seconds , other took nearly 60 seconds to process.
The slow system produced undesired results [I was working on an image processor].
I guess your case is similar and had to do a lot with the system vitals.
Cheers
Clain
I figured out that the problem is with antivirus. I recently switched to Bitdefender from Avast. When I switched back to Avast, the problem disappeared miraculously. So, i guess antivirus is also a factor here.
Related
I recently ditched XAMPP on my Windows 10 machine and re-installed Apache (2.4), PHP 7 and MySQL manually (I followed the instructions given here in order to be able to switch between PHP versions easily).
Everything works fine, except that now when I make a change in a PHP file and hit Refresh in the browser, the change often doesn't appear immediately in the browser. No matter how hard I hit F5 (or Ctrl+F5), I still get the non-modified source code, and I have to wait a couple of minutes before those change are finally visible to the browser.
Needless to say, it's quite annoying when developing. And it didn't happen when I was using XAMPP.
So there seems to be some kind of cache somewhere, but I can't find where it is. I don't know if it's Apache or PHP, although I suspect it might be PHP, because the CSS or JS files are not affected by this problem (as far as I can tell).
Any idea what's causing this behavior and how to disable it?
EDIT: I did some more testing.
I created the simplest PHP file possible. Just:
<?php
echo 'test1';
I can confirm that the problem occurs even in this simple case (changing "test1" to "test2": the browser still shows "test1" for a while).
Opening the same page in another browser still shows the outdated code (test1 instead of test2).
Clearing the browser cache doesn't help.
So the problem doesn't seem to happen on the client side.
However, if I do the same test with an HTML file instead of a PHP file, then the problem doesn't occur. Any change done to that file is visible immediately in the browser (of course I'm still accessing this file via Apache, so http://localhost/some-path/test.html)
So the problem seems to affect only PHP files.
It seems the problem was caused by the OPCache module, which I had to enable in order to work on another (drupal 8) project.
In php.ini, the following line:
; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=60
Changing 60 to 1 (and restarting Apache) basically solved the problem.
random.php
$min=1;
$max=13031;
$ran_num = mt_rand($min,$max);
echo $ran_num;
This is working fine on my local host, but when I run it on my server, it always return the same number. not sure what is going on.
Update:
I am running a wordpress site, and I put the random.php in the theme folder.
I also have eaccelerator installed, this might be the issue, I am looking into it now
If your server has PHP lower than 4.2 - you need to call to mt_srand before you can use mt_rand
By default modern PHP creates different number for mt_rand (it's uses libc random number generator), so the problem can be somewhere else.
This can likely to be caused by some caching, for example check the followings:
clear your web browser caching (use private mode or use different browser),
disable Varnish (if it's in use),
check whether code is using memory caching like Memcached/Redis,
this may be related to PHP cache accelerators (but less likely),
restart your web server just in case (could be some extra caching module),
make sure you're editing the right file and it was deployed properly,
test it in the smallest possible PHP code.
Wordpress may use cache, and if you reload the page, it loads from cache, so you will see the same random number again and again. It has nothing to do with PHP version in this particular case - to fix this, it is needed to disable the wordpress cache.
UPDATE 1:
After doing an strace on the server, I have discovered that the mmap's process is taking 90% of this processing time. I've discoverd that 1 of the pages is taking a minute to load.
So I found this link:
PHP script keeps doing mmap/munmap
It possibly shows the same problem. However, I don't understand what the anwer means by correctly disabling the php error handlers?
ORIGINAL QUESTION:
How do I check for bottle necks on my web server when loading a specific web page which is being served by my server?
For some reason, a couple of pages on my site have become very slow, and I am not sure where the slowness is happening.
Screenshot from Chrome Dev Tools:
Click here to enlarge:
So basically, I need to find out what is taking this section to long to load? Client Side web tools can't seem to break this down?
Xdebug: Profiling PHP Scripts - pay attention to KCacheGrind tool or, alternatively, you can use Advanced PHP debugger apd_set_pprof_trace() function and pprofp to process generated data file.
Derick Rethans (author of Xdebug) released quite a nice article today called What is PHP doing?
It covers the strace that you've already done, but also shows you how you can use a custom .gdbinit to get the actual php function name that is causing the problem.
Of course you have to run your script from the command line with gdb, so I hope that your problem is reproducible in this way.
mmap is for creating a memory mapped view of a file.
If it really is the error handler causing it, I'd guess that your script is generating a lot of errors (which you are trying to log), maybe a NOTICE for an undefined index in a loop or something).
Check the log file (is anything being logged at all?), check permissions on the log file if nothing is logged, also double check what your error reporting level is set to.
var_dump(ini_get('error_reporting') & E_NOTICE); - Non-zero if you are reporting notices.
error_reporting(E_ALL & ~E_NOTICE); - Turn off reporting notices.
I would suggest looking into Xdebug profiling. The other two answers deal with client side loading issues but if your bottleneck is server side it won't become apparent from the use of those tools.
You may also want to look into the database queries that are being run to serve the pages in question. You could be missing an index somewhere which would explain a recent slowness with specific pages as your database tables grow in size.
I would extract those queries and run them using MySQL EXPLAIN (assuming you are using MySQL) to see if there is slowness there.
Using an application such as Fiddler or YSlow Firefox addin will help identify slow loading elements in your website. This should make any issues apparent.
http://fiddler2.com/fiddler2/
https://addons.mozilla.org/en-US/firefox/addon/yslow/
Hope this helps
Page Speed for Chrome is also an option:
https://developers.google.com/speed/docs/insights/using_chrome
I think I may have found a bug in PHP's crypt() function under Windows.
However: I recognize that it's probably my fault. PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror.)
So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.
The setup
I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.
I don't see anything in php.ini related to crypt(), but will happily answer questions about my config.
The problem
Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.
Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.
As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.
I saw that PHP's latest version lists this bugfix:
Fixed bug #51059 (crypt crashes when
invalid salt are [sic] given).
So I created a very simple test script, as follows, using the same salt given in an official example:
$foo = crypt('rasmuslerdorf','r1');
echo $foo;
This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.
Effect on Apache
When these pages hang, Apache's server-status page (which I explained here, regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'
Eventually, Apache may crash. When it does, the Windows crash report looks like this:
szAppName: httpd.exe
szAppVer: 2.2.14.0
szModName: php5ts.dll
szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,
// but that didn't fix it
offset: 00a2615
Is it my fault?
I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.
However, my argument in favor of 'it's PHP's fault' is:
I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case
There was recently a bug with crypt(), so maybe it still has issues
I have made the simplest test case I can, and I still have the problem
Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?
Thanks in advance for any help you may give.
The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.
However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.
By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).
This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.
Therefore, with some hesitation, I have filed a bug report:
Bug #51666 - Using crypt() makes Apache hang or crash
Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.
Yes. It's a known bug,
http://bugs.php.net/bug.php?id=50947
You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.
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"