1. MongoDB E-Commerce
Case Study: Totsy
Mitch Pirtle
MongoChicago - October 20, 2010
Chicago, IL

2. About this session

3. About the speaker
New Yorker
Contributor to many FOSS projects (Joomla! founder)
Budding author
MongoDB for Web Development
Extreme Joomla! Performance
High-traffic projects (Jetsetter, MTV, Food Networks)
Husband, dad, skate punk, metalcore bassist, coach

5. About the team

6. What is MongoDB?

7. What is MongoDB?
Document database

8. What is MongoDB?
Document database
Wicked fast speed

9. What is MongoDB?
Document database
Wicked fast speed
Great for scale

10. What is MongoDB?
Document database
Wicked fast speed
Great for scale
Low administration requirements

11. What is MongoDB?
Document database
Wicked fast speed
Great for scale
Low administration requirements
Encourages simple code, fewer bugs

12. www.totsy.com
Private sale website catering to parents with
small kids

13. What is Totsy?
Launched last year
Relies heavily on
organic growth
Stampede traffic
patterns - high peaks,
deep valleys
Leading player in their
market segment

14. The challenge
Get out of initial outsourced platform
Didn’t scale
Didn’t perform
Didn’t work
Brittle, difficult to manage or enhance
Essentially a case study on how not to use RoR,
PostgreSQL and Heroku

15. The Original Plan™
Use Joomla! as an application container
Use MongoDB for all non-Joomla! data
Build custom Joomla! extensions, all using MongoDB

16. “Oh yeah, we’re probably
dead in a couple weeks
without the new
platform.” :-)

17. Hey, wait a minute.

18. How about a framework?
One layer lower, with much less overhead, and
only using what we wanted and nothing more...

19. The New Plan™

20. The New Plan™
Primary need was speed and scale, of which the
previous effort was an #epicfail

21. The New Plan™
Primary need was speed and scale, of which the
previous effort was an #epicfail
Tap into existing personal network of PHP talent

22. The New Plan™
Primary need was speed and scale, of which the
previous effort was an #epicfail
Tap into existing personal network of PHP talent
Leverage relationship with MongoDB and Lithium
projects

23. The New Plan™
Primary need was speed and scale, of which the
previous effort was an #epicfail
Tap into existing personal network of PHP talent
Leverage relationship with MongoDB and Lithium
projects
Fully showcase MongoDB, and finally have a site with
no relational engines needed

24. Yippy skippy.

25. Yes, I really said that.

28. What was expected

29. What was expected
Rapid development

30. What was expected
Rapid development
Fast execution of code

31. What was expected
Rapid development
Fast execution of code
Spartan hosting requirements

32. The Result

33. The Result
Extremely rapid development

34. The Result
Extremely rapid development
Extremely speed

35. The Result
Extremely rapid development
Extremely speed
Extremely minimal hosting requirements

36. The Result
Extremely rapid development
Extremely speed
Extremely minimal hosting requirements
K.I.S.S. and all the goodness that entails

38. Development profile

39. Development profile
Small team: 1 designer, 1 front end developer, 2
engineers and 1 contract engineer

40. Development profile
Small team: 1 designer, 1 front end developer, 2
engineers and 1 contract engineer
Three months active development

41. Development profile
Small team: 1 designer, 1 front end developer, 2
engineers and 1 contract engineer
Three months active development
Redmine + Git for project management + version
control

42. Development profile
Small team: 1 designer, 1 front end developer, 2
engineers and 1 contract engineer
Three months active development
Redmine + Git for project management + version
control
Local, Development, Test, Production environments

43. Stack profile

44. Stack profile
PHP: fast execution, quick prototyping

45. Stack profile
PHP: fast execution, quick prototyping
Lithium: PHP 5.3+ RAD framework

46. Stack profile
PHP: fast execution, quick prototyping
Lithium: PHP 5.3+ RAD framework
MongoDB: whack-daddy database from tomorrow

47. Stack profile
PHP: fast execution, quick prototyping
Lithium: PHP 5.3+ RAD framework
MongoDB: whack-daddy database from tomorrow
LightTPD: fcgi lightweight webserver

48. Stack profile
PHP: fast execution, quick prototyping
Lithium: PHP 5.3+ RAD framework
MongoDB: whack-daddy database from tomorrow
LightTPD: fcgi lightweight webserver
Xcache: PHP opcode cache

49. Stack profile
PHP: fast execution, quick prototyping
Lithium: PHP 5.3+ RAD framework
MongoDB: whack-daddy database from tomorrow
LightTPD: fcgi lightweight webserver
Xcache: PHP opcode cache
Linux: defacto standard operating system in
datacenters

50. Atomic Operations with
MongoDB

51. Your relational data
Whoah Nelly!
Good reason for a DBA
Many foreign keys
Need for triggers,
stored procedures,
cronjobs...

52. With a side of MongoDB
K.I.S.S.
Simple to manage
Simple to access
Little or no need for
foreign constraints

53. What MongoDB did for me.

54. What MongoDB did for me.
Encouraged extremely simple data model, producing
tighter, faster, bug-free code.

55. What MongoDB did for me.
Eliminated the need for cache.
Really. No kidding.

56. What MongoDB did for me.
Used GridFS for all file storage. Lithium happily
provided a media adapter allowing us to create a
GridFS plugin to transparently store files in the
database.

57. What MongoDB did for me.
Removed worries about a complicated hosting
environment

58. What MongoDB did for me.
Bought us a ton of time to carefully deliberate next
steps, and come out of permanent crisis mode

59. What MongoDB did for me.
Allowed us to commit every possible crime required for
survival in a frantic, frenetic startup environment

60. Crimes? What crimes?

61. My shameful story

62. My shameful story
code code code commit code pray commit code code

63. My shameful story
code code code commit code pray commit code code
Models had no schema defined

64. My shameful story
code code code commit code pray commit code code
Models had no schema defined
No time for optimization or performance testing

65. My shameful story
code code code commit code pray commit code code
Models had no schema defined
No time for optimization or performance testing
Not a single line of code was run through a harness

67. So what is Lithium?

68. Lithium PHP framework
http://lithify.me
http://rad-dev.org/lithium/wiki
Projects demonstrating MongoDB support:
http://rad-dev.org/lithium_mongo/source
http://rad-dev.org/lithium_blog/source

69. Why Lithium?

70. Why Lithium?
Leverages the latest and greatest features and
practices found in PHP 5.3+

71. Why Lithium?
Leverages the latest and greatest features and
practices found in PHP 5.3+
Extremely modular, everything in Lithium is a plugin

72. Why Lithium?
Leverages the latest and greatest features and
practices found in PHP 5.3+
Extremely modular, everything in Lithium is a plugin
Native hooks into MongoDB and other non-relational
databases

73. Why Lithium?
Leverages the latest and greatest features and
practices found in PHP 5.3+
Extremely modular, everything in Lithium is a plugin
Native hooks into MongoDB and other non-relational
databases
Simple hooks for additional customization (GridFS...)

74. Why Lithium?

75. Why Lithium?
Promiscuously opinionated framework

76. Why Lithium?
Promiscuously opinionated framework
Test harness provided

77. Why Lithium?
Promiscuously opinionated framework
Test harness provided
Simplified prototyping

78. Why Lithium?
Promiscuously opinionated framework
Test harness provided
Simplified prototyping
li3_docs - Dynamic code documentation

79. Why Lithium?
Promiscuously opinionated framework
Test harness provided
Simplified prototyping
li3_docs - Dynamic code documentation
Many other helpful plugins available and growing

80. What kind of speed?

81. What kind of speed?
One evening right when a bunch of major sales
launched, I saw 1,700+ operations per second on the
MongoDB master server.

82. What kind of speed?
One evening right when a bunch of major sales
launched, I saw 1,700+ operations per second on the
MongoDB master server.
This server had a load of 0.68.

83. What kind of speed?
One evening right when a bunch of major sales
launched, I saw 1,700+ operations per second on the
MongoDB master server.
This server had a load of 0.68.
This translates to 17% capacity on a four core
machine.

84. What kind of scale?

85. What kind of scale?
We’re using multiple servers for redundancy only.

86. What kind of scale?
We’re using multiple servers for redundancy only.
When we need to add servers, the effort will be greatly
simplified by having sharding already provided.

87. What kind of scale?
We’re using multiple servers for redundancy only.
When we need to add servers, the effort will be greatly
simplified by having sharding already provided.
Probably could have launched on this laptop with
identical performance.

88. A quick note on single
server durability.

89. </rant>

90. Questions and Excuses

91. Thanks!
Email: spacemonkey@mongodb.org
Twitter: @mitchitized
Web: http://www.mitchitized.com/
Slides: http://www.slideshare.net/
spacemonkeylabs