Something I was thinking today was what if the avatars were stored in base64 rather then images in FTP. This can save a lot of storage for big board owners and allow them to not worry about forcing external avatars.
Example execution:
$avatar = file_get_contents("path supplied.png");
$avatar_encoded = base64_encode($avatar);
Could work, though you've got to wonder if the PHP processing time to encode/decode the avatars would really make it worth it?
(2012-01-11, 10:58 PM)euantor Wrote: [ -> ]Could work, though you've got to wonder if the PHP processing time to encode/decode the avatars would really make it worth it?
It would. It is a technique used by many designers and developers including myself to save load time. On sites with many many images and thousands of daily visitors calling that image each and every time can add strain to the server and anger to the user since the website is loading so slowly. For example see
this link to display WebOutfit's logo without an image. See the source for example code.
I've used data URI's before Jason
I'm just questioning if it would really be worth doing this. With a proper set of caching rules and techniques such as image optimisation, I'm sure we could achieve similar speed changes. I know that avatars load supremely quickly on my own site.
Actually storing as base64 will increase the number of bytes. Your current avatar is 4,610 bytes but base64 encoded it's 6,148 bytes.
If anything binary should be stored as BLOB, if not in the file system.
Oh gosh no, imagine all the extra calls to the database, it's going to use another "JOIN" in the SQL query to match the users who posted in a thread and their avatars in the database, then for each avatar you'll have to decode it... Either that or there will be an extra task to cache the "already decoded" avatars which will be the same as what we have now...
I'm a user, I've chosen to display 100 replies per page, the gigantic SQL query will also extract 100 avatars, and then decode each one of them, calculate the time it's going to take to do all that...
As a big board owner, I worry less about disk space then database size...
(2012-01-11, 11:18 PM)TheGarfield Wrote: [ -> ]Oh gosh no, imagine all the extra calls to the database, it's going to use another "JOIN" in the SQL query to match the users who posted in a thread and their avatars in the database, then for each avatar you'll have to decode it... Either that or there will be an extra task to cache the "already decoded" avatars which will be the same as what we have now...
I'm a user, I've chosen to display 100 replies per page, the gigantic SQL query will also extract 100 avatars, and then decode each one of them, calculate the time it's going to take to do all that...
As a big board owner, I worry less about disk space then database size...
I doubted you and tried it.
http://weboutf.it/garfield.php
Make sure you scroll down to the red notice too
.
Ya, disk space is so cheap now is it really worth it?
You're extracting the same image, So you've just decoded one image in your database, insert like 100 different images, and for each image decode it..
Don't calculate the SQL time only because that's generally easy to "SELECT" from a database, calculate the time the PHP will make to process all the "decode" requests, now add to that complexity the potential 300 visitors viewing different pages every minute, the PHP is whether going to have a heart attack, or a very slow response time
(2012-01-11, 11:29 PM)Alex Smith Wrote: [ -> ]Ya, disk space is so cheap now is it really worth it?
But the users of MyBB are cheap and purchase unreliable and slow storage. Sure, this may add a fraction of a second load time to your board which is not visible to the human eye. Would you rather have a lightweight script running your website or a lightweight script with a folder filled with high quality JPEGs taking up 20% of your server.
(2012-01-11, 11:33 PM)TheGarfield Wrote: [ -> ]You're extracting the same image, So you've just decoded one image in your database, insert like 100 different images, and for each image decode it..
Don't calculate the SQL time only because that's generally easy to "SELECT" from a database, calculate the time the PHP will make to process all the "decode" requests, now add to that complexity the potential 300 visitors viewing different pages every minute, the PHP is whether going to have a heart attack, or a very slow response time
Or a very quick response time that will add a difference not even visible to a human eye. Rethink your logic.