Test the performance of your implementations please!

>Have you considered using a Redfish session for your needs, when you have multiple requests?

Yes, but same vendor has a 8 concurrent login sessions limit.
I am concerned that if there is a bug in my script, and it errors out between operations, the session is kept open, and I'll lock myself out once limit is reached.
And there can also be other management or monitoring software active in same organization that uses up sessions.


>Also, another fairly time intensive task for a low powered CPU is the negotiation of an HTTPS connection. If you aren't already, you could consider using a persistent connection. Using curl for single shot
>connections wont be doing this, so your HTTPS connection will need to be re-established for every request.

Already use a persistent HTTP keep-alive connection in my own application.
But the 0.4 second it would take, if that was not the case (as in my curl example) is not what I am really worried about. The 6 seconds it takes when authentication is used is.
In fact it looks more like an intentional 5 second delay on every login to me (to prevent brute forcing of passwords?), than real time spent computing a hash.
And would argue that if it did was spent computing some complicated multiround hash (bcrypt?), implementations should add some caching mechanism that keeps hash input (password) and result in memory for some time.