Hoping someone has some ideas around what to do with this.
We have a application thats PHP based hosted in IIS.
There are a number of functions that need to run which can be running for 10mins+. The problem I have is that if I run one of these functions in my web browser. If I open another tab and try to access the site while that is happening then it just sits loading until the long process finishes and then it loads the page.
I guess this is more of a multi session thing to my browser? Is there some easy option in IIS I can change that will let it load the other pages as normal? Or is this a browser thing?
It seems if I open an in private window at the same time, that will load normally.
The issue is related to the session. by default PHP session use a file system.so that has to wait for the session file to be closed before they can open new. Therefore, subsequent requests for the same session wait on prior requests.
To resolve the issue you could try the below things:
-close the session when you are done with it by using the session_write_close()
-Implement a custom DB handler which utilizes the database instead of the file system.
Reference:
FastCGI on IIS7... multiple concurrent requests from same user session?
Related
When i´m doing a request to a "huge" page with a lot of data to load, and make a second request to a "normal" content page, the normal page is blocked until the "huge" is loaded.
I activated the Profiler and recognized that the FirewallListener was the blocking element).
Profiler Screenshots (Loaded huge, switched tab - loaded normal)
Huge
Normal
While the "huge" page was loaded, i did a mysql php request on cli with some time measurements:
Connection took 9.9890232086182 ms
Query took 3.3938884735107 ms
So that is not blocking.
Any ideas on how to solve that?
Setup:
php-fpm7.2
nginx
symfony3.4
It is been blocked by the PHP Session.
You can't serve to pages that requires access to the same session id.
Although once you close/serve/release the session on the slow page, another page can be served on the same session. On the slow page just call Session::save() as soon as possible on your controller. This will release the session. Take into consideration that everything you do after saving the session will not be stored in the session.
The reason the firewall takes so long is that of debug is enabled.
In debug, the listeners are all wrapped with debugging listeners. All the information in the Firewall is being profiled and logged.
Try to run the same request with Symfony debug disabled.
We had a similar problem. When sending a couple of consecutive requests to the server in a short period, the server became very slow. I enabled the profiler bar, and a lot of time was spent by the ContextListener
The problem was that file server access on our server is very slow, and session information was stored on the file system, as is the default for symfony.
I configured my app to use the PdoSessionHandler, and the problem was gone.
I'm using PHP to download a (big) file from a remote server and this download is triggered by clicking on a download button on a web page.
So when i click the download button on the web page, then an Ajax request (with angulars $http) is made to a PHP function. That function triggers a download using cURL.
In the mean time I'd like to make other requests to my PHP site with Ajax. But all other Ajax requests show the status Pending as long as the download is in progress.
So basically the download is blocking every other request to PHP. Is there any way I can avoid this blockage?
This is most likely due to the session file being locked. This is a very common oversight on many php-based web-apps. Essentially, when you call session_start() to access the $_SESSION array, it opens the session file in the tmp directory in read/write mode and locks this file to avoid potential concurrency issues. If you call another script from a different ajax request (or any HTTP request, such as from a new browser window), if that second request also calls session_start, it will wait until the session file is unlocked before moving forward.
The fix is to release the session file once you know you are no longer going to be writing to it. Since your use-case is a huge file download, it is unlikely that during the data output you will need to push anything into the $_SESSION array. You release it from write-mode by calling session_write_close()
I had no idea this was the case until I found out a popular web-app I frequently use was guilty of this. A great blog post on this common bottleneck is:
http://konrness.com/php5/how-to-prevent-blocking-php-requests/
Caveat: I realize this is potentially a server configuration question, but I thought there might be a programmatic answer, which is why I am posting here...
Running PHP on Apache, our users were able to issue multiple concurrent requests (from different tabs in the same browser, for example).
Since moving to FastCGI under IIS, this is no longer the default behavior. Now, when a user starts a request to the server and the browser is waiting for a response, if they open a new tab and start another request, the new request is not processed by IIS until the previous request is completed by IIS.
If the user opens a different browser and logs in (which starts a new session for that user), concurrent requests are possible.
My question is: is there a way to configure FastCGI/IIS7 that will allow multiple concurrent requests from the same user session? If not, is there an alternative that would allow this?
The problem is the session mechanism, most likely. PHP Sessions, by default, since they are using the file system, have to wait for the session file to be closed before they can open them again. Therefore, subsequent requests for the same session wait on prior requests, or to give another example in addition to yours, if you had a frameset page (shudder) with three frames, each referencing the session, they would all load one at a time, because each page would have to wait for the session mechanism.
Possible Solutions:
As soon as you're done with the session, call session_write_close()
Implement a custom DB handler which utilizes the database instead of the file system.
It looks like I'm out of luck, at least running PHP under FastCGI on Windows: PHP FastCGI Concurrent Requests
I'm not quite sure how to phrase this question correctly, so I'll start with the scenario I encountered.
I have a bit of processing in my web app that takes longer than I'd like the user to wait to have control of the page again, so I decided to have it processed by an ajax request.
The problem is, even though I offloaded this request into an ajax request, it seems that apache won't process any further requests until the original processor heavy request is complete.
I originally wanted to know how I could get around this issue, but have since decided that it might be a bad idea in general.
However, I'm still curious if anyone knows why apache behaves this way, and what (if any) configuration directive controls it. My original thought was KeepAlive, but disabling that didn't seem to change the behavior.
I am running php through mod_php if that makes a difference.
I appreciate any help getting pointed in the right direction!
Are you using file-based sessions? PHP will lock session files for each request and maintain that lock until you do a session_write_close() or the script terminates/exits. The side effect of this is that all requests become serial, since they're all contending for the same single resource (the session file).
I am sure it's the session file. I have the same problem. I run a request that is long such as a PHPMyAdmin SQL insert which takes multiple minutes to process. While it is processing I try to open a new tab in the same browser and go to any page on my website and it will not go there until the original PHPMyAdmin request is done.
If I open an incognito window in Chrome which is the same browser it works fine. If I open the website in any other browser it is fine.
So it is probably the file based session which is the default for PHP.
Others have mentioned going to memcached. You could also save sessions in the database.
Before having to go to memcached you could do all the session based stuff at the beginning. Copy the session variable into a temporary variable so you can close it then close it. And then if you need to set a session value later open it and make the change and then close it quickly.
Can you point to evidence that it's apache? Unless your apache setup isn't optimal, most likely your page wait is something else, maybe you have set your ajax call to be non-async?
I have an application on an Apache2. The applications plays some media files like video files, mp3 files and wav files using a php file in order to avoid direct download from not-registered users. Now, I'm having problems because during the media file is loading, I cannot go to another page on the application until the media file is fully loaded.
I don't know if it's an issue about Apache2 or PHP. Can anybody help me to find out a solution for this issue? It seems that the same client cannot load two instances of PHP pages in the same site.
I'm looking forward your answers. Thanks in advance
If you are using session, I suggest you session_write_close() before you output the file to the browser.
This is because when the session is opened on one page, you cannot load another page until the session has been written and released. session_write_close() is called automatically when your script ends, but because your outputting process takes time before your script end, your session file is locked and thus other pages cannot be viewed.
However, if you are using different browser and/or system, it will be ok because the session file locked is unique to each SESSION ID.
Look at: http://php.net/manual/en/function.session-write-close.php
However do take note that after session_write_close(), you cannot call session_start() or there will be an E_WARNING warning. Also if you make changes to $_SESSION, it will not take effect.