Thumbnail link straight to image?

[me1000]

So apparently the host says the displayimage.php uses up too many system resources (but for some reason the thumbnail page doesnt  :-\ ) anyway...

Is there an easy (or anyway for that matter, as this is kind of an urgent matter) to make the thumbnails link directly to the image itself?

I though by just removing the _thumb from the thumbnail filename and placing the remaining filename back into the link it shouldnt be that hard, but I have been digging around in the code for about 4 hours now!  :'(

Maybe someone can help me!

Thank you,

[Stramm]

http://forum.coppermine-gallery.net/index.php?topic=34360.0

[me1000]

Thanks for the link, but that isnt exactly what I was looking for.
I need something that links to the JPG itself, not the displayimage.php page..

Thanks,

[adam1701]

I'm trying to do the same thing. displayimage.php is using way too many resources and I'd like to link direct to the image. Surely there's a way! 

[Joachim Müller]

I can't see the reason why anyone would like to skip the intermediate page at all (there are much simpler photo gallery scripts that only come with a thumbnails->full-size mechanism that you could use).

[adam1701]

^ Simple reason that displayimage.php is using too many resources on my server. I'd love to keep it, but my hosts can't cope with it.

[Joachim Müller]

Find a better webhost then. Post a link to your gallery for a start.

[me1000]

Finding a better host is not really an option, this is our last host before we have to go dedicated (which would be a bit expensive)

here is one gallery,
http://voy.trekcore.com/gallery/
that is the one I have been trying to play with some

but we have 7 coppermine galleries running in total.

Thanks,

[Joachim Müller]

You're running the totally outdated cpg1.4.2, while the most recent stable currently is cpg1.4.14, so you're running 12 versions behind. Those 12 versions have been released for very valid reasons: they fixed bugs in previous versions. Upgrading is mandatory. Maybe your resource consumption issues may be fixed as well.

[me1000]

We upgraded, but that won't solve the problems according to our hosts. Could you tell us where in the PHP files the thumbnail links are made so that we can edit it? Also, if you would be able to tell us how to make a link to the larger version from a thumbnail, that would be awesome!


Thanks for your help!
I really appreciate it! 

[Joachim Müller]

We upgraded, but that won't solve the problems according to our hosts.

Really? I wonder what makes them coppermine experts...
Imo they tell you nonsense: bandwidth use is being caused by the image, which is embedded into displayimage.php and would be transfered from server to client just as well if you did as you suggested, so bandwidth can simply not be an issue.
Another possible ressource hog may be the database queries performed. However, I strongly doubt that displayimage.php is the culprit.

Actually, you have an issue - when going to http://voy.trekcore.com/gallery/displayimage.php?album=2&pos=1 I get

No input file specified.

Seems like you over edited something. Fix that, then let us take a look at your displayimage.php once it is working again.
Let's try to figure out together why your webhost thinks that displayimage.php is to blame.

[me1000]

I may have misunderstood the host, but I believe the problem was CPU consumption, not bandwidth (I will however try to get more info on this).

The reason you get the no input specified is because the host set the displayimages.php's privileges to 000.


I have uploaded the new displayimage.php but renamed it to, displayimage3.php

displayimage2.php is the file that I tried to edit (but it is the old version)


Thanks again for your help, you dont have any idea how much we appreciate it!

[me1000]

This is the so called 'abuse report': 

Hi,

This message is to advise you of a temporary block placed on your account.
The account referenced above was found to be consuming an inordinate amount
of processor time, to the point of degrading overall system performance.

While we do limit each account to no more than 25% of a system's CPU in our
terms of service, we do not actively disable accounts until they greatly exceed that number, which is what happened in this case.

It was necessary to disable your account to maintain a minimum level of proper service for everyone else. From this point, the following options are available:

a) Block heavy users of your site, if any, that may be causing excessive load.
b) Optimize scripts (php, etc) that may be consuming a large amount of cpu.
c) Upgrade to a dedicated server; your site may have outgrown a shared environment.

Please let us know if you have a solution you feel would resolve this issue. Should a solution not be forthcoming, we are happy to assist you with an upgrade to dedicated services, where your site will have room to grow without affecting other customers. I appreciate your attention to this matter. Thank you.

~~~
09:35:18 up 117 days, 7:04, 1 user, load average: 22.05, 20.75, 18.38

top - 09:35:21 up 117 days, 7:04, 1 user, load average: 21.64, 20.69, 18.38

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
23702 mysql 15 0 152m 108m 3208 S 18 2.7 18:49.64 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/gato
5275 trekcore 25 10 0 0 0 Z 7 0.0 0:00.22 [php] <defunct>
22763 trekcore 28 10 19192 8800 4108 R 7 0.2 0:00.21 /usr/bin/php displayimage.php
29106 trekcore 27 10 0 0 0 Z 7 0.0 0:00.21 [php] <defunct>
24040 trekcore 26 10 0 0 0 Z 7 0.0 0:00.21 [php] <defunct>
16259 trekcore 28 10 19116 8748 4128 R 7 0.2 0:00.21 /usr/bin/php displayimage.php
31385 trekcore 28 10 19504 9088 4084 R 7 0.2 0:00.20 /usr/bin/php displayimage.php
4433 trekcore 27 10 19512 8916 4084 R 6 0.2 0:00.19 /usr/bin/php displayimage.php
20014 trekcore 28 10 19268 8852 4084 R 6 0.2 0:00.19 /usr/bin/php displayimage.php
25236 trekcore 28 10 19456 9056 4084 R 5 0.2 0:00.15 /usr/bin/php displayimage.php
10695 trekcore 28 10 19456 8996 4084 R 4 0.2 0:00.12 /usr/bin/php displayimage.php
19606 trekcore 27 10 19456 8984 4084 R 3 0.2 0:00.10 /usr/bin/php displayimage.php
21479 trekcore 27 10 19128 8712 4084 R 3 0.2 0:00.10 /usr/bin/php login.php
4488 trekcore 28 10 19400 8980 4084 R 3 0.2 0:00.09 /usr/bin/php thumbnails.php
15034 trekcore 28 10 19408 8820 4084 R 2 0.2 0:00.07 /usr/bin/php thumbnails.php
647 trekcore 28 10 19456 8924 4084 R 2 0.2 0:00.06 /usr/bin/php displayimage.php
10871 trekcore 28 10 19488 9068 4076 R 2 0.2 0:00.06 /usr/bin/php thumbnails.php
26823 trekcore 28 10 19104 8688 4084 R 1 0.2 0:00.04 /usr/bin/php displayimage.php



The account was not suspended; rather,the source of the load was:

disabling: ./ds9/gallery/displayimage.php
disabling: ./tos/gallery/displayimage.php
disabling: ./tng/gallery/displayimage.php
disabling: ./tas/gallery/displayimage.php
disabling: ./thorncliff/gallery/displayimage.php
disabling: ./voy/gallery/displayimage.php
disabling: ./ent/gallery/displayimage.php
disabling: ./movies/gallery/displayimage.php

if that helps you any...

-Thanks Once Again!

[Joachim Müller]

So http://voy.trekcore.com/gallery/displayimage3.php?album=30&pos=0 is the original file? Then my suggestions would be:

• Turn voting off, especially for anonymous users
• Turn the filmstrip display off
• Turn your custom "news & updates" section off at the top
• Disallow search engine spiders to crawl displayimage.php by entering the corresponding lines into robots.txt

Alternatively, you could go for the pop-up solution I suggested in the first place, which will strip all those extra features of displayimage.php. As suggested: it will make nearly no difference in terms of load, CPU usage, mysql resources consumption and bandwidth usage if you use displayimage only for the sake of using it for the pop-up. Your idea to link directly to the image is nonsense and won't help at all - it will only look unprofessional.

Whatever solution you decide to use (stripping some features from the full-sized displayimage page or going for the pop-up solution), it will result in less CPU cycles burnt, less mysql queries run and less bandwidth consumed.

In fact this all means that your site is popular and that it is getting a lot of hits. You might want to consider moving hosts or upgrading your webhosting contract. If your site is very popular (which is possible as you offer popular and high quality content), it may be an alternative to consider hosting on a dedicated machine (or a virtual dedicated server).

[me1000]

ok, we have linked the image straight to the fullscreen version.

Any other tips for optimizing anything to reduce CPU consumption?

Thanks again for your cooperation!
You have really helped us a lot!

[me1000]

 

The host has shut us down again,

here is the abuse report,

Hello,

I was forced to disable the /home/trekcore/public_html/voy/gallery directory on gator227 for causing an excessive load due to multiple php processes running concurrently. Raising the load this high is against our TOS. Please reply back so we can discuss this issue further.

Attached are the logs:

[root@gator227 ~]# for d in `ps aux | grep trekcore | awk '{print $2}'`; do ls -la /proc/$d  | grep cwd; done
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
ls: cannot read symbolic link /proc/7203/cwd: No such file or directory
ls: cannot read symbolic link /proc/7203/root: No such file or directory
ls: cannot read symbolic link /proc/7203/exe: No such file or directory
lrwxrwxrwx    1 root     root     0 Nov 24 15:38 cwd
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
lrwxrwxrwx    1 trekcore trekcore 0 Nov 24 15:38 cwd -> /home/trekcore/public_html/voy/gallery
ls: /proc/1023: No such file or directory

[root@gator227 ~]# top -c
top - 15:36:46 up 127 days, 13:07,  2 users,  load average: 22.20, 21.93, 21.77
Tasks: 229 total,  21 running, 203 sleeping,   1 stopped,   4 zombie
Cpu(s):  5.9% us,  3.5% sy, 19.1% ni, 64.5% id,  6.7% wa,  0.0% hi,  0.3% si
Mem:   4143580k total,  3913328k used,   230252k free,   213384k buffers
Swap:  6289408k total,     4320k used,  6285088k free,  2689400k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23702 mysql     15   0  157m 133m 3360 S   14  3.3 180:59.79 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/gato
17207 trekcore  28  10 19648 9236 4080 R   12  0.2   0: 00.14 /usr/bin/php thumbnails.php
32295 trekcore  28  10 20044 9608 4048 R   12  0.2   0:00.06 /usr/bin/php displayimage.php
4320 trekcore  27  10 21048  10m 4120 R   10  0.3   0:00.24 /usr/bin/php displayimage.php
10698 trekcore  27  10 19580 9168 4144 R   10  0.2   0:00.21 /usr/bin/php thumbnails.php
10366 trekcore  27  10 19580 9176 4152 R   10  0.2   0:00.20 /usr/bin/php thumbnails.php
359 trekcore  28  10 19652 9244 4084 R   10   0.2   0:00.16 /usr/bin/php thumbnails.php
3011 trekcore  28  10 19896 9428 4076 R   10  0.2   0:00.15 /usr/bin/php thumbnails.php
28761 trekcore  26  10     0    0    0 Z    8  0.0   0:00.20 [php] <defunct>
12564 trekcore  28  10 19896 9468 4076 R    8  0.2   0:00.18 /usr/bin/php thumbnails.php
7736 trekcore  28  10 19896 9424 4076 R    8  0.2   0:00.14 /usr/bin/php thumbnails.php
28934 trekcore  28  10 18760 8100 4068 R    8   0.2   0:00.04 /usr/bin/php thumbnails.php
15173 trekcore  28  10 18380 7880 4044 R    8  0.2   0:00.04 /usr/bin/php thumbnails.php
14467 trekcore  27  10     0    0    0 Z    6  0.0   0:00.23 [php] <defunct>
3392 trekcore  28  10 19932 9384 4076 R    6  0.2   0:00.19 /usr/bin/php displayimage.php

Load after disabling directory:

[root@gator227 ~]# top -c
top - 15:42:53 up 127 days, 13:13,  2 users,  load average: 3.54, 10.06, 16.72

They only restricted access to a single gallery this time, and the thumbnails page was what taxed it most, but we think there were more thumbnails on that gallery than the others.

but as the displayimage page also showed up as well, can we just bypass that page entirely?  :-\


Thank You,

[me1000]

nevermind, I was able to reverse engineer the original mod, to get the results I wanted

[Joachim Müller]

As I suggested: find decent webhosting that can handle your traffic instead of crippling your gallery that way.