Register · Search · Software · Join Upload & Sell · Hosting

Moderated by: Fred Miranda
Username   Password

FM Forum Rules
FM Forums | Alternative Gear & Lenses | Join Upload & Sell   
Search Used
1 2
3
end
  

Archive 2007 · Logic of Locking AIT
  
 
Daniel Buck
Offline
Dedicated FM
Upload & Sell: Off
p.3 #1 · Logic of Locking AIT


Kit Laughlin wrote:I usually record the URLs of images I really like—Fred, will recorded URLs work once a thread is archived? cheers, KL
you may just need to save them to a folder on your machine, that's the best way to keep them viewable in the future. Some folks put watermarks on them, other folks don't. If they don't, you can always re-name the photos with the name of the photographer in case you ever want to contact them in the future.

Nov 06, 2007 at 04:48 AM
htbyron
Offline
Upload & Sell: Off
p.3 #2 · Logic of Locking AIT


Thanks, Fred!

Nov 06, 2007 at 04:54 AM
Kit Laughlin
Offline
Upload & Sell: On
p.3 #3 · Logic of Locking AIT


Daniel,

What I meant was, 'would the SAME url still retrieve an image, if that thread has been archived in the meantime?' I was thinking that the archiving process might change the link. cheers, Kit



Nov 06, 2007 at 05:25 AM
Fred Miranda
Online
Dedicated FM
Moderator
Upload & Sell: On
p.3 #4 · Logic of Locking AIT


Kit Laughlin wrote:
Daniel,

What I meant was, 'would the SAME url still retrieve an image, if that thread has been archived in the meantime?' I was thinking that the archiving process might change the link. cheers, Kit



Hi Kit,
Actually whenever the thread gets archived, it will change the link from:
http://www.fredmiranda.com/forum/topic/385342

To:
http://www.fredmiranda.com/forum/topic2/385342

However, even if you click on the first link, you will be redirected to the second link.
Take care,
Fred

Nov 06, 2007 at 06:32 AM
rico
Offline
Dedicated FM
Upload & Sell: Off
p.3 #5 · Logic of Locking AIT


I serve images to FM threads from my web server. According to the logs, FM does not access my server when I post images using the IMG UBBC. All traffic from my server is generated by browsers external to FM.

I believe the bandwidth hit to FM is caused by those images that are hosted by FM. Specifically, the PHP URL emits an HTTP header to suppress caching: this will cause all images to be refetched as readers flip between pages, or revisit the same page in a subsequent browser session.

Nov 06, 2007 at 07:09 AM
pdmphoto
Offline
Dedicated FM
Upload & Sell: On
p.3 #6 · Logic of Locking AIT


Rico, that seems contrary to what Fred says - but what do I know

Nov 06, 2007 at 08:02 AM
pdmphoto
Offline
Dedicated FM
Upload & Sell: On
p.3 #7 · Logic of Locking AIT


Seems that Fred doesn't want to make any changes or rules for his paid members (like have time expirations on images posted, number of images posted,...). That's fine for them, and understandable. Too bad he doesn't come right out and say that instead of talking about the load his server carries processing externally hosted images. He should admit that point rather than say his server get overburden by externally hosted images.


Nov 06, 2007 at 08:13 AM
Kit Laughlin
Offline
Upload & Sell: On
p.3 #8 · Logic of Locking AIT


Fred: thank you. Still my favourite web destination! Cheers and best wishes, KL

Nov 06, 2007 at 09:11 AM
TeamSK jay
Online
Upload & Sell: Off
p.3 #9 · Logic of Locking AIT


pdmphoto wrote:
Seems that Fred doesn't want to make any changes or rules for his paid members (like have time expirations on images posted, number of images posted,...). That's fine for them, and understandable. Too bad he doesn't come right out and say that instead of talking about the load his server carries processing externally hosted images. He should admit that point rather than say his server get overburden by externally hosted images.


Although I still don't understand why exactly the code is generating undue bandwidth - Given that the solution is nothing more than splitting up the thread into chunks I see no basis for accusations of anything more than some convoluted technical process that needs to be worked around. In the end this is a real win-win situation. The AIT still exists in the familiar format, its history is retained and the turn page problem will be eliminated or significantly reduced.

Nov 06, 2007 at 04:28 PM
pdmphoto
Offline
Dedicated FM
Upload & Sell: On
p.3 #10 · Logic of Locking AIT


TeamSK jay wrote:
pdmphoto wrote:
Seems that Fred doesn't want to make any changes or rules for his paid members (like have time expirations on images posted, number of images posted,...). That's fine for them, and understandable. Too bad he doesn't come right out and say that instead of talking about the load his server carries processing externally hosted images. He should admit that point rather than say his server get overburden by externally hosted images.


Although I still don't understand why exactly the code is generating undue bandwidth - Given that the solution is nothing more than splitting up the thread into chunks I see little basis for accusations of anything more than some convoluted technical process that needs to be worked around. In the end this is a real win-win situation. The AIT still exists in the familiar format, its history is retained and the turn page problem will be eliminated or significantly reduced.


It comes down to honesty. It's something I try to have myself, and something I look for in others, especially if business is involved. And this is a business for Fred. Not to mention that I am submitting my images on a host I pay to have. Fred talks about a load; I think he's giving me a load!

That's OK, I've helped him out by changing all the filenames for the images I have posted. He won't have to worry about his server getting overloaded with my external images.


Nov 06, 2007 at 04:36 PM
 



TeamSK jay
Online
Upload & Sell: Off
p.3 #11 · Logic of Locking AIT


Fred could have done a better job of opening the topic of the AIT and bandwidth but if I just look at the solution, I don't see how simply splitting the thread into chunks has any bearing on how his paid members use his service. Can you connect the data stream dots for me?

Nov 06, 2007 at 04:46 PM
htbyron
Offline
Upload & Sell: Off
p.3 #12 · Logic of Locking AIT


Paul:

I don't see any reason to disbelieve Fred's explanation that loading the pics onto the server when the thread is opened requires additional bandwidth, wherever those pictures are hosted. And in any event I believe the solution (which many of us in this thread suggested) is a reasonable accommodation of the member's goals and Fred's concerns.

I hope you will reconsider your decision to remove your images from the archived thread -- your shots are inspiring and your contributions have been significant. Please don't punish the rest of this fine community.

Tom

Nov 06, 2007 at 04:50 PM
Fred Miranda
Online
Dedicated FM
Moderator
Upload & Sell: On
p.3 #13 · Logic of Locking AIT


pdmphoto,
We have a very friendly group, so please drop your insinuations and insults. I have no reason to be dishonest about anything here and am only looking out for the best interests of the forum for all of us. Everything I wrote is based on the data I have.
Let’s get back to photography and move on. Thanks for your understanding and cooperation.

Nov 06, 2007 at 05:28 PM
brainiac
Offline
Dedicated FM
Account Locked
p.3 #14 · Logic of Locking AIT


Fred - thanks for a great web site which is one of my favourite places to go on the web. I know a lot of people feel that way.

Scrijptegs
--------------
> I believe the bandwidth hit to FM is caused by those images that are hosted by FM. Specifically, the PHP URL emits an HTTP header to suppress caching: this will cause all images to be refetched as readers flip between pages, or revisit the same page in a subsequent browser session.

I agree. FM hosted files are served as php scripts. I know from experience that doing that can be a source of slowdown. What I do whenever serving a jpeg via php is have the script that serves it simultaneously write the file to the server. If someone then requests the file again, it comes as a simple file path instead of this: http://www.fredmiranda.com/forum/message.php?Action=downloadfile&FileID=218681

Fred, why don't you try caching jpegs instead of serving them as scripts? If you like I am happy to give you my own code which does exactly that.

Image Size
----------------
Images are served in sizes wider than the browser width. The server should serve files in a size which fits. The data-size of files served will drop dramatically. Again, Fred, I am happy to give you my php/javascript code which solves this problem and will lighten the load on your servers for jpegs hosted on FM.

Wasteful output
----------------------
Looking at the page source code of normal pages here, honestly Fred, I can halve the number of bytes being served. You are not harnessing the awesome collective power of your visitors computers by using javascript to expand content. You aren't even applying DRY (don't repeat yourself) principles in CSS. On this very page, the code
span style='color:#ffffff;font-weight:bolder;font-family:verdana,Arial,Helvetica,sans-serif;font-size:14px'

appears EIGHT TIMES! That's just one of hundreds of places in this page where your html/css is really wasteful. I might even do better than halving the output for an identical result.

Javascript is so universal now that you should be building the pages like this:
function dc(uid, uname, uaddr, avatarurl, comid, text){
    write('blah blah ' + uname + )
    write('blah blah<img src="/avatars/' + avatarurl + '.jpg">')
    write('blahblah' + js_processors(text))
    write('<input type=button id=' + comid + ' value="delete">' et cetera)
}
dc(4838,'brainiac','UK',129,128376886,'Thanks Fred...')
dc(4838,'brainiac','UK',129,128376887,'Thanks again...')
dc(4838,'brainiac','UK',129,128376888,'...and again')
dc(4838,'brainiac','UK',129,128376889,'...and again')
dc(1,'Fred','USA',2,128376984,'Shutup Brainiac')

i.e. get the 3GHz beast at the other end to draw the bloody page and take the load off your server...


Connection hogging
---------------------------
It might be worth checking whether jpegs hosted on external servers are keeping the connection alive to your server while those external files slowly download. I think it's unlikely but you never know.

Voting
---------
Finally, a very nice way to reduce wastage is to introduce a voting system per comment. Look no further than slashdot.org for an example of how to do that effectively. When a visitor is only viewing the most popular comments she will be loading the server far less. I have written a comment voting system which simply allows one incremental vote per comment per ip address. As before, you're welcome to that code, or just my ideas on how to do that.

Thanks for a great site Fred. There are lots of great people here, and we want to help make FM even better, not just to make you richer, but also to save ourselves time! ;-)

Nov 06, 2007 at 08:30 PM
brainiac
Offline
Dedicated FM
Account Locked
p.3 #15 · Logic of Locking AIT


...and BTW, using a javascript function to draw comments on the client side would make it more feasible to load more than 10 comments in a page, which is one of the ongoing nuisances, since the print thread version has reduced functionality and you can't see which page a particular comment is on.

Nov 06, 2007 at 09:10 PM
brainiac
Offline
Dedicated FM
Account Locked
p.3 #16 · Logic of Locking AIT


TP. Please please please let me help you to fix this excruciating turn page bug!

Nov 06, 2007 at 09:11 PM
Fred Miranda
Online
Dedicated FM
Moderator
Upload & Sell: On
p.3 #17 · Logic of Locking AIT


Hi Richard,
Check your PM.

Nov 06, 2007 at 10:19 PM
Kit Laughlin
Offline
Upload & Sell: On
p.3 #18 · Logic of Locking AIT


Fred: from what I know of this (I host three of my own sites) everything that Richard has observed is accurate—if he were here, I'd be hiring him to optimise my sites!

good luck with this; Richard, we may have to talk off line, after February (current book deadline). Cheers, KL


Nov 06, 2007 at 10:58 PM
rico
Offline
Dedicated FM
Upload & Sell: Off
p.3 #19 · Logic of Locking AIT


Caching is a feature of HTTP (RFC 2616) without regard to whether the content is a static file or generated dynamically. The simplest bandwidth optimization for FM is the "Expires" header field which specifies when an image will be reloaded (rather than drawn from the cache of the remote browser). This hews to the so-called Expiration Model. Slightly more complex is the Validation Model where finer-grain control is possible. Click below for my visual demo:

http://patternassociates.com/rico/fmtest/a.cgi

This yields a JPEG image. On visiting the link multiple times, you will be aware when it misses your browser cache because it takes 3 seconds to download (and is progressive scan). Every browser click accesses my server for validation using an ETag header field. My demo simply invalidates your cache on the ½ minute mark.

Visit http://patternassociates.com/rico/fmtest/ for the C source code.

Nov 07, 2007 at 10:19 AM
brainiac
Offline
Dedicated FM
Account Locked
p.3 #20 · Logic of Locking AIT


Thanks for that info Rico. Is it your experience that all browsers adhere to the RFC, or is it the case that some browsers see .php?blah in the URL and fetch the file regardless of the Expires header?

It seems to me that using normal non-php file paths is still a good idea in the long run, as most hits will not be repeats.

BTW, I notice that command-R in firefox _always_ reloads the file, whereas when I just go to the URL, as you say, the browser respects the Expires header. That's good behaviour. My experience in the past is that not all browsers do the right thing in this regard, but I could be wrong about that, especially as browsers are better these days.

Nov 07, 2007 at 10:44 AM




FM Forums | Alternative Gear & Lenses | Join Upload & Sell
1 2
3
end
    
 

You are not logged in. Login or Register

  Username   Password  
Lost your password?