-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve performance on interface ipmitool? #105
Comments
As background: we had this backend as a quick way to test our IPMI implementation. Performance optimization was not a requirement for us. If we have a backend that works the way you suggest, that could certainly be an improvement. I don't mind including a new interface (e.g. ipmitool-shell). So if it is important for you feel free to make a PR. |
Thanks for the information, I didn't know it was focused on testing, I'll try other interfaces to see how that affects performance. |
what interface connection do you use? is it plain rmcp? than you could try the native rmcp implemenation in this lib |
Yes, it is, I'll give it a try, thanks again |
This is more a question than an issue. Currently, the ipmitool interface is based on executing ipmitool on every request, however, creating a new process is costly. The question is: is it worth changing it to run 'ipmitool shell' from start and send the request to that process (instead of creating a new processes every time)? The downside is that we might need to keep 4 processes running (one for each possible lun value), but that shouldn't be a problem.
The text was updated successfully, but these errors were encountered: