I’ve been hacking away at this for the last few days and finally figured that I need some help. I’ve installed the hosted version of Pagetest (tried on both W2k3/W2k8), with Apache 2.2 and PHP5.
User account is created and URLBlast is running fine. I submit a test and “pagetest.exe” is a launched and processes the URL. The problem happens with the results. URLBlast is writing the results into: C:\Documents and Settings\All Users\Application Data\urlblast directory. The hickup is apparently occuring when trying to unzip the files. The results never show up in the:
C:\web site\content\results.… directory. For example the latest test was in C:\web site\content\results\10\01\12\18
And apparently the script is removing all files after it attempts to extract. Maybe it’s not getting the path correctly? I’ve removed all “delete” permissions from “C:\Documents and Settings\All Users\Application Data\urlblast” and files do remain in there. If I copy them manually to results, that works fine…but sort of defeats the purpose.
Check your apache access logs and see if there are any messages about progressimage.php or workdone.php. Urlblast posts the zip file (and progress images) to the web server and then cleans them up after they are done. The unzipping of the files is done on the server side in php.
If I was to guess I would say that the maximum file upload size for php or apache is preventing the uploads but it could be something else as well.
If the access logs don’t have anything useful let me know and I can get you custom php files that log debug information about what is going on.
Upload/Post size was 8M/8M, which should be more than sufficient. Apache access logs don’t show anything interesting. No references to workdone.php. I’ve been looking at that file, but don’t know enough about PHP to figure out quickly how to write the path variable to a file… I am guessing that it might be trying to write to a nonexistent directory, but in theory that should show up with 404s in Apache.
If you have those custom files with debugging, that would be great.
Attached are updated workdone.php and resultimage.php files. They are built off of what is currently in the tip of SVN though so they may not work with your install (in which case you can either pull the latest from SVN here: [url=http://code.webpagetest.org/svn/webpagetest]http://code.webpagetest.org/svn/webpagetest[/url] or just take the logMsg parts out from the attached files and put them in yours) .
You should end up with a log.txt file in the work folder that has the logged data.
Hmm…I’ve added the additional LogMsg lines to the existing script and I don’t see the data being logged anywhere. The only log entries that I have are in: urlBlast_MachineName_log.txt and 20100113.log. Which are:
Hmm…I’ve added the additional LogMsg lines to the existing script and I don’t see the data being logged anywhere. The only log entries that I have are in: urlBlast_MachineName_log.txt and 20100113.log. Which are:
Hmm…I’ve added the additional LogMsg lines to the existing script and I don’t see the data being logged anywhere. The only log entries that I have are in: urlBlast_MachineName_log.txt and 20100113.log and they are the sames ones as before.
Sounds like the post isn’t making it through at all (which it sounds like is the case from what you saw in the access logs as well). Try adding debug=1 to urlblast.ini and see if the urlblast log file displays any more useful information (you’ll need to restart urlblast). Depending on what build of urlblast you have the debug code might not be in there (in which case I can post the latest build which does have it enabled).
Arghhh. The problem is fixed. My apache was running on port 8080 and I did specify that in the urlblast.ini, but when you said that the post isn’t making it through, it kind of clicked to try a default port and viola.
Is port 80 hardcoded somewhere? Maybe the guide should specify that the webserver can only run on the default port.
Anyway, thank you for the help and spending time on this.
doh. I did have a bug a while back with the ports (where it was just using the default for wininet). I thought it was fixed but either I haven’t released the fixed version yet or (more likely) it isn’t 100% fixed. It sounds like it was working for getting the work but the post side was broken so I must have missed something on the fix.
I opened a new bug and I’ll get it fixed in the next release. Sorry abouut that (and glad you got it working).
I am guessing that it might be trying to write to a nonexistent directory, but in theory that should show up with 404s in Apache.