Lucian Maran

home

Helios versus System.Web

07 Jun 2014

Conform specificatiilor OWIN, 4 layere intervin atunci cand rulezi o aplicatie web:

OwinStack

Am sa insist aici doar asupra primelor doua.

1. Host Layer

Pentru a gazdui o aplicatie web (WebApi) pe o masina Windows ai practic doua optiuni la dipozitie:

  1. IIS
  2. SelfHost/OwinHost (o Console Application ce poate rula independent sau ca Windows Service)

Exista cateva scenarii in care SelfHost poate fi o solutie viabila (sau unica solutie). Pentru majoritatea scenariilor insa, IIS este "gazda" ideala. De ce prefer IIS?

2. Server Layer

Am stabilit ca folosesc IIS, dar acesta se ocupa, in principal, de managementul proceselor. Web Server-ul este cel care preia cererile HTTP, initiaza pipeline-ul OWIN si returneaza raspunsul furnizat de layer-ele superioare.

Daca ai ales un host de tip IIS, poti opta in continuare pt. unul din cele 2 servere: System.Web sau Helios.

2.1. System.Web

2.2. Helios

Instalare Helios

Initializare Helios

Dezinstalare Helios

3. Masurarea performantelor: Helios vs. System.Web

Pt. masurarea performantelor am creat creat o aplicatie simpla de tip Owin plecand de la un "Empty" Asp.Net project. Tot codul se afla in fisierul Startup.cs:

using Owin;

namespace Helios
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.Run(async context =>
            {
                context.Response.ContentType = "text/plain";
                await context.Response.WriteAsync("Hello World!");
            });

        }
    }
}

Alte considerente legate de conditiile de test:

In toate cazurile am folosit acelasi "stressing tool" (Apache Benchmark) si aceiasi parametri:

ab -n 70000 -c 50 http://pcdadi/ (ultimul "/" e obligatoriu)

Sunt simulate astfel 70.000 requesturi, cu 50 de clienti (thread-uri).

Doar de curiozitate, am adaugat pentru masuratori si codul de tip "Hello World" prezentat pe homepage-ul NodeJS. Am incercat ca rezultatele sa le suprapun a.i. cele 3 solutii sa poata fi cat mai usor comparate:

Nu incercati sa-l intelegeti :-), am sa-l iau pe rand:

3.1. Consum de CPU

Aici Helios si NodeJs se comporta ambele la fel de bine: se descurca doar cu jumatate din puterea de care are nevoie System.Web pentru a face acelasi job.

Am sa anticipez putin: din figura de mai sus se observa ca "turnul" cel mai ingust corespunde lui Helios. Adica, acelasi test s-a finalizat mai rapid in cazul Helios, deci ne vom astepta ca la testul "requests/sec" acesta sa ofere cel mai bun rezultat.

3.2. Rata de transfer (req/sec)

  1. Helios (5700 req/sec) - cel mai bun
  2. System.Web (4200 req/sec)
  3. NodeJS (3700 req/sec)

Faptul ca aria incadrata de cele 3 "clopote" este cvasi-identica imi ofera un argument in plus in ceea ce priveste acuratetea rezultatelor (in fiecare test nr. de request-uri a fost acelasi - 70.000).

3.3. Memoria alocata (doar "manage" memory)

Se observa ca Helios consuma de aprox 4 ori mai putina memorie, dar sa nu ne amagim. De unde provine aceasta diferenta? - din faptul ca nu mai incarca, si nu mai proceseaza "balastul" indus de pipeline-ul clasic din Asp.Net. O sa vedem asta in figura ce urmeaza.

Pe masura ce creste in complexitare, aplicatia va tinde sa devina conumatorul de memorie dominant, reducand astfel decalajul afisat mai sus.

3.4. Numarul de biblioteci (dll-uri) incarcate in memorie

Acelasi rezultat il poti obtine apeland din cod (sau in Immediate Window) metoda:

System.AppDomain.CurrentDomain.GetAssemblies()

Cu Helios, numarul de dll-uri necesare rularii aplicatiei se reduce la jumatate (20 fata de 39). Ramane insa valabila aceeasi afirmatie ca si la paragraful anterior: pe masura ce aplicatia va creste in complexitate, nr. de dll-uri ce apartin strict de aplicatie va creste, facand ca raportul dintre cele doua servere sa se diminueze treptat.

Helios si System.Web, impreuna

Punand un break point pe ultima linie din Startup.cs si urmarind apelurile de pe stiva te poti convinge ca in pipeline-ul Http nu mai apare nicio referinta la System.Web. Cele 2 biblioteci instalate (Loader.IIS si Host.IIS) fac aproape toata treaba:

In schimb, daca verifici librariile incarcate in memorie ai sa ramai poate surprins. Mult criticatul System.Web este tot acolo. De ce? Biblioteca in sine, ofera inca multe functii utile. Probabil se poate elimina complet, nu stiu. Partea buna este ca acum rolul acestui modul s-a schimbat. Din comportamentul intrusiv pe care l-a avut inainte (se "agata" de fiecare request/response http) acum a devenit o biblioteca "docila" care raspunde doar atunci cand este intrebata.

Riscuri

A trecut mai bine de jumatate de an de cand proiectul Helios a fost expus publicului dar nici acum nu exista o versiune alfa sau beta. Nici macar cartitudinea ca acest proiect nu va fi abandonat. Personal, am decis sa-l folosesc in proiecte personale, de o mai mica anvergura. Daca aplicatia iti merge pe Helios, sigur te vei putea intoarce oricand la System.Web, fara nicio bataie de cap. Desigur, reciproca (tot ce merge pe System.Web merge si pe Helios) nu o nicidecum adevarata.
Asadar, consider ca riscul este minim.

Limitari

Surse:

comments powered by Disqus