SitePoint Sponsor

User Tag List

Results 1 to 15 of 15
  1. #1
    SitePoint Enthusiast
    Join Date
    May 2005
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    WAMP: Only 1 script per time served. How to handle multiple requests?

    Hi guys,

    When I do a simple script that takes 10 secs to run:

    test.php :

    for ( $counter = 1; $counter <= 10; $counter += 1) {
    echo $counter."<br>";
    sleep(1);
    }

    my entire server hangs!
    While the first script is running, if i load another script, it will just say "Waiting for server.name...." and only execute after the first script is done.

    I tried googling, and one of the solutions is to increase my MAXCLIENTS in my httpd.conf.

    However,
    a) There is no such line in my HTTPD.conf
    b) adding such a line prevents my apache from starting up.

    I am using:
    Windows
    Apache 2.0
    Php 5.2.6

    Appreciate any help offered.

    Thanks

  2. #2
    SitePoint Enthusiast
    Join Date
    May 2005
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi, just an update to the above...

    While the 10 sec script is running, loading a STATIC file (for example, a small jpg) is fine. However, running another small PHP script (hello-world.php), will only execute once the first script is done....

    Is this how php works??

  3. #3
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Are you using sessions, or any other external resources in this php script? The code you posted(nothing more) should not behave as you stated.

  4. #4
    SitePoint Enthusiast
    Join Date
    May 2005
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi crmalibu,

    Thanks for the reply.

    No, no sessions at all. There is nothing but the loop code as per above.

    Something else i found though!

    If i run both requests within ONE browser, it will achieve the abovementioned behaviour.

    However, lets say i run one instance in Firefox, and another in IE, the IE one will load fine!

    Is there some kind of "scripts executed per client" limit that I am facing?

  5. #5
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Browsers do have some max connections settings. I would be suprised if one of them was set to only a single connection though. In FF you can check this by typing about:config into the address bar. Look at the network.http* settings.

    I would imagine that theres probably some apache setting, or module that might try to limit connections per client as well.

  6. #6
    SitePoint Evangelist
    Join Date
    Jun 2006
    Location
    Wigan, Lancashire. UK
    Posts
    523
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sprockett View Post
    Is there some kind of "scripts executed per client" limit that I am facing?
    No, but the number concurrent connections to web servers is limited by most browsers. IE7 (I believe) sets a limit of 8.
    ---
    Development Projects:
    PHPExcel
    PHPPowerPoint

  7. #7
    SitePoint Enthusiast
    Join Date
    May 2005
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Mark, crmalibu, thanks so much for your responses. I realize that this is a browser caused problem.

    Yes, I checked out FF and as per crmalibu's reply, there are a multitude of network.http*maxconnections* type settings, typically in the range of 8-15.


    This would explain how FF allows me to run simultaenously:
    1. single instance of the script
    2. multiple other static image requests


    However, FF still only allows only ONE instance of a PHP script to be loaded at anytime.
    Should it not be 8? (assuming max connections per server is 8)?

  8. #8
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    do a phpinfo()

    is session.auto_start on?

  9. #9
    SitePoint Enthusiast
    Join Date
    May 2005
    Posts
    60
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by crmalibu View Post
    do a phpinfo()

    is session.auto_start on?
    GENIUS!! PURE GENIUS!!

    that was it!!! swtiched off autostart, and script now loads up to 8 instances

    Thanks a billion crmalibu!

  10. #10
    SitePoint Guru
    Join Date
    Dec 2005
    Posts
    982
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    session:auto_start only prevents multiple requests from the same user/session, correct?
    MySQL v5.1.58
    PHP v5.3.6

  11. #11
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, but it's not related to session.auto_start

    In order to solve the concurrency issue, php obtains an exclusive lock on the session file(one file per session id) when you call session_start() and doesn't release the lock until session_write_close() is called. php automatically calls session_write_close() when your script exits if you haven't already closed any open session.

    since session_start() needs to obtain an exclusive lock before doing any reading or writing, it will just sit there and wait*, blocking further script execution until it gets its lock.

    So it's not really anything specific to session.auto_start, because you will experience the same behavior when manually calling session_start(). auto_start just calls session_start() for you.

    *I've come across systems where php won't wait for a lock, instead it just immediately fails and loads an empty session array, which of course it will try to save when session_write_close() gets called, which generally means you lose all your session vars. I don't know if this was a bug that was fixed, it was quite a while ago.

  12. #12
    SitePoint Guru
    Join Date
    Dec 2005
    Posts
    982
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's what I thought would be the cause. It makes sense though -- you don't want two scripts making changes to a session at the same time or else you could end up with the bug you described happening.
    MySQL v5.1.58
    PHP v5.3.6

  13. #13
    SitePoint Enthusiast zombat's Avatar
    Join Date
    Jun 2008
    Location
    Victoria, BC
    Posts
    63
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by crmalibu View Post
    Yes, but it's not related to session.auto_start

    In order to solve the concurrency issue, php obtains an exclusive lock on the session file(one file per session id) when you call session_start() and doesn't release the lock until session_write_close() is called. php automatically calls session_write_close() when your script exits if you haven't already closed any open session.

    since session_start() needs to obtain an exclusive lock before doing any reading or writing, it will just sit there and wait*, blocking further script execution until it gets its lock.

    So it's not really anything specific to session.auto_start, because you will experience the same behavior when manually calling session_start(). auto_start just calls session_start() for you.

    *I've come across systems where php won't wait for a lock, instead it just immediately fails and loads an empty session array, which of course it will try to save when session_write_close() gets called, which generally means you lose all your session vars. I don't know if this was a bug that was fixed, it was quite a while ago.
    That is very interesting behaviour. I wasn't aware of that, thanks for sharing crmalibu. I've always been a fan of using file-based sessions just for simplicity, but this seems like it would be a good reason to move session handling to a database for a read-heavy site that stores a lot of session information.
    PHP/MySQL programmer for hire!
    http://www.zombat.net

  14. #14
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Usually, you wan't/need this behavior. Otherwise you may end up with corrupted/stale/out of state session data. If you need concurrent reads for performance(doubtful, how often do you need thier browser to load two pages which both use sessions simultaneously?) then you can just take care to call session_write_close() manually in those specific scripts as soon as you're done modifying session variables if there's still quite a bit more script execution time to be done.

    You're free to start>save, restart>save the same session multiple times per script.
    PHP Code:
    session_start();
    // do stuff, read vars etc...
    session_write_close();

    // do something that takes a long time....


    session_start();
    // now update sesson vars with the result 
    This way you aren't locking out other scripts from reading the session data while you perform some lengthy task(for example, any kind of network IO can potentially take a long time, same with downloads etc...). Of course, if the other scripts that could be running at this moment might need the combined result of the first and second update to the variables though, you wouldn't want to do this, you need them to wait. An example could be if you serve large downloads from a php script, and use session variables to control access to these files. If it takes 5 minutes to download the file, and you don't close the session before you start dumping the data to them, then they won't be able load any other pages which use sessions for 5 minutes, the pages will just hang. So you would start the session>read the vars to authenticate them>close the session>output data. Then if you need to update a session var again, for example to keep track of thier filenames downloaded this visit, you can just start the session again after the data has finished being output so you can update vars.

    You almost always wan't this locking behavior. Without it, or if you program without considering the implications of not having it, you're more likely to introduce those kinda subtle bugs that your users complain about that you just can't ever seem to reproduce.

  15. #15
    SitePoint Guru
    Join Date
    Dec 2005
    Posts
    982
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Very cool tip crmailbu.
    MySQL v5.1.58
    PHP v5.3.6


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •