cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Which analyzer for Websockets calls in dcrum?

r_muresu
Participant

hi, we have an application that makes extensive use of websockets calls. Currently I don't see detailed information from these calls. there is a particular analizye to use for this ?

5 REPLIES 5

sandrine-extern
Advisor

Bonjour,






Je suis actuellement absente du bureau.


En cas d'urgence, merci de contacter le pilote de l'équipe VAM : Stéphane Aguero.






Cordialement,


r_muresu
Participant

Bonjour , pas de problème ... rien d'urgent . Je vous informe que demain je ne suis pas dans le bureau parce que j'ai un tournoi de tennis . mais vous pouvez contacter mon meilleur assistant Marco La Rocca . Merci et bonne journée

ulf_thornander3
Inactive

Salut

I'm guessing that HTTP, SOAP or XML would be what you need.

If you are running 12.3, you can let the wizard guide you and it will tell you if it can find some structure in the packets that match against a decode.

If that is not the case and you know it's transactional data in the packtes, you can then craft your own decode using the Universal Decode.

wojciech_kurek
Inactive

Roberto,

Websockets are usually part of a larger HTTP server, handling regular HTTP requests as well. It's not possible to separate analysis of regular HTTP traffic and Websocket traffic. Since the HTTP decode does not have native Websocket support, below are the possible routes you could follow:

  • Define the Websocket URL as a user defined URL and set the 'Report all content types' parameter for it. This will allow to report calls to the WS URL (i.e. Websocket session handshakes). Due to the fact, that the handshake response has a 101 status code, the number of handshakes will be reported on the 'Standalone hits' CAS metric, not 'Operations'. This is the only way to analyze both regular HTTP traffic and Websockets (in some aspect) on the same server.
  • Use the Universal Decode for custom protocol analysis, as Ulf suggested.
  • If you are not interested in the accompanying HTTP traffic nor Websocket packet contents, you can just use the Generic with transactions decode for the number of Websocket messages and response times.

Wojtek.

Krzysztof_Ziemi
Dynatrace Pro
Dynatrace Pro

One more comment on WebSockets and how DC RUM could be applied to it:

Websocket is just the transport. Websocket opens a two-way channel for client and server to exchange information and then what’s sent both ways is purely up to the app. Without knowing the app we can only count bytes and packets. There is no “transaction” concept on the websocket level itself.

This means that DC RUM could monitor web socket traffic if:

  • we have been provided knowledge on how the app works over web sockets (how to extract transaction names and match requests with responses)
  • universal decode script were created to extract transaction names from the web socket data streams
  • and, optionally, web socket streams were correlated (in the universal decode script) to match requests and responses flowing between client and server.

Please note though that there may be no request and response present in web socket traffic in a traditional way. That is, a web socket may be opened to receive updates to be rendered on user's screen when they become available. This morel has no transaction, so there's no bearing for measuring response time. End of it all might be that measuring throughput and errors is what makes sense after all. Error detection may still need a small piece of a universal decode. Throughput measurements would work with the generic TCP decode. Or (better) the non-decrypting SSL decode if traffic is SSL-encrypted.

So long story short, the minimalistic approach to web sockets is SSL non-decrypting decode (if traffic is encrypted) or generic TCP decode (for non-encrypted traffic). The deep-dive approach requires universal decode, but this requires knowledge on the application messages structure exchanged over web sockets and most probably would still not deliver something like "response time" because that is outside of the web socket traffic nature.