From: Patrick M. <li...@5e...> - 2005-03-26 22:51:47
|
Ok, I did some tests myself and here is what I discovered: The Flash player seems to accumulate the calls for a frame. The correct way to see this is adding a call to NetDebug::trace("In method now"); in the invoked remote method. This will add a single trace header per request. So if you call 20 remote methods, and you see only one trace in the NetConnection debugger, there was only one call. If you call 20 remote methods, and see 20 trace actions in the NetConnection debugger, that means it was sent as separate calls. Any number between 1 and 20 traces means the call was split into several batches. Now I tried with deferred (next frame) calls and while I saw several traces in the NetConnection debugger, it still showed the odd behaviour with sleep. So it seemed either that: 1. The web server or PHP is single threaded (unlikely) 2. The Flash player was waiting for a remote response before sending the next request (just as unlikely) But in fact it's none of the above. I verified this by doing packet sniffing using TCP Spy and multiple calls with sleeep(1) in some methods and not in others. As it turns out Flash opens a limited number of connections; on my system, using the standalone version or the ActiveX in IE or the plugin in Firefox, it creates 2 connections. That means that Flash has a limited number of channels to send data through. So if one is blocked, (for example by a sleep) and the other one is clear, data will continue to be passed in the clear channel. As soon as both channels are blocked it will seem as though Flash or Apache or PHP are single-threaded, when in fact it's a question of number of open connections. I wanted to test this theory by doing the following: Create a service with two methods, one called method1 and another called method2. Method1 contains sleep(10) and method2 is empty. They return either 1 or 2 so we can easily see which returns before or after. So I created a Flash file that would call method1 and then call method2 in a setInterval(200). In theory, every return from method2 should come before method1. On the other hand, if I would call method1 two times (seperated by an interval to disable batch calls) before the method2 setInterval, it would, in theory, block borh channels. Now here is the caveat: the player in the IDE and the standalone/plugin/ActiveX players behave differently. In the IDE, it waits for both calls to come back before starting to send new ones, while in the standalone, as soon as one channel is free it starts a new request. If you test the above in the standalone, it will work as expected, but not in the IDE. While I was working with this, I noticed that when a connection is interrupted, the number of headers int is replaced by garbage, and it can severally crash AMFPHP and Apache if error_log is on, so I solved that issue (ie: it used to make the error log grow by 20 megs per AMFPHP call). So please download the new bleeding edge version for that issue now solved. http://www.5etdemi.com/uploads/amfphpbeta.zip Patrick JesterXL wrote: > Ok, I tried what your blog entry said, Patrick, but the next frame ignores > sleep... like, check this out: > > - call ping, it returns true > - call 100 pings, and the 101st is another function, all done in a while > loop returns the calls in the exact order I sent them. > > ...however, if I call the function that makes PHP sleep for 10 seconds, and > then call ping over 1 frame later, it still waits for the sleep to end. So, > waiting a frame does not solve the sleep issue. > > :: tests on PHP 5 server :: > > Yep, same there too. PHP4 is running Apache & Linux something, PHP5 is > being run on IIS on Windows 2k I think. > > My Java co-worker at work said that it's up to the webserver or servlet or > whatever to determine how the webserver performs... but this appears to me > that PHP is single-threaded and just eats things in the order it receives > them. This seems kind of lame (again); is this a PHP thing or what? > > --JesterXL > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > amfphp-general mailing list > amf...@li... > https://lists.sourceforge.net/lists/listinfo/amfphp-general > |