Hello,
I keep encountering the same problem. My photos look great in photoshop and terrible in Preview. Also, I know that I need to save differently for my images to look good on the web, I am just lazy to do it since I am more concerned with the printed image. I haven't had a problem with printed images, but I would like the images to look good when someone opens them on a disc on their own computer
Do you mean that they look bad when uploaded to here?
If so, then yes you can optimise the pics a bit - but ultimately the 365 software does seriously degrade pictures uploaded to it. (storage space is expensive - so optimising the pics size-wise is a necessary evil I guess.)
@intymalcolm - er, no Malcolm - I wasn't referring to my storage space - I was referring to the server storage space that the owner of 365project.org has to support - if this site didn't reduce image quality it would cost Ros a lot more.
@styru My pictures also look gross on 365, but I am not as worried about that. I am sorry i didn't give more info @Inty.
So here is my big problem:
1. I open my RAW file in Photoshop, adjust levels a bit to amp up the color, contrast, etc.
2. I then open in Photoshop to finish the edit by taking away blemish, softening wrinkles, etc.
3. When I save, I save at 300 ppi so that my images can be printed poster size and at maximum quality.
4. When I go to show someone the now JPS in Preview, or if they are using windows, Windows viewer, the images are flat, dull, and slightly gray. Not exactly portfolio quality, nor reflective of what the images actually look like when printed. (I hope, although I have never had an image not print correctly.)
Is there anything I can do to make the images look better on the screen for people who don't have photo shop and think they just got some crap images from me? I hope that makes sense. I will take a screen shot right now.
Ok, I can't take a screen shot, but I think I fixed the problem on my mac. I re-did my settings. Doh! However, I am still having a problem when I try and display on a Windows system.
I wonder if this could a color space issue? If you are shooting in aRGB and making the corrections in ACR and it looks good there...when you move it to PS/PSE that prgram may only see sRGB. This could explain the gray areas.
@styru Yes, I know you were. Storage is cheap. Really cheap. Also, Preview is the default image viewer on a Mac... which is what the OP was asking about, innit :)
@chapjohn Sounds plausable. Or bit depth, maybe...
@intymalcolm Not online it's not. 1TB of storage on Amazon Web Services S3 (which is what this site uses) costs $95 per month. That doesn't include bandwidth costs to transfer that data out (required every time someone views a photo on the site).
@abirkill That's a crazy price! You can stick your own server in a rack in some random datacenter for less than that. Then bung as many TBs in it as it can handle.
Amazon, eh? Always though that was a swizz...
Hold on, though, S3? So the server's are in Ireland? I was sure, when I signed up, this site was running on hardware located in the UK. Still, as long as it's EU metal, I guess I can put up with that.
@intymalcolm I think you are underestimating the requirements for hosting a site like this. A server in a rack is not going to come even close to cutting it.
Almost all sites with the data storage and transfer requirements as large as this use systems like Amazon AWS (until they get large enough to build their own custom datacentres, e.g. Google, Facebook, etc.). They have a lot of drawbacks, but cost is very rarely one of them. As an example, SmugMug, another (albeit larger) photo sharing site estimates that switching to Amazon S3 from local storage solutions has saved them almost $1 million a year, and that was back in 2007.
They saw cost savings of $500,000 per year when they first switched, and at that time had 64 million photos. This site has, to my not-completely-uneducated guess, in the region of 2 million photos. They are also stored at lower resolution than Smugmug (for non-ace members), so clearly the savings are not going to be anywhere close to Smugmug's level of savings, but that gives you an idea of the relative cost of Amazon's storage vs. running your own redundant storage system that's fast enough to serve a large number of photos anywhere in the world.
Thinking that you can just shove a server in a rack and have it serve 2 million photos on demand within a few milliseconds anywhere in the world, while also keeping those photos reliably indexed and with assured backup capabilities, is a bit like suggesting you can use a Mini to evacuate the population of a small city.
@intymalcolm The site also uses Amazon Cloudfront, so the photos are cached on various servers around the world, and you are served from the cache that is nearest (in latency, which may not equal geography) to you. The server that sends a photo to me is almost certainly not the same server (or datacentre) that sends a photo to you.
The underlying S3 storage that the Cloudfront servers pull from is eu-west-1, which is most likely to be their Dublin, Ireland datacentre, although I don't think they guarantee that anywhere. You can see this if you check the URL for, e.g., a profile photo:
Edit: Example traceroute from Sheffield, UK (resolves to a server that looks likely to be based near London Heathrow, latency of 19ms):
traceroute to media.365project.org (216.137.63.108), 30 hops max, 60 byte packets
1 xxxxxxxxxxxxxxxxxxxxxx 0.364 ms 0.544 ms 0.618 ms
2 xxxxxxxxxxxxxxxxxxxxxx 12.433 ms 12.474 ms 12.514 ms
3 xxxxxxxxxxxxxxxxxxxxxx 13.773 ms 13.813 ms 13.852 ms
4 leed-bb-1b-ae6-0.network.virginmedia.net (81.97.80.121) 61.244 ms 45.124 ms 45.178 ms
5 leed-bb-1c-ae1-0.network.virginmedia.net (62.253.174.26) 18.165 ms 14.002 ms 18.758 ms
6 62.252.224.238 (62.252.224.238) 21.244 ms 18.677 ms 18.447 ms
7 ae13-xcr1.lnd.cw.net (195.2.10.241) 19.054 ms 19.457 ms 18.176 ms
8 ae15-xcr1.lns.cw.net (195.2.30.114) 22.127 ms 23.126 ms 23.164 ms
9 178.236.15.4 (178.236.15.4) 21.778 ms 21.914 ms 23.346 ms
10 178.236.3.55 (178.236.3.55) 23.597 ms 23.522 ms 178.236.3.57 (178.236.3.57) 21.591 ms
11 178.236.3.119 (178.236.3.119) 23.358 ms 178.236.3.117 (178.236.3.117) 22.183 ms 178.236.3.119 (178.236.3.119) 19.407 ms
12 server-216-137-63-108.lhr3.r.cloudfront.net (216.137.63.108) 20.701 ms 19.112 ms 18.647 ms
Example traceroute from Vancouver, BC (resolves to a server that looks likely to be based near Seattle, Washington, latency of 6ms):
traceroute to media.365project.org (54.240.188.224), 30 hops max, 60 byte packets
1 xxxxxxxxxxxxxxxxxxxxxx 0.438 ms 0.614 ms 0.809 ms
2 xxxxxxxxxxxxxxxxxxxxxx 4.864 ms 4.915 ms 4.970 ms
3 216-19-176-125.stc.novuscom.net (216.19.176.125) 5.026 ms 5.212 ms 5.281 ms
4 six01-sea4.amazon.com (206.81.80.147) 7.543 ms 7.914 ms 8.053 ms
5 205.251.225.164 (205.251.225.164) 8.370 ms 205.251.225.160 (205.251.225.160) 8.623 ms 205.251.225.166 (205.251.225.166) 8.894 ms
6 205.251.226.132 (205.251.226.132) 9.194 ms 5.260 ms 205.251.226.134 (205.251.226.134) 5.345 ms
7 server-54-240-188-224.sea50.r.cloudfront.net (54.240.188.224) 5.507 ms 5.901 ms 6.045 m
@abirkill Heh, I wasn't thinking a single server, clearly. A few'd do it. Stick them near the backbone and latency'd be manageable; the limit's more likely to be the last mile than the backhaul.
Though it's possible I'm underestimating the size of the site - at least the engaged user count. I'd've though a couple of thousand, tops. (I've only got a skinny hunch on that, though, from the browse by day page), so you could serve that out of a single rack... if you had to. Three'd handle it no problem.
Also, there may be a couple of million images - hell, let's call it 10 - so 5TB of data, maybe. However, most of that isn't live and so can live with a few dozen extra millis for access, so that can live somewhere cheaper - only the last couple of months is going to be hit hard. If that. Maybe even days would do.
Meh, dunno. Data at rest is something I don't tent to have to deal with so much, so I'm a bit finger in the air :)
IIRC, S3 does guarantee a data package location, though. Data protection laws vary wildly, so realistically they'd have to specify a geographical location for the data, to engage any savvy (or even shady) business types.
All of which is interesting, but - erm - don't answer the OP so much. Sorry. @sparrow.
@intymalcolm Where on the backbone? This is a global site. The minimum ping time to a site on the opposite side of the world from the requesting location is 216ms. Loading the homepage (for me, right now) makes 71 separate file requests -- that's HTML, Javascript, CSS, profile images, photos, etc. Most browsers will only multiplex at most 4 requests at a time, so that's a minimum of (71/4)*216 = 3.8 seconds just in request latency to load the page from the other side of the world from the servers -- not including data transfer time. And that assumes your user is on the backbone too. That's as opposed to (71/4)*6 = 107ms for the same requests from my Vancouver connection to Amazon's Seattle datacentre.
Talking about load, those 71 requests are all for different files -- and almost all of which are also different from the files any other user will request when viewing the home page. That means that, to serve the home page, you need to load 71 resources from different locations on a hard disk (they will not be contiguous on the disk). Just taking into account seek time for the hard disk to locate those 71 resources means that a single hard disk would take over half a second (approx 8ms seek time per file). Add on read time and a single user clicking 'home' ties up an entire hard disk for maybe as much as .75 seconds. Now work out how many concurrent users might do that at once at peak load (remember, the number of people viewing is going to be a lot higher than the number of people uploading -- I click the home page button probably 10-15 times a day at least and I only upload a photo every 3-7 days!) and work out how many hard disks (all of which need the same data accessible) to serve that load demand -- and that's just to serve the home page. Yes, there can be caching done, but that's not going to eliminate all of the contention -- you are still going to need multiple copies of the same data if you want to serve it without latency.
These are, of course, enterprise-class drives we're talking about (I hope) -- typical cheap consumer drives will not last very long at 100% utilisation. Enterprise drives cost approximately $250/TB, and as discussed, you'll need multiple copies of the data, so for each TB of storage you may need 3TB of duplication to serve the site with sufficiently low latency -- even just for the recent files. Now we're at ~$750 per TB of actual data cost.
Next up, let's talk about redundancy. Obviously we need local redundancy -- if a drive fails and we lose all the data, that's not gonna be acceptable. So we probably need a RAID 5 array with dual spare drives (the minimum considered acceptable for business-critical data), so that we can survive two failures without data loss. Now we're up to 5TB of drives for every 1TB of data -- or $1250 per TB cost. (You could use the duplication as backup instead -- if you don't mind the site grinding to a halt whenever a disk fails, and putting more load on the remaining disks)
But wait! That's only redundancy within the same data centre! It's fair to say Ross makes a nice profit from the site -- probably not enough to live on, but enough to supplement another income quite nicely. He may well rely on that profit by now -- after all, the site has been around for several years and is showing no sign of dying off. So he may have mortgages or other expenses that rely on his income from this site not dropping to zero overnight. Obviously, we need to protect against the data centre (or at least our bit of it) burning down (not unheard of), so we need to duplicate all of the data in another data centre. That's now 6TB of drives for every 1TB of data -- or $1500 per TB cost. (That's only to allow us to rebuild the site should there be a catastrophic failure in the main data centre -- it's not a system that can take over serving the data to everyone, so we will still have considerable downtime and Ace members clamouring for membership refunds)
Suddenly, Amazon S3's $1140 per year per TB cost starts to seem more reasonable. We haven't yet considered the cost of the hosting the servers, the cost of buying the servers, the cost of maintaining the servers (not just the price of replacement disks and other hardware when something fails but also, who is going to replace the failed hard drive and rebuild the array when you're on a two week vacation in another country?), the bandwidth costs of syncing the two datacentres, etc. etc.
And after all of that we *still* have a solution that is at least 216ms away from at least one of your customers. So not only does your own hosting cost more than Amazon, involve way more hassle than Amazon, it's also a whole lot slower for your customers than Amazon (unless they're lucky enough to live in the same country as the datacentre).
It's easy to think that data is cheap and companies that use Amazon are just for those too lazy to do it themselves -- but when you actually work out the costs, it can be surprising how quickly AWS or similar solutions (such as Google's cloud storage services) can pay for themselves. It's sites like this, which are big enough to not be easily served by single servers, but small enough that it's not cost-effective to start hiring technicians and building your own (small) datacentres, where services like AWS become surprisingly justifiable.
I agree that this doesn't help @sparrow at all -- I think my earlier post linking to this thread (and specifically, the second-to-last post in it by me) should answer her questions on how to switch to using sRGB in her workflow though. But if not, please do come back to us and ask!
@abirkill and just think, 100 years or so ago Babbage was still trying to invent a computer and these conversations would have been unimagined. Where to 100 years from now?
@peterdegraaff I find this short essay a good insight into the utterly incomprehensible complexity of the technology we take entirely for granted every day:
(Similar levels of complexity that are so far beyond the possibility of any one person to fully comprehend are, of course, also present in even the cheapest digital cameras)
@abirkill clever article. Could really be about the litigation between Apple and Samsung over tablets and pads. Thank goodness they weren't trying to patent cuneiform
@abirkill All of which fairly a reasonable, if sub-optimal analysis.
Except,
1) This isn't a business-critical website, it's a small 'social' site for amateur photographers, so it doesn't hava a requirement for 5 9's uptime. The occasional outage is acceptable; annoying, but acceptable. And of course it's 'global', as is ALL the Internets.
2) A reasonably configured server, configured by someone competent, would hold much more in cache that you seem to think. Indeed, assume 5000 users, with an average of one upload a day each and it's trivial to hold the last 24 hour's upload thumbnails, profile pics and comments in the backend DB's memory cache - (5000 x (2K + 20K)) == a touch over 100MB for the images, on a system with, say, 16GB of RAM this is trivial. And the comments etc are smaller than that, even. Assign a Gig for DB cache and that 8ms seek all but vanishes and we get a nice, fast homepage load... which has already been optimised to only fetch the latest 10 entries by default anyway.
4) Further, notwithstanding the caching, basing the arithmetic on the 'average seek time' assumes a FCFS disk scheduling algorithm, which is somewhat inefficient. Not even Windoze does that. Even SSTF is better... but, most likely, the OS will be using LOOK or Circular LOOK, which is much fast and reduces the average time to seek significantly. Also, of course, we're using a striped RAID array (because we're not daft) and the seek time is no longer linear and much, much faster than 8ms.
5) A reasonably well spec'd server can handle 50K request a minute, NP. Even if ALL the site users hit refresh at the same time, once a minute a single server could -- just about - handle that. (71 x 5000 < 50K, no?)
You've a point about maintenance time, though, so two live racks and lower-spec machine for backup. Job done, but with as much much space as you need. Because storage is cheap :)
Heh, and I strongly doubt that Ross get's much revenue from this site... what with there being no advertising and it being, essentially, free. :shrug:
Anyhow, as you were. :D
Write a Reply
Sign up for a free account or Sign in to post a comment.
Tweets ahoy!
Join the Group
Pin With Me
If so, then yes you can optimise the pics a bit - but ultimately the 365 software does seriously degrade pictures uploaded to it. (storage space is expensive - so optimising the pics size-wise is a necessary evil I guess.)
........................................
Feeling Blue - my 365 days of one colour - Click HERE
@styru Guess you're not a Mac user, eh? Also, I reckon £50/TB is cheap ;)
So here is my big problem:
1. I open my RAW file in Photoshop, adjust levels a bit to amp up the color, contrast, etc.
2. I then open in Photoshop to finish the edit by taking away blemish, softening wrinkles, etc.
3. When I save, I save at 300 ppi so that my images can be printed poster size and at maximum quality.
4. When I go to show someone the now JPS in Preview, or if they are using windows, Windows viewer, the images are flat, dull, and slightly gray. Not exactly portfolio quality, nor reflective of what the images actually look like when printed. (I hope, although I have never had an image not print correctly.)
Is there anything I can do to make the images look better on the screen for people who don't have photo shop and think they just got some crap images from me? I hope that makes sense. I will take a screen shot right now.
@chapjohn Sounds plausable. Or bit depth, maybe...
@sparrow See my post second from the bottom in this thread for how to adjust your workflow to use sRGB: http://365project.org/discuss/general/17770/colors-appear-different-in-365-and-facebook
Amazon, eh? Always though that was a swizz...
Hold on, though, S3? So the server's are in Ireland? I was sure, when I signed up, this site was running on hardware located in the UK. Still, as long as it's EU metal, I guess I can put up with that.
Almost all sites with the data storage and transfer requirements as large as this use systems like Amazon AWS (until they get large enough to build their own custom datacentres, e.g. Google, Facebook, etc.). They have a lot of drawbacks, but cost is very rarely one of them. As an example, SmugMug, another (albeit larger) photo sharing site estimates that switching to Amazon S3 from local storage solutions has saved them almost $1 million a year, and that was back in 2007.
http://don.blogs.smugmug.com/2006/11/10/amazon-s3-show-me-the-money/
They saw cost savings of $500,000 per year when they first switched, and at that time had 64 million photos. This site has, to my not-completely-uneducated guess, in the region of 2 million photos. They are also stored at lower resolution than Smugmug (for non-ace members), so clearly the savings are not going to be anywhere close to Smugmug's level of savings, but that gives you an idea of the relative cost of Amazon's storage vs. running your own redundant storage system that's fast enough to serve a large number of photos anywhere in the world.
Thinking that you can just shove a server in a rack and have it serve 2 million photos on demand within a few milliseconds anywhere in the world, while also keeping those photos reliably indexed and with assured backup capabilities, is a bit like suggesting you can use a Mini to evacuate the population of a small city.
The underlying S3 storage that the Cloudfront servers pull from is eu-west-1, which is most likely to be their Dublin, Ireland datacentre, although I don't think they guarantee that anywhere. You can see this if you check the URL for, e.g., a profile photo:
https://s3-eu-west-1.amazonaws.com/365production/profile/98884_sq.jpg
Edit: Example traceroute from Sheffield, UK (resolves to a server that looks likely to be based near London Heathrow, latency of 19ms):
traceroute to media.365project.org (216.137.63.108), 30 hops max, 60 byte packets
1 xxxxxxxxxxxxxxxxxxxxxx 0.364 ms 0.544 ms 0.618 ms
2 xxxxxxxxxxxxxxxxxxxxxx 12.433 ms 12.474 ms 12.514 ms
3 xxxxxxxxxxxxxxxxxxxxxx 13.773 ms 13.813 ms 13.852 ms
4 leed-bb-1b-ae6-0.network.virginmedia.net (81.97.80.121) 61.244 ms 45.124 ms 45.178 ms
5 leed-bb-1c-ae1-0.network.virginmedia.net (62.253.174.26) 18.165 ms 14.002 ms 18.758 ms
6 62.252.224.238 (62.252.224.238) 21.244 ms 18.677 ms 18.447 ms
7 ae13-xcr1.lnd.cw.net (195.2.10.241) 19.054 ms 19.457 ms 18.176 ms
8 ae15-xcr1.lns.cw.net (195.2.30.114) 22.127 ms 23.126 ms 23.164 ms
9 178.236.15.4 (178.236.15.4) 21.778 ms 21.914 ms 23.346 ms
10 178.236.3.55 (178.236.3.55) 23.597 ms 23.522 ms 178.236.3.57 (178.236.3.57) 21.591 ms
11 178.236.3.119 (178.236.3.119) 23.358 ms 178.236.3.117 (178.236.3.117) 22.183 ms 178.236.3.119 (178.236.3.119) 19.407 ms
12 server-216-137-63-108.lhr3.r.cloudfront.net (216.137.63.108) 20.701 ms 19.112 ms 18.647 ms
Example traceroute from Vancouver, BC (resolves to a server that looks likely to be based near Seattle, Washington, latency of 6ms):
traceroute to media.365project.org (54.240.188.224), 30 hops max, 60 byte packets
1 xxxxxxxxxxxxxxxxxxxxxx 0.438 ms 0.614 ms 0.809 ms
2 xxxxxxxxxxxxxxxxxxxxxx 4.864 ms 4.915 ms 4.970 ms
3 216-19-176-125.stc.novuscom.net (216.19.176.125) 5.026 ms 5.212 ms 5.281 ms
4 six01-sea4.amazon.com (206.81.80.147) 7.543 ms 7.914 ms 8.053 ms
5 205.251.225.164 (205.251.225.164) 8.370 ms 205.251.225.160 (205.251.225.160) 8.623 ms 205.251.225.166 (205.251.225.166) 8.894 ms
6 205.251.226.132 (205.251.226.132) 9.194 ms 5.260 ms 205.251.226.134 (205.251.226.134) 5.345 ms
7 server-54-240-188-224.sea50.r.cloudfront.net (54.240.188.224) 5.507 ms 5.901 ms 6.045 m
Though it's possible I'm underestimating the size of the site - at least the engaged user count. I'd've though a couple of thousand, tops. (I've only got a skinny hunch on that, though, from the browse by day page), so you could serve that out of a single rack... if you had to. Three'd handle it no problem.
Also, there may be a couple of million images - hell, let's call it 10 - so 5TB of data, maybe. However, most of that isn't live and so can live with a few dozen extra millis for access, so that can live somewhere cheaper - only the last couple of months is going to be hit hard. If that. Maybe even days would do.
Meh, dunno. Data at rest is something I don't tent to have to deal with so much, so I'm a bit finger in the air :)
IIRC, S3 does guarantee a data package location, though. Data protection laws vary wildly, so realistically they'd have to specify a geographical location for the data, to engage any savvy (or even shady) business types.
All of which is interesting, but - erm - don't answer the OP so much. Sorry. @sparrow.
Talking about load, those 71 requests are all for different files -- and almost all of which are also different from the files any other user will request when viewing the home page. That means that, to serve the home page, you need to load 71 resources from different locations on a hard disk (they will not be contiguous on the disk). Just taking into account seek time for the hard disk to locate those 71 resources means that a single hard disk would take over half a second (approx 8ms seek time per file). Add on read time and a single user clicking 'home' ties up an entire hard disk for maybe as much as .75 seconds. Now work out how many concurrent users might do that at once at peak load (remember, the number of people viewing is going to be a lot higher than the number of people uploading -- I click the home page button probably 10-15 times a day at least and I only upload a photo every 3-7 days!) and work out how many hard disks (all of which need the same data accessible) to serve that load demand -- and that's just to serve the home page. Yes, there can be caching done, but that's not going to eliminate all of the contention -- you are still going to need multiple copies of the same data if you want to serve it without latency.
These are, of course, enterprise-class drives we're talking about (I hope) -- typical cheap consumer drives will not last very long at 100% utilisation. Enterprise drives cost approximately $250/TB, and as discussed, you'll need multiple copies of the data, so for each TB of storage you may need 3TB of duplication to serve the site with sufficiently low latency -- even just for the recent files. Now we're at ~$750 per TB of actual data cost.
Next up, let's talk about redundancy. Obviously we need local redundancy -- if a drive fails and we lose all the data, that's not gonna be acceptable. So we probably need a RAID 5 array with dual spare drives (the minimum considered acceptable for business-critical data), so that we can survive two failures without data loss. Now we're up to 5TB of drives for every 1TB of data -- or $1250 per TB cost. (You could use the duplication as backup instead -- if you don't mind the site grinding to a halt whenever a disk fails, and putting more load on the remaining disks)
But wait! That's only redundancy within the same data centre! It's fair to say Ross makes a nice profit from the site -- probably not enough to live on, but enough to supplement another income quite nicely. He may well rely on that profit by now -- after all, the site has been around for several years and is showing no sign of dying off. So he may have mortgages or other expenses that rely on his income from this site not dropping to zero overnight. Obviously, we need to protect against the data centre (or at least our bit of it) burning down (not unheard of), so we need to duplicate all of the data in another data centre. That's now 6TB of drives for every 1TB of data -- or $1500 per TB cost. (That's only to allow us to rebuild the site should there be a catastrophic failure in the main data centre -- it's not a system that can take over serving the data to everyone, so we will still have considerable downtime and Ace members clamouring for membership refunds)
Suddenly, Amazon S3's $1140 per year per TB cost starts to seem more reasonable. We haven't yet considered the cost of the hosting the servers, the cost of buying the servers, the cost of maintaining the servers (not just the price of replacement disks and other hardware when something fails but also, who is going to replace the failed hard drive and rebuild the array when you're on a two week vacation in another country?), the bandwidth costs of syncing the two datacentres, etc. etc.
And after all of that we *still* have a solution that is at least 216ms away from at least one of your customers. So not only does your own hosting cost more than Amazon, involve way more hassle than Amazon, it's also a whole lot slower for your customers than Amazon (unless they're lucky enough to live in the same country as the datacentre).
It's easy to think that data is cheap and companies that use Amazon are just for those too lazy to do it themselves -- but when you actually work out the costs, it can be surprising how quickly AWS or similar solutions (such as Google's cloud storage services) can pay for themselves. It's sites like this, which are big enough to not be easily served by single servers, but small enough that it's not cost-effective to start hiring technicians and building your own (small) datacentres, where services like AWS become surprisingly justifiable.
I agree that this doesn't help @sparrow at all -- I think my earlier post linking to this thread (and specifically, the second-to-last post in it by me) should answer her questions on how to switch to using sRGB in her workflow though. But if not, please do come back to us and ask!
https://plus.google.com/112218872649456413744/posts/dfydM2Cnepe
(Similar levels of complexity that are so far beyond the possibility of any one person to fully comprehend are, of course, also present in even the cheapest digital cameras)
Except,
1) This isn't a business-critical website, it's a small 'social' site for amateur photographers, so it doesn't hava a requirement for 5 9's uptime. The occasional outage is acceptable; annoying, but acceptable. And of course it's 'global', as is ALL the Internets.
2) A reasonably configured server, configured by someone competent, would hold much more in cache that you seem to think. Indeed, assume 5000 users, with an average of one upload a day each and it's trivial to hold the last 24 hour's upload thumbnails, profile pics and comments in the backend DB's memory cache - (5000 x (2K + 20K)) == a touch over 100MB for the images, on a system with, say, 16GB of RAM this is trivial. And the comments etc are smaller than that, even. Assign a Gig for DB cache and that 8ms seek all but vanishes and we get a nice, fast homepage load... which has already been optimised to only fetch the latest 10 entries by default anyway.
4) Further, notwithstanding the caching, basing the arithmetic on the 'average seek time' assumes a FCFS disk scheduling algorithm, which is somewhat inefficient. Not even Windoze does that. Even SSTF is better... but, most likely, the OS will be using LOOK or Circular LOOK, which is much fast and reduces the average time to seek significantly. Also, of course, we're using a striped RAID array (because we're not daft) and the seek time is no longer linear and much, much faster than 8ms.
5) A reasonably well spec'd server can handle 50K request a minute, NP. Even if ALL the site users hit refresh at the same time, once a minute a single server could -- just about - handle that. (71 x 5000 < 50K, no?)
You've a point about maintenance time, though, so two live racks and lower-spec machine for backup. Job done, but with as much much space as you need. Because storage is cheap :)
Heh, and I strongly doubt that Ross get's much revenue from this site... what with there being no advertising and it being, essentially, free. :shrug:
Anyhow, as you were. :D