## WeBWorK Main Forum

### Problem with Static Images

by Jack Dockery -
Number of replies: 4
Over the Christmas  break Our IT people applied upgrade to ubuntu 16.04 and setup webwork (2.12) so we can use CAS. This semester, any problem with a static image is very slow to render, up to 45 seconds. All problems with Dynamic images are just fine.

For static images the hang up seems to be the time to generate the alias/link
in wwtmp/COURSE/images to the static image. Once that is generated there is no problem loading the image as you can paste that link into a browser and the image displays just fine so the link to the static image is being created, just seems to take a long time.

We have CAS turned on in some courses and not in others, this doesn't seem to make any difference.

Any help would be great as we are in the middle of the semester and have lots of frustrated students this weekend.

### Re: Problem with Static Images

by Michael Gage -
Normally I would suggest restarting the apache server, since a runaway child process can cause this kind of behavior. In this case that seems unlikely since it is only creating the images that is slow, but you should try that anywayif you haven't already.

It's possible to set up WeBWorK so that the images are served through lighttpd (a light weight server). Again I don't that is the problem but you should check how you are serving static images in any case. This will be the case if you are serving images on port 8080 or 8000. See release notes for recent WeBWorKs for details.

Having said all of that this will be difficult to debug from distance. Here is what I can tell you.

The mechanism that creates the link to the alias files is in pg/lib/PGalias.pm.
Most of this code seems straightforward and wouldn't cause a slowdown, but there is one place where PGalias checks to see if the link was actually created properly by issuing a curl or lwp-request command to ping the newly created link. That could be failing and causing a slowdown.

The actual command line for this is in site.conf where I have:

####################################################
# url checker
####################################################
# set timeout time (-t 40 sec) to be less than timeout for problem (usually 60 seconds)
$externalPrograms{checkurl} = "/usr/bin/curl -I"; #or "/usr/bin/lwp-request -d -t 40 -mHEAD "; # or "/usr/local/bin/w3c -head "$externalPrograms{curlCommand} = "/usr/bin/curl";

#FIXME there was an error using lwp-request ??? you get:
# [mgage@its-webwork-up03.its.rochester.edu]\$ /usr/bin/lwp-request -d -t 40 -mHEAD
# https://math.webwork.rochester.edu/webwork2_files/applets/geogebra_stable/geogebra.jar
# 501 Protocol scheme 'https' is not supported (IO::Socket::SSL not installed)
# and you get this even after running cpan to install IO::Socket::SSL --
# which is installed at Installing /opt/rh/perl516/root/usr/local/share/perl5/IO/Socket/SSL.pm

You can see that on my site there was some trouble with lwp-request and I switched over to curl. You can see also that when you use lwp-request there is a timeout if the ping fails. (Nothing is set using curl -- which is probably dangerous -- I'll have to go back to fix this. )

I wonder if that is what is happening on your machine. Something in the behavior of lwp-request and curl could easily have changed during a system upgrade.

Let us know what you find out.

-- Mike

### Re: Problem with Static Images

by Jack Dockery -
One more thing, I did some more testing and the
link to the static image is generated very fast, but the problem page
takes very long time to load, twice as long if there are two images in
it.  We have a problem that contains two static images, one in the problem
description and one in the hint. Whichever image is first gets shown, but the
second one does not. I played around with setting each image as the first one,
and it doesn't matter; the second image is never shown, just a broken link
that looks like: \{ image("6.2.23hint.png", width => 174, height => 90, tex_size => 500 ) \}.
When both images are called, it takes over a minute for the problem to load and
then a warning is thrown.

### Re: Problem with Static Images

by Michael Gage -
Are you using lighttpd to serve images? (there will be an uncommented reference to a url on port 8080 or 8000 in your site.conf file)

If not have you checked the behavior of the
externalProgram{checkurl} tool. (Also defined in site.conf.) If that
tool is not working for some reason it may hang until it times out.

In
https://github.com/openwebwork/pg/blob/master/lib/PGalias.pm

look at lines 766 - 791. There are some checks that can help debug the
check_url message. You can also force the check_url message to return 1 no matter what (just add return(1); to the end of the subroutine
and comment out the call to the check_url_cmd on line 788).

If that fixes your slow down problem you have localized the difficulty. After that it's a matter of figuring out why curl or lwp-request (the two
possibilities for the check_url command defined in site.conf) is not working as it's supposed to.

Hope this helps.

### Re: Problem with Static Images

by Jack Dockery -
THANKS!!! That fixed it, for some reason lwp-request for a local url doesn't work for a link that is local to the server but does if we test an external url:

Three examples:
1) checking link on the server using lwp-request on the server:

/usr/bin/lwp-request -d -t 40 -mHEAD https://webwork.math.montana.edu/wwtmp/S18M171//gif/6f220643-a8b4-333a-8fe7-96607065a064___3cd22e5e-bc29-3de2-a440-15f4fd36c705.pngwww.monta
500 Can't connect to webwork.math.montana.edu:443

2) checking an external link using lwp-request on the server
/usr/bin/lwp-request -d -t 40 -mHEAD www.montana.edu
200 OK

3) checking the link on the server using lwp-request on another 16.04 box:
/usr/bin/lwp-request -d -t 40 -mHEAD "https://webwork.math.montana.edu/wwtmp/S18M171//gif/6f220643-a8b4-333a-8fe7-96607065a064___3cd22e5e-bc29-3de2-a440-15f4fd36c705.png"
200 OK

It seems that the dynamic images are not checked for a valid url but the static ones are. If we comment out the check in PGalias and retrun 1 as Michael suggests everything seems to be back to normal.

THANKS we have had a lot of very up happy calculus students learning to be patience.

Another question: why would you want to check to see if the url is valid?

Thanks Again!