New Relic Mobile: diferències entre la versió Lite i l’Enterprise

Bones!

Avui, un dels nostres súper clients ens ha fet una magnífica pregunta: la versió Enterprise de New Relic Mobile, val la pena? Fa unes setmanes vam fer una call d’una horeta amb els nois de New Relic, que super amablement ens van ensenyar tota la plataforma, fent brillar alguns highlights i deixant-nos bocabadats en algúns casos, i una mica psépsé en alguns altres. Però clar, una cosa és el que et diuen els comercials en una explosió de màrqueting, i l’altra és quan intentes argumentar la compra del servei de New Relic a les 8 del matí. Així que ens hem posat a comparar la nostra versió Lite amb la seva trial d’Enterprise, en busca de diferències que argumentin aquests $999/mes/app, i aquest post és el que ha sortit.

Primer de tot: nosaltres recordem haver viscut $29/mes/app. I com que som molt xafarders, hem buscat a l’Internet Archive, i hem arribat aquí. Com diria en Jorge Barroso, “que áspero”.

EDIT! Quan hem acabat el post hem mirat a veure si podiem contractar només un mes a $999, i hem arribat al pantallot que segueix. Però intentem comparar les versions Lite, Standard i Enterprise, i el link ens duu a una pàgina que no existeix, i ens fa una redirecció al princing de l’APM en comptes del mobile… és a dir, problemes. Suposem que l’Standard està desapareixent. Potser és el moment de comprar-ho?

 

New Relic Mobile Pricing

 

Bé, deixant a part el tema del preu, ara sí, és l’hora de comparar la versió Lite amb l’Enterprise. Així que let’s compare!

 

App / Interactions

La primera secció capada a la versió Lite és la d’Interactions. Aquesta pantalla ens mostra una llista de totes les pantalles de la nostra app: Activities en Android i ViewControllers en iOS. I, per cada una de les pantalles, el temps mig d’interacció. El temps d’interacció és l’estona que triga la pantalla en acabar totes les tasques: renderitzar la pantalla, baixar imatges d’internet i mostrar-les, treure dades de la base de dades, fer una petició al server, esperar, rebre el resultat, parsejar-lo i pintar-lo… També ens mostra si aquest temps de procès és en foreground o en background. Per exemple, en el cas del nostre client, la pantalla que més triga és l’Activity de Login. Vet aquí l’screenshot:

New Relic Interactions

Mirant aquest gràfic podem deduir que… no ho sé. La suma de tots els mètodes que apareixen a la taula no fa la suma mitjana d’interacció. Dedueixo que els temps d’espera a les peticions HTTP no apareixen, però… aleshores… quina és la gràcia? Si dels 8 segons d’interacció, només hi ha 43ms que afectin al foreground… doncs… no m’ajuda molt a baixar el temps total d’interacció. Per altra banda, si deixem de mirar el temps d’interacció per pantalla, sí que té sentit: pots saber quant triga cada part del cicle de vida de l’Activity, o de les crides a API’s més importants. Per exemple, si mirem la breakdown table d’aquesta pantalla…

New Relic Interactions Breakdown Table

…veiem que hi ha un onCreate() que triga 150ms de mitjana. Bad numbers! És una pantalla súper complexa, amb una estructura realment complicada, i té tot el sentit que trigui tant a executar-se l’onCreate(). Per altra banda, el fromJson() de GSON triga una mitjana de 638ms a executar-se. També és per a posar-se les mans al cap. Però ei! Els caps pensants darrere d’aquesta app han posat el parsing del JSON en background, així que aquests 638ms no penjen la pantalla, sinó que simplement, l’usuari ha d’esperar més a veure les dades. Per altra banda, també veiem que es passa un segon i mig fent quelcom a la BBDD… què serà? Gràcies a aquest gràfic, veiem què passa quelcom que es mereix estudi.   Per acabar la secció: Si en comptes d’ordenar les pantalles per temps mig d’interacció les ordenem per visualitzacions, podem arribar a altres tipus de resultats. Per exemple, en el cas del projecte que analitzem ara mateix, la pantalla més vista té unes 6 vegades les visualitzacions de la segona pantalla més vista. Així que ja tenim a on atacar si volem millorar la nostra app. Navegant per l’interface, arribem a una secció que en el cas de la pantalla de Login no apareixia: la pantalla d’Slowest Traces. Fem click a la Trace que encapçala la secció, amb 166 segons d’espera, i trobem això:

New Relic Slowest Traces

En aquest gràfic veiem que estem fent 3 peticions a la xarxa, alhora, i quant de temps estàn trigant. A més, si posem el ratolí a sobre dels Threads, també podem veure quins mètodes ens estàn consumint el temps de CPU. Pràctic? Home, sí, si tenim algún cas en que el nostre codi pot tenir un consum de CPU molt bèstia. Però no hauria de ser el cas… De fet, ho estic pensant com a desenvolupador que ja sap el què està passant, i no és la manera. Si ho penso com que sóc un analista “de fora” que ve a accelerar l’app en busca de bottlenecks, doncs sí que té tot el sentit del món, per a conéixer què està passant a l’app sense mirar una línia de codi.

App / Devices

La segona secció capada a la versió Lite és la de Devices. Hi trobarem una llista de tots els dispositius que utilitzen l’app, dividits entre mòbils i tablets. I per aquests, ordenats per interacció, o temps de resposta de les peticions HTTP, o peticions per minut, tràfic (en número de dispositius), o rate d’errors. Bé, ara per ara no m’imagino per a què pot servir, a part de per agafar molta ràbia als mòbils castanya. O per a saber quins són, i capar-los a Google Play…? Bé, he pensat en comparar el Samsung S5 amb un S2, i oh! S’agrupen per “Samsung Device”, així que… casi. Tampoc ens servirà per a capar.

New Relic Devices

App / OS

Seguim amb la pantalla d’OS. És el mateix que la de devices, però en versions del sistema operatiu. Conforme més nou és el SO, més baix és el temps d’interacció. Bé, també pot ser perquè els nous dispositius tenen millors CPU’s… o potser estic sent massa simple. Bé, sóc un home. Vet aquí l’screenshot: New Relic OS Quin pal, New Relic s’està tornant poc interessant per moments.

Network / Map

Canviem de secció: anem a temes de xarxa. Aquesta pantalla va ser de les que em va cautivar un any enllà, quan vaig veure la versió Enterprise per primera vegada. En aquest cas no posarem un screenshot del nostre cas partícular, perquè com que aparéixen els noms dels host, perdriem la bonica anonimitat del nostre client. Però ver aquí el que ens vol ensenyar la gent de New Relic:

New Relic Network Map

Què veiem aquí? La versió del mapa de xarxa de l’APM, en comptes de la de mòbils. Haurem de fer l’exercici d’imaginar com es veu la versió mòbil, però bé, el tema és que en el nostre cas, veurem a tots els hosts als que accedeix la nostra app, quantes peticions fa per minut, i quin és el temps de resposta d’aquell host. Per exemple, podem veure que Crashlytics contesta en 500ms en el millor moment del dia, i 800ms en el pitjor, amb un bonic gràfic. Doncs el mateix, amb tots els hosts, inclús les imatges a Amazon S3, la nostra pròpia API…

New Relic Crashlytics API

 

Network / HTTP requests

Les vostres pròpies conclusions here… el mateix que a la pantalla anterior, però dividit en hosts en comptes de mostrar en un mapa. Aquí, a part del temps de resposta, podem veure les peticions per minut, el temps total d’espera, els GB totals que s’han transferit… i us avanço que les dades són bestials. Ens ajuda a mirar-nos al melic i a conéixe’ns nosaltres mateixos. Per exemple, si considerem 100 les dades que envia l’app a l’API del nostre client, està enviant 10 a settings.crashlytics.com. Áspero…

New Relic Http Requests

 

Network / Errors

El nombre d’errors per host, codis d’errors HTTP (400, 500…), i tipus d’errors de xarxa (DNS lookup failed, Cannot connect to host, Secure connection failed, Timed out…)

New Relic Http Errors

Network / Geography

Aquesta secció és bestial si tens un producte worldwide: com és la salut de les teves connexions a diferents parts del món. En el nostre cas, on tenim els servidors a Gandi.net (Paris) i l’Amazon S3 a Irlanda, estàvem preocupats per com funcionava l’app a EEUU. I ens vam sorprendre! Si no haguéssim tingut aquesta eina, no hauriem pogut conéixer les dades. És veritat que amb monitis.com podem veure la salut de la nostra API des de diferents parts del món, però també és veritat que la connexió que deuen tenir ells i les que tenen els mòbils dels usuaris reals no tenen res a veure.

New Relic Geography

 

Network / Carriers

La salut de les connexions segons el carrier. No sabem si és molt útil, perquè bé… no ho canviaràs. Com a molt, podem detectar quins carriers són els més ràpids, i ei: això us agradarà!

New Relic Carriers

Network / Connection types

Aquesta pantalla mostra tres valors, que són els 3 tipus de connexió (segons New Relic…): unknown, none i wifi. No sé què ens volen dir, però ei, la resposta HTTP és més ràpida amb WIFI que amb none, però les dues són més ràpides que unknown. Ho enteneu? Nosaltres tampoc.

New Relic Connection Types

 

Usage / Versions

Res a destacar. Bé, sí: que aquesta pantalla ens mostra l’ús de les diferents versions de la nostra app, i ens permet comparar ús de CPU, memòria, tràfic… No se m’acut cap cas en què l’informació que ens mostra sigui increiblement millor que la que ens dóna Answers de Crashlytics o un Analytics. Al final, extrany és que canvii l’ús de la CPU entre versió i versió, i que no te n’hagis adonat. Bé, sí, si no ets qui ha desenvolupat l’app pots no saber-ho, i tenir la big picture del que està passant entre diferents versions pot tenir el seu sentit…

 

 

Conclusió

Home, $999 al mes són molts calers, i al final, el tema és si ho utilitzaràs al 100%. Fent aquest anàlisi hem trobat coses del nostre client que es podrien millorar, però seria per un tema d’excel·lència. És a dir, a la secció d’Interactions, hem vist que tenim un problema amb un accés a la BBDD que triga un segon i mig, i sense donar moltes voltes, hem vist un JSON que trigava uns 650ms de mitja a parsejar-se. Aquestes dades ens poden servir per a aixecar el dit quan hem fet quelcom malament i dir “tenim un problema, l’hem de solucionar”. D’altra manera, no ens n’adonariem si ningú es queixa. Però també hem de pensar que potser els objectius de negoci (com les noves funcionalitats que poden portar a majors conversions) poden ser més importants que els 650ms que triga a parsejar-se el JSON famós, i que té pinta que no es soluciona en una tarda ràpida tocant la banda del servidor.

Així que… si ets una gran empresa amb un equip tècnic fort, i amb el temps per a la millora contínua, New Relic és una bona opció. Si el teu focus és treure nova funcionalitat, potser no ho és tant. Però el que sí que pot ser una bona opció és anar fent cícles de refactoring, i gastar-se els $999 cada 6 mesos, i dedicar un temps de desenvolupament a buscar bottlenecks i solucionar-los. De fet, el tema de l’Enterprise no es pot contactar via web, sinó que ho has de parlar amb un comercial, així que no sé si això de contractar un mes cada sis mesos es podrà fer. Serà qüestió de preguntar-ho!

Bé, això és tot! Per acabar, esperem que aquest post us sigui molt útil.

Com no, si voleu preguntar-nos més coses, no dubteu en contactar amb nosaltres! :·)