Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Computing IO-Wait time #267

Closed
pranavtbhat opened this issue Sep 10, 2019 · 6 comments
Closed

Computing IO-Wait time #267

pranavtbhat opened this issue Sep 10, 2019 · 6 comments

Comments

@pranavtbhat
Copy link
Contributor

I'm investigating an IO-boundedness issue with a python server, and would like to instrument the uvloop to compute the amount of time spent polling for IO.

The way to do this in libuv would be to register a prepare handle that records the start_time and a check handle that records the the stop_time and writes it to some form of global state. I went through the UVLoop code, and there seems to be no way to register custom check or prepare handles.

Is there another cleaner way to do this? I suppose I could subclass uvloop.Loop and register the handles myself, but that seems to be a fairly ugly approach.

@1st1
Copy link
Member

1st1 commented Sep 11, 2019

You can try to build uvloop in debug mode. It will have many debug attributes then; if total polling time isn't one of them we can add it.

In general we do need to design a deep tracing API for uvloop. #171 is meant for that, but I didn't have the time to work on it.

@pranavtbhat
Copy link
Contributor Author

Total polling time doesn't seem to be a debug attribute. Also, we probably need aggregate data to debug this, so debug-mode may not be feasible for extensive analysis.

The ability to register custom prepare/check handles could allow users like me to self service some tracing/profiling needs. Do you think this would be clean and worth adding to UVLoop?

@1st1
Copy link
Member

1st1 commented Sep 12, 2019

TBH I don't want to add any non-asyncio API to uvloop. It will increase maintenance overhead and will split the ecosystem a bit.

If you can implement the desired functionality for the debug build, I can consider accepting it.

@pranavtbhat
Copy link
Contributor Author

I'll follow up with a PR then. Thanks Yury!

@1st1
Copy link
Member

1st1 commented Sep 12, 2019

I'll follow up with a PR then. Thanks Yury!

NP. Just to clarify: whatever is in the debug build can be removed in the future, i.e. it's not a stable API. But before removing something like that we should figure out a better way.

@pranavtbhat
Copy link
Contributor Author

@1st1 I tried building the functionality into the debug build, but the debug build itself is a fairly large performance hit.

I considered another option. Inheriting from uvloop.loop.Loop. This requires me to cimport from uvloop. The required cython header (pxd) files are packaged as expected.

However, the libuv .h/.c files are not, and the C compilation fails. Since UVLoop packages it's own libuv, it's probably too hacky to define a separate dependency on libuv.

Do you think we can package the vendor/libuv directory too?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants