Bandwidth Issues with 1.5RC4 - for Pekka

[stevehof]

Pekka,

I tried to email you this but the email was returned as non-deliverable.

I and Tony Gillilan have had double the bandwidth usage since upgrading to 1.5RC4. This anomaly started the exact day of the upgrades. We are both with the same hosting company. The tech guy at our hosting company http://www.networkeleven.com looked into your code and you can read the results of his investigations below. If you’d like to contact him, use support@networkeleven.com. I’m not saying he’s correct in his assumptions but it looks reasonable to me…I'd be very interested to hear your comments on this. The tech support person worked with your code and came up with the following:

""If you want proof that the script is causing the double bandwidth hit from the site's ip, just go here:

http://www.sphoto.com/test-photo.php?photo=825

I commented out the line that pieces together all of the final HTML and displays it - so if you go to view source it is a completely blank page and the only request made for anything on the page is this:

4.27.236.202 - - [17/Jan/2005:11:44:27 -0800] "GET /test-photo.php?photo=825 HTTP/1.1" 200 39 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"

However, these two still show up at the exact same time:

66.192.180.232 - - [17/Jan/2005:11:44:27 -0800] "GET /medium/poppiespurpleflwrs7311-419.jpg HTTP/1.0" 200 123148 "-" "-"
66.192.180.232 - - [17/Jan/2005:11:44:27 -0800] "GET /medium/poppiespurpleflwrs7311-419.jpg HTTP/1.0" 200 123148 "-" "-"
(((above is my own fixed IP from my site's access logs - Steve)))

I'm going to continue looking into the script to see if I can find line is actually grabbing the images to create those lines, but hopefully that will at least put to ease any concerns that there is something wrong with the server, considering the page that someone is being displayed there and grabbed by the user's browser doesn't even have a reference to the image showing up in the access logs that is getting hit by the server's ip.

Furthermore, if I then comment out the entire section of php code that is being run by the page, the double requests stop. I will reply again when I find out what is causing it.

The first instance of the 2 accesses by the script is by the calling of the function: ee_checkthumb(0); on line 2086

ee_checkthumb is defined in file fetchsettings.php at line 1299, the culprit is line 1304:
$check = @fopen($url,"r");

At this point it's not hard to see where the problem is, they are calling fopen() using a url to the image rather than a file path, so it is creating a call to the web server.


The second instance is by line 2134 which states:
include($toroot . "viewerstyles/VIEWERSTYLE_default.php");

In order to investiage this further I created a copy of VIEWERSTYLE_default.php named test-VIEWERSTYLE_default.php

Within this file it is caused by line 17 which states:
$sizetag = @getimagesize($url,$info);

Again as above, they are calling a function by accessing the image using the url to the image and not the file path so it is creating a call to the web server.

So there are the two requests that get generated each time a request is served and why it is made. I hope that at least alleviates any concern that there is something wrong with the web server, it is quite obviously an oversight by the programmer. If I were you I would send the above to the programmer and ask them to fix it, it's really not that hard of a fix but I will not go so far as fixing their code for them after just spending over an hour investigating the above.

Just to be clear, where I referenced line 2086 and line 2134 where the calls originated this was in the file photo.php - the other lines I mentioned are in the respective files that I stated.
--
Steven
Network Eleven, LLC
http://www.networkeleven.com""

[Pekka]

Comments are here. I try to be as clear as possible.

Line 17 in viewerstyles/VIEWERSTYLE_default.php

$sizetag = @getimagesize($url,$info);
is called only when in misc settings editor you have chosen option 2 or 3. Getimagesize() function retrieves image dimensions and how much data it needs can be anything from 1K to almost 30% of image, in rare cases even more (depends on file saving). It is a PHP function which I cannot relly finetune - I do have a custom function which does the same thing, but it also needs to have some data to make up the sizes.

To debug:

You can add a line in VIEWERSTYLE_default.php line 4

print $s_imagecheckifthere;

It prints a number next to the big photo. When it is 0 (zero) the getimagesize is NOT called.

ee_checkthumb()

photo.php line 1879 (navigation thumbs)

if ($s_imagecheckifthere == "1") {
//......some code
ee_checkthumb(0);
//.....some code
}

photo.php line 2084 (big photo)

if ($s_imagecheckifthere != "0") {
ee_checkthumb(0);
}


Above code works the same a the first one, if you have set misc settings to use substitute images it checks if the image is there.

When $s_imagecheckifthere is 1 or 2 (misc setting at "3. Use EE's substitute error image for main photos only (normal performance)"), it checks existence of the big image.

When $s_imagecheckifthere is 1 (misc setting at "2. Use EE's substitute error images on all pages (slowest performance)"), it checks existence of the thumbs and big image.

When $s_imagecheckifthere is 0 (misc setting at "1. Let browsers handle error icons on all pages (fastest performance)"), NOTHING is done.

Steven from Network Eleven has found the correct code, but that was really an unneccessary feat as in earlier post http://photography-on-the.net/forum/showthread.php?t=51903&p=363502 I did mention about this setting:

"Only think I can think of which may cause this is that you have "misc settings/When image file is not found" at 2 or 3. That would make PHP check image existance and that could be added to bandwith (max 1/3 datasize per image only). But in your server it looks like above settings is at 1."

Perhaps there is a bug so that in your EE the variable is not set to 0 (setting no. 1). Above code is so simple that it is not likely that e.g. setting 1 can make those functions happen. Please check that setting and resave misc settings page. Let me know if the variable is not set properly.

One more thing:

they are calling fopen() using a url to the image rather than a file path, so it is creating a call to the web server

EE is designed to work on multiple servers over network. That is why all path functions work on URL's or FTP. That is a basic design decision made from the very start, and I still stand behind it and think it is a good one. Counting bandwidth when script calls to localhost are done - that is a design decision bandwith-counter programmers have done (obviously to get more bw counted).

Hope this helps!

[stevehof]

Pekka, Yes, I think this will help us out quite a bit. Thanks for your efforts and patience