Forum Moderators: coopster
I'm returning reformatted rows retrieved from a MySQL database HASH table, via a remote SCRIPT src=... tags on the parent HTML. The script retrieves and buffers the entire result regardless of size in less than 1 second -- the maximum return size is around 160 Kbytes (~900 lines, no table, just BRs) -- using document.write().
Obviously, I used JavaScript because the return is dynamic, and can return a different list based on different values that are passed to the PHP.
Here's the issue -- when I test the parent HTML page locally over the LAN, everything works perfectly, however, remote clients seem to have trouble either rendering or recieving the longest JavaScript result based upon the speed that the TCP transfer is taking place -- for example, a dialup (or other bandwidth challenged) client will not render the 160K JavaScript at all, but will render any result less than ~64 Kbytes, moreover, I will see the request for the PHP in the Apache log, however, the returned bytes will be inconsistent, sometimes less than the actual return value, but sometimes it will be complete.
So I guess the question is if there are limitations of size or retrieval time placed on remote JavaScript (src=) loading by clients -- I've noticed some clients, load the entire file, but will not render the contents, others will cause a PHP exec timeout (does transfer time count?) when the script timeout is less than the time it would take to transfer the script to the browser, although the PHP script is actually done in less than a second (ends with a return;, but also tried exit; and die();).
Over the LAN with every client I try, there is no problem.
I've also tried different things with regards to output buffering, implicit flushing, and sending multiple document.write()'s for each line instead of just one to encapsulate the whole output -- and it doesn't really matter much -- In every case, the smaller result sets are always rendered while the large set is not. It may also be important to note that it is an all-or-nothing kind of thing, I never get partial rendering by the browser, it either shows what it is supposed to, or the client sees nothing.
One more really important thing is that loading the script URL directly in the the browser always exposes the JavaScript code in it's entirety.
I can include links to illustrate if that would help.
The PHP can also return the exact same info as full a HTML doc, and that always works as expected regardless of the return size. Paginating the result so it returns less data to the client also works without drama, but is not the workaround I was looking for, It also does not seem to matter if I use the Apache Module PHP or the CGI version.
JavaScript line limit? Time Limit?
Output Buffers [us3.php.net] may also be of help here.
Good luck!
others will cause a PHP exec timeout (does transfer time count?) when the script timeout is less than the time it would take to transfer the script to the browser
This does not count toward PHP time limits [php.net]:
Note: The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running.
I use JavaScript because the purpose of the PHP is to embed HTML text into a site where remote PHP+MySQL is not supported (ie: most free public servers and ISP PWPs). I could use an IFRAME for this and return straight HTML code directly from PHP, but IFRAME options are not as consistent between browsers as I would like (the ones I need anyway).
The buffering also works differently than it appears -- I call ob_start() at the very top of the PHP, and ob_end_flush() right before the final return; -- it actually seems like the script is blocking at that point (script's end) until the buffer data is recieved by the client, or until Apache can buffer the whole thing (or what's left). I can certainly add additional output after the ob_end_flush() and check the timestamp, but it's likely that the script is waiting at the explicit return; -- what do ya think?
I feel it's totally an issue of speed and/or time -- with respect to bandwidth, more data takes more time.
I have written the JavaScript outputs to .js files and served it through several Apache HTTPd's as a plain file, and the result is the same (the small ones work, the biggie does not), what I still can't figure is if it is the time to transfer, or the time to render (due to size) that the JavaScript client is rejecting. Maybe the client will not attempt to execute and render the JS code if it hasn't recieved the entire JS block in a certain amount of time? Remember, this works like tables in a way, the parent HTML page cannot be complely rendered until the JS SCRIPT tag is resolved.
I'll do some tweaking to the PHP code to find out exactly how much data a JS client can/will accept in one SCRIPT tag, then I'll touch the code to force it to lag to see how long various JS clients & browser rendering engines will wait to complete a SCRIPT object.
I'll report what I find out.
I have written the JavaScript outputs to .js files and served it through several Apache HTTPd's as a plain file, and the result is the same (the small ones work, the biggie does not), what I still can't figure is if it is the time to transfer, or the time to render (due to size) that the JavaScript client is rejecting.
OK, seems we are both on the same page as far as PHP goes then -- PHP seems to be a non-issue.
I think you are right in that it has something to do with your JS file and/or the size of it and how the browser is handling it. However, I also know that some of the Rich Text Editors that are written in JS are quite large yet they load and function without issue.
You might need to pose your question in the JS Forum and see what the experts there have to say about the matter.
The parent page that calls the PHP/JS is a different HTTPd from the PHP HTTPd, but only on a different port, such that the DNS name is the same, so the returned JS returns HREF tags relative to the parent HTML -- this shouldn't matter since that's what I want it to do and the context of the links should be rendered by the browser relative to the parent page, right?
What's really knocking my noodle is that I've tried to make the JS output rediculously large (well, at least 10x my largest possible return size ~1 Mbyte), and still the same -- the LAN-speed load has no trouble whatsoever regardless of size, while a bandwidth limited load will fail to render the script returned text at all (I see the request in the Apache log for the full data value) -- moreover, it will not render the NOSCRIPT stuff either in such a case, so it seems like it knows it can do it, but it just does not for some reason.
I'm also wondering if the HTTP headers returned with the JS text have anything to do with this behavior, in particular, I know that the server returns an Expires: header, and the server does not do any compression -- wonder if the browser will reject the script SRC if it arrives already expired (yesterday) or about to expire soon (access plus...)? I also want to check if the Apache is sending a pragma: no-cache header, and if it matters any. It would be interesting to know how SCRIPT SRC targets are handled by the browser's cache algorithm.
I also tested the returned Content-type: text/plain vs. application/x-javascript, and it made no difference.
