• Save
Making it fast: Zotonic & Performance
Upcoming SlideShare
Loading in...5
×
 

Making it fast: Zotonic & Performance

on

  • 7,361 views

Talk given at the Erlang User Conference, june 2013, Stockholm, about the performance of Zotonic, the Erlang Web Framework and CMS. ...

Talk given at the Erlang User Conference, june 2013, Stockholm, about the performance of Zotonic, the Erlang Web Framework and CMS.

It highlights Zotonic's architecture, performance charts and provides a glimpse into the future of this web development framework.

Statistics

Views

Total Views
7,361
Views on SlideShare
1,996
Embed Views
5,365

Actions

Likes
3
Downloads
0
Comments
0

5 Embeds 5,365

http://zotonic.com 5161
https://twitter.com 166
http://eventifier.co 29
http://www.eventifier.co 6
http://cloud.feedly.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Making it fast: Zotonic & Performance Making it fast: Zotonic & Performance Presentation Transcript

  • ZotonicMaking it fast!Zotonic & performanceErlang User Conference,Stockholm, June 14 2013Arjan Scherpenisse - arjan@miraclethings.nl
  • Lets make a website!
  • I have <? PHP ?>It is on this machine.Everyone uses it.So it must be good.Let’s use it... (and think later)
  • I use <? PHP ?>
  • I use <? PHP ?>
  • I use <? PHP ?>
  • What happened?I got mentioned on popular blogToo many PHP+Apache processesMelt down
  • I can use PHP!Of course you canUse more hardwareUse caching proxyUse xyz and a bit of abcAdd complexityAnd keep it all running, all the time
  • Same for RoR, Django...The problem is not that you can’t scaleThe problem is that you need to scaleimmediately
  • Yur site got /.ed!Many people followed popular linkA process per requestDeath by too many processes... doing the same thing!
  • Most websites are...quite smalle.g. less than a million pagesexcept for a couple of huge onesnot visited that muche.g. less than 10 pages per secondUnless linked to from popular placeRelative small set of “hot data”
  • Thats why we are making Zotonic.
  • Zotonics goalsThe frontender is in the drivers seatReliable performanceA web server should easily handle the load of 99% ofall web sitesMaximise the use of hardware, do more with lesshardware and less wattsSelf-contained, sysadmin friendlyNo external services, CDNs, caching servers,background workers.., and, no downtime
  • So, whats in the box?
  • So, whats in the box?Well, a lot :-P
  • So, whats in the box?Multiple sitesAdmin interfaceUser managementPage managementMenu editorCommentingImage managementVideo embeddingi18nE-mail sending,receiving (!)Importer modulesREST API…You name it, we(probably) got it :)
  • The request stack
  • Steps for a requestAcceptParseDispatch(match host, URL, controller)Render template(fetch data)Serve the result
  • Where is the time spent?Simple request: 7.5k/secTemplate rendering request: 10msLots of content: a lot less :pFetching data & rendering should be optimized
  • What takes time?Fetch data from databaseSimple query roundtrip takes 1 – 10 msFetch data from caching serverNetwork roundtrip = 0.5 msSo: do not hit the network or the database
  • What saves time?Dont repeat things that you could have done along time agoHTML escapingContent filtering(Zotonic stores sanitized / escaped content)
  • What saves time? pt IICombine similar (and especially simultaneous)actions into oneRequestsDB resultscalculations...
  • Where can we save timeClient-side cachingStatic filesTemplatesIn-memory caching
  • Client-sideLet client (and proxies) cache css, javascript,images etc.Combine css and javascript requests: http://example.org/lib/bootstrap/css/bootstrap~bootstrap-responsive~bootstrap-base-site~/css/jquery.loadmask~z.growl~z.modal~site~63523081976.css
  • Static filesFile requests are easily cachedChecks on modification datesCache both compressed and uncompressedversionStill access control checks for content (images,pdfs etc.)
  • TemplatesDrive page renderingCompiled into Erlang byte codeUsing ErlyDTLForked; were merging it back
  • Template 101Hello, {{ m.rsc[123].title }}This is the id of your first image:{{ m.rsc[123].o.depiction[1] }}Search query:{% for id in m.search[{query cat=person}] %}...Call the models – models responsible for cachingthose results
  • Template caching{% include “_template.tpl” maxage=100 %}and{% cache 3600 vary=z_language %}This gets cached per language for an hour{% endcache %}Whole and partial caching possibleMaxage in dispatch rules{page, [“hello”], controller_template,[{template, “hello.tpl”}, {maxage, 3600}]}
  • In-memory caching1) Memo cache in process dictionary of therequest process2) Central shared cache for the whole site(“depcache”)
  • Memo cacheIn process heap of request handlerQuick access to often used valuesResources, ACL checks etc.Flushed on writes and when growing too big
  • DepcacheCentral cache per siteETS basedKey dependencies for consistencyGarbage collector threadSimple random evictionSharing non-cached results between processesz_depcache:memo(fun() … end, 0, Context)
  • Erlang VM considerationsCheap processesExpensive data copying on messagesBinaries have their own heapString processing is expensive(as in any language)
  • Erlang VM and ZotonicBig data structure, #context{}Do most work in a single processPrune #context{} when messagingz_context:prune_for_{database, template, async}/1Messaging binaries is ok
  • Aside: WebmachineWe created a fork, webZmachineNo dispatch list copyingNo PmodsMemo of some lookupsOptimizations (process dictionary removal,combine data structures)Custom dispatcher (different way of treatingvhosts)
  • Slam dunk protectionHappens on startup, change of images,templates, memory cache flush etc.Let individual requests failBuild in artificial bottlenecksSingle template compiler processSingle image resize processMemo cache – share computationsmod_failwhaleMeasure system load, serve 503 page, retry-after
  • So, what about performance?http://www.techempower.com/benchmarks/
  • How important are these, really?JSON testSpit out “hello world” in jsonWhat are you testing?HTTP parsing?JSON encoding?Your TCP/IP stack?Well, OK, Zotonic does NOT do so well...
  • Platform x1000 req/secNode.js 27Cowboy 31Elli 38Zotonic 5.5Zotonic w/o logging 7.5Zotonic w/ dispatcher process pool 8.5Some numbersi7 quadcore M620 @ 2.67GHzwrk -c 3000 -t 3000 http://localhost:8080/json
  • Techempower conclusionsWe can improve some stuffCompiled dispatch rule / host matchingMigrate to webserver that handles binaries (Elli orCowboy)Merge Webzmachine ReqData/Context paramsCaching template timestamps – speedup freshnesscheckNot every framework implements the same test.Pose artificial restrictions on the tests?Zotonics memory-caching is fast...
  • A recent project
  • KroonappelsNation-wide voting weekendClient requested 100% availability + highperformance100k “votes” in 1 hour3x Rackspace VPS nodes, 2 GB, load balanced
  • Kroonappels1 vote was about 30 requestsDynamic i18n HTMLAjaxStatic assetsLoad test needed adjustmentsDid not push to the maxStopped at 500k votes / hr; 1.5M req/hrCustomer satisfied :-)
  • Kroonappels – made with ZynamoData layerDistribution ring based on Dynamo principlesConsistent hashing, work distributionService architecture w/ GET/PUT/DELETE semanticsLike riak_core without vnodes
  • Service oriented
  • Zynamos downsideHard...to maintain,to do cachingto write new stuffthere are DBMSs that can do this for usGot us thinking: Do we really need this scale?
  • What do we want?Multiple machines, but for error recoveryHardware errorsHardware upgradesHot failover
  • The P2P ideaTrusted P2P ring of collaborative ZotonicmachinesReliable messaging / notificationPoldercast P2P modelSynced database backups / assetsBittorrent protocol for large filesWAL for db deltasSites are vertical, data silosRun our own DNS?
  • Thank you!Book chapter: “The performance of Open SourceApplications” coming out soon (http://www.aosabook.org/)…and chat with me & Andreas :-)Come get a tshirt!Online resources:http://zotonic.com@zotonic - http://twitter.com/zotonicIRC, XMPP, mailing listsTalk slides, tutorial slides, tutorial source code...