Skip to content
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

[feature request] neuroglancer http accessor profiler #37

Open
xgui3783 opened this issue Nov 27, 2023 · 2 comments
Open

[feature request] neuroglancer http accessor profiler #37

xgui3783 opened this issue Nov 27, 2023 · 2 comments

Comments

@xgui3783
Copy link
Collaborator

xgui3783 commented Nov 27, 2023

Is there an interest in adding a profile functionality to neuroglancer-scripts? (similar to scale-stats)

Usecase: we would like to be able to

1/ monitor the "liveliness" of a VM serving precomputed volume

2/ simulate average usecases (e.g. 10 concurrent users) and test the performance (average/median/min/max response time) of image services

I would imagine the usage would be something like:

# N.B. not yet implemented
profile-precomputed [-c/--concurrent int=1] \
  [-n int=1] \
  [-t/--threshold_ms int=-1] \
  PRECOMPUTED_URL1 [PRECOMPUTED_URL2] ...

I would imagine for each iteration the script would select a random x, y, z, level, then fetch volumes at +- 3 levels, with appropriate bounding box (bound by the limit of the volume)

We will happy to put in work for this utility, as we foresee that we will need to create such a utility in any case.

The question is, is neuroglancer-script a good/correct place for such utility?

would love to hear your thoughts @ylep

@ylep
Copy link
Collaborator

ylep commented Dec 20, 2023

Well, this is a rather specific use-case, so I would not make it a priority, but I'd definitely incorporate the code if you want to contribute it! (as long as it does not add a significant burden, e.g. extra dependencies, to the main neuroglancer-scripts workflows that is data conversion)

@xgui3783
Copy link
Collaborator Author

xgui3783 commented Jan 2, 2024

My naive first impression is that we should not need any more than requests (which is already a dependency) and ThreadPoolExectuor, which is a built in.

But glad to see that there is interest. I will see what I can whip up.

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

No branches or pull requests

2 participants