2. Introducing (How it was)
Azure Web Site
CPU-Intensive worker
role
Web site file system
DB
3. Introducing (Step 2: Scalable storage)
Azure Web Site
CPU-Intensive worker
role
Web site file system
DB
4. Introducing (Step 3: Access securing)
Azure Web Site
CPU-Intensive worker
role
Web site file system
DB
Non-authorized user
Authorized user
Middleware
proxy
x
5. Why node.js ?
• Fast for development and implementation
• Low-cost solution
• Horizontal and vertical scaling
• High-flexibility
• High-performance (…?)
DB
Load balancer
6. Performance (theoretical)
• Working in a one thread
• Creation of a 2000 blank threads can take
up than 3.7 sec (Windows 8)
• It takes ~50 mb RAM
• IO operations shouldn’t block main thread
• Proxing of traffic from storage to client works
almost at operation-system layer (when properly
implemented) – through piping from source
thread to another.
Message loop picture
7. Performance (practical 5kb)
Testing with Apache AB console utill
1000 tries in 50 threads
File size 5kb
• Storage:
• Proxy
Connection Times (ms)
min avg max
Connect: 115 120 3082
Processin
g:
127 5818 5964
Total: 242 5938 9046
Connnection Times (ms)
min avg max
Connect: 115 124 3142
Processin
g:
244 6002 8865
Total: 359 6126 12007
4800
5000
5200
5400
5600
5800
6000
6200
1 2
Storagems Proxy
Diff:
Min value: 33%
Av. Value: 3.1%
Max value: 25%
8. Performance (practical 500kb)
Testing with Apache AB console utill
100 tries in 10 threads
File size 535kb
• Storage:
• Proxy
Storagems Proxy
Diff:
Min value: <1%
Av. Value: 3%
Max value: <1%
Connnection Times (ms)
min avg max
Connect: 116 148 3100
Processin
g:
950 2063 1318
Total: 1066 2211 4418
Connnection Times (ms)
min avg max
Connect: 115 118 127
Processin
g:
965 1694 4334
Total: 1080 1812 4461
634
834
1034
1234
1434
1634
1834
2034
2234
2434
1 2
