Flickr.com - PHP/mysql case study
Introduction
Carl Henderson from Flickr.com, a very popular photo blogging service has released a pdf (not sure exactly when this was actually released) detailing the issues they faced with having a high-traffic website.
original PDF can be downloaded here
some interesting points taken from this pdf are below.
Classes, libraries, and systems used
1) smarty for templating
2) PEAR and XML for Email parsing
3) perl for controlling
4) imagemagick for image processing
5) mysql (4.0/innoDb)
6) java, for node service
7) apache 2 and redhat linux
8) 60,000 lines of PHP code
9) 60,000 lines of templates
10) 70 custom smarty functions/modifiers
11) 25,000 DB transactions/second at peak
12) 1000 pages per second at peak
unicode support
1) UTF-8 pages
2) CJKV support
Tips: don't use HtmlEntities(). Also, Javascript has patchy Unicode Support
Why php was used
1) Everything can be stored in the database, including smarty cache
2) a "shared nothing" approach (as long as php sessions were not used)
Mysql usage
Select's: 44,220,588
Insert's: 1,349,234
update's: 1,755,503
delete's: 318,439
13 select's per Insert, Update, and delete
Tips: many of the tables that needed to be full-text searched were de-normalized. This does waste space, but because it allowed for little or no joins, it made searching much faster.
Carl Henderson from Flickr.com, a very popular photo blogging service has released a pdf (not sure exactly when this was actually released) detailing the issues they faced with having a high-traffic website.
original PDF can be downloaded here
some interesting points taken from this pdf are below.
Classes, libraries, and systems used
1) smarty for templating
2) PEAR and XML for Email parsing
3) perl for controlling
4) imagemagick for image processing
5) mysql (4.0/innoDb)
6) java, for node service
7) apache 2 and redhat linux
8) 60,000 lines of PHP code
9) 60,000 lines of templates
10) 70 custom smarty functions/modifiers
11) 25,000 DB transactions/second at peak
12) 1000 pages per second at peak
unicode support
1) UTF-8 pages
2) CJKV support
Tips: don't use HtmlEntities(). Also, Javascript has patchy Unicode Support
Why php was used
1) Everything can be stored in the database, including smarty cache
2) a "shared nothing" approach (as long as php sessions were not used)
Mysql usage
Select's: 44,220,588
Insert's: 1,349,234
update's: 1,755,503
delete's: 318,439
13 select's per Insert, Update, and delete
Tips: many of the tables that needed to be full-text searched were de-normalized. This does waste space, but because it allowed for little or no joins, it made searching much faster.

3 Comments:
Any thoughts as to why they recommend, "don't use HtmlEntities()". Is it a problem with unicode?
By
Phil, at 9:07 PM
For point 10, you probably meant to say 70 custom smarty functions/modifiers.
By
Anonymous, at 7:07 PM
yep, you are correct. The typo has been fixed.
Thanks.
By
justin silverton, at 9:24 PM
Post a Comment
Links to this post:
Create a Link
<< Home