For 4 years I work on some image heavy projects. I started clueless. Now, when I look at first works they are not so good, though I have seen far worse implementations of such sites. Such sites have quite a lot common bottlenecks that can be solved using some of the “design patters”.
The top problems in no particular order are as follows:
- Disk space
- Throughput
- Speed
- Memory
Although disk space is cheap nowadays, it is still important for couple reasons, namely in shared/vps hosting it is limited, or when considering backup solutions. So you should not store images bigger than needed, though you will need creating various formats used for site.
These additional formats are needed to save from one of the biggest bottlenecks in the image heavy websites, that is image processing. I have seen lots of websites that scale the images dynamically on each image view. That’s flawed approach. You will need lots of processing power, and the pages will always load slower. Converting images should be done once, either on upload or on specific event.
Should you save original images is up to you, but I would recommend stripping unnecessary information from them and compressing to ~70% quality or so if they are JPEG. That would not impact their visual appearance too much, but will save lots of space. In some cases this is not applicable.
You should never scale images using image tag attributes or styles, or the image will look like crap. Also, this will not save bandwidth. Always create formats required for site, in the worst case you will regenerate images when you need them.
Another thing related to speed of image site is its disk access. Although there are RAIDs, on very busy sites that’s not enough. So sooner or later you will have to think how to serve images from another server than dynamically generated content (php scripts/db). This can be done in various ways, for example using network disks mapping your infrastructure, though the best way around is using separate subdomain for static content.
There is one more quite unexpected load -eater as well. That is logs. I would not recommends switching logs off, but you should minimize the amount you write to error log. We managed to reduce loads by 1/3 by just fixing single banner with wrong URL. Use full URIs if you have to. But check the logs after you code, please.
There is another reason having statical content served on separate sub domain. The reason is memory. A typical apache process takes around ~30-50m. And it serves both complex php scripts and tiny icons used in design. So, using lighthttpd or similar simple and very fast web server for static content is quite useful. Then you can focus on servers disk qualities than memory amount. It is even useful keeping these 2 webservers running on same physical server through 2 IPs. On the long term you will notice significant load decrease, limited by disk access alone.
It is quite strange that most of the commercial server setups do not take this into account. Most usually, control panels use single web server (aka Apache) for hosting all the contents and you have to setup everything manually.
0 Comments