The Erlang Web. An Open Source Fault Tolerant and Scalable Web Framework.2008.pdf

Page 1

The Erlang Web

an Open Source Fault Tolerant and

Scalable Web Framework

Erlang User Conference, Stockholm, Sweden

November 13, 2008

Michał Ptaszek, Michał Slaski, Michał Zajda

michal@erlang-consulting.com

Page 2

Contents

•

The reason to have the Erlang Web

•

How it works

•

Erlang Web 1.1 features

•

License

•

Scalability

•

Fault tolerance

•

Stress testing

•

Example sites

Page 3

The reason to have the Erlang Web

•

Concurrent Erlang good for web applications

•

Yaws, INETS and Mnesia

•

Same platform and share same memory space

•

MVC paradigm

•

No Erlang code in HTML templates

•

Reusable components

•

Move from early adopters to early majority

Page 4

How it works

•

Built on top of HTTP server

•

Calls controller functions

•

Expands templates with

dynamic parts

Page 5

How it works

•

Dispatcher

– regular expressions used to match on URL

regular expressions used to match on URL

•

Controllers

– functions accessed through dispatcher

functions accessed through dispatcher

•

Templates

– XHTML files and wtpl engine with inheritance

XHTML files and wtpl engine with inheritance

Page 6

How it works

•

Wparts

– tags put in templates

tags put in templates

•

Wtypes

– data types for which validation and formatting can be done

data types for which validation and formatting can be done

automatically

•

i18n support

– files with multilingual translations

files with multilingual translations

•

Request dictionary

– mechanism for accessing data from wparts

mechanism for accessing data from wparts

Page 7

Dispatcher

•

A collection of files with regular expressions

{dynamic, "^/index.html$", {main, home}}.

{dynamic, delegate, "^/user", "config/dispatcher/user.conf"}.

{static, "^/about$", "about.html"}.

{static, "^style.css$", enoent}.

Page 8

Controllers – simple case

•

Request to URL: http://hostname/app/

Request to URL: http://hostname/app/module

module/func

func

– Will use

Will use module.erl

module.erl

– Will call

Will call validate/1

validate/1 function

function

– If successful, will call controller function

If successful, will call controller function func/n

func/n

•

func/n

func/n should:

should:

– accept arguments returned from

accept arguments returned from validate/1

validate/1

– return one of:

return one of:

•

{template, Path}

•

{json, Data}

•

{redirect, Url}

Page 9

Controllers with data flow

•

The controller module should export dataflow/1 that returns a

list of functions to be called

•

Functions will be called one by one

•

If something goes wrong, error/2 function is called

•

In this way basic aspects can be implemented

Page 10

Controllers with data flow - example

dataflow(save) -> [validate, log].

validate(save,_) ->

Name = eptic:fget("post","example_name"),

case is_valid_name(Name) of

true -> {ok, [Name]};

false -> {error, bad_name}

end.

log(save, Name) -> …

error(save, bad_name) ->

{template, "templates/error/error_1.html"}.

save(Name) ->

db:save(Name),

{template, "templates/save/form.html"}.

Page 11

Templates

•

XHTML files parsed with Xmerl

•

Xmerl structures of parsed templates are stored on disk as binaries

for better performance

•

Template inheritance with wtpl engine

•

Automatic generation of forms used in CRUD operations

Page 12

Wpart

•

HTML template contains <wpart:somename />

•

During expanding the tag is replaced with value returned from

–

wpart_somename:handle_call(Element)

•

handle_call should accept the current tag as an Xmerl record

•

handle_call should return any Xmerl construct

handle_call(E) ->

Name = wpartlib:has_attribute("attribute::name", E),

#xmlText{value = “Hello “ ++ Name}.

Page 13

Wtype

•

Basic wtype

– Used for formatting and validation

Used for formatting and validation

– Wtypes for dates, integers, text, etc. are built in

Wtypes for dates, integers, text, etc. are built in

•

In template:

<wpart:lookup key="id" format="integer"/>

•

In controller function:

wtype_integer:validate({[],ID})

Page 14

Wtype

•

Complex wtype

– Used for defining data structures from the model

Used for defining data structures from the model

– Can consist of basic and complex wtypes

Can consist of basic and complex wtypes

– Can be constructed using Erlang record syntax

Can be constructed using Erlang record syntax

– Or can be constructed/updated on the fly

Or can be constructed/updated on the fly

-record(person, {id, name, age}).

-record(person_types, {

id = {integer, []},

name = {string, []},

age = {integer, [{min, 1}, {max, 140}]}

}).

Page 15

Request dictionary

•

Temporary storage created per each HTTP request

•

Implemented as ETS table

•

Stores

– GET/POST variables

GET/POST variables

– Data passed from the model to the view

Data passed from the model to the view

Page 16

License

•

Erlang Web Public License

– Derivative work of the Erlang Public License, Version 1.1

Derivative work of the Erlang Public License, Version 1.1

– Changes definition of Modifications to include also

Changes definition of Modifications to include also

wpart/wtype modules

Page 17

Scalability

•

Front End

– HTTP server

HTTP server

– Dispatcher

Dispatcher

– Cache tables

Cache tables

– Static content

Static content

•

Back End

– Invalidator

Invalidator

– Controllers

Controllers

– Templates

Templates

– Database

Database

Page 18

Fault tolerance

•

Two Back End nodes

•

running Erlang

Distributed Application

•

which registers at

Front Ends during

startup

Page 19

Stress testing

•

One machine for Erlang Web application and one for Tsung

– Intel Core 2 Due 2.4 GHz

Intel Core 2 Due 2.4 GHz

– 3 GB DDR2 RAM

3 GB DDR2 RAM

– Erlang R12-4, no hipe

Erlang R12-4, no hipe

– Suse 11

Suse 11

•

Application implemented with

– Yaws 1.73

Yaws 1.73

– Mnesia as database

Mnesia as database

– dispatcher, template inheritance

dispatcher, template inheritance

Page 20

Stress testing

•

No caching

– All requests are served

All requests are served

by back end

•

Inets http client

– Response time = 4ms

Response time = 4ms

•

Tsung (HTTP 1.1 connections)

– 185 pages / sec

185 pages / sec

•

Caching on front end

– All requests are served

All requests are served

by front end

•

Inets http client

– Response time = 1ms

Response time = 1ms

•

Tsung (HTTP 1.1 connections)

– 1000 pages / sec

1000 pages / sec

Page 21

One node, no caching

•

Pages per second

Page 22

One node, no caching

•

Response time

•

in milliseconds

Page 23

Two nodes, front end with cache

•

Pages per second

Page 24

Two nodes, front end with cache

•

Response times

•

in milliseconds

Page 25

Example sites

•

erlang-consulting.com

Page 26

Example sites

•

erlang-consulting.com

•

umbria-rentals.com

Page 27

Example sites

•

erlang-consulting.com

•

umbria-rentals.com

•

protest-project.eu

Page 28

Example sites

•

erlang-consulting.com

•

umbria-rentals.com

•

protest-project.eu

•

erlang-web.org

Page 29

Questions

Page 30

For more information and to download visit

http://www.erlang-web.org

Thank You!