Gnocchiclient is slow to start

[jd]

gnocchiclient leverages cliff (https://github.com/openstack/cliff), an OpenStack home made command line parser. To be short, I'll try to summarize the pros/cons of cliff:

Pros

• Easy to have "openstack metric "
• Have JSON/CSV outputs

Cons

• OpenStack specific
• Slow to start (>2s to run "gnocchi help")
• Output sucks for Gnocchi – nothing fits into a terminal

I'm starting to think we should just ditch it, as it's not very likely we can solve the cons. I've been looking into something that seems wildly used by the Python community, named click: http://click.pocoo.org/

My analysis give the following:

Pros

• Maintained by the wild Python community (Pocoo, like Flask)
• Fast

Cons

• I don't think it'd be easy to have "openstack metric " anymore
• No output format existing except "print". Probably need to add a plugin to output "tables" and CSV/JSON

Click can have plugins, and there are some here: https://github.com/click-contrib

Since Gnocchi is not an OpenStack project anymore, there's no reason to have the OpenStack CLI integration kept around (except by convenience). I'm leaning toward replacing cliff by click, but since it's a rather big change, I'd prefer to have objections before starting to write any code.

I'm also not stuck on Click, but it seems like the best option. Using argparse directly would be a PITA.

[jd]

@sileht @chungg Please, weight in.

[chungg]

• i don't understand the 'slow to start'? is it just a one time thing?
• what's the expected diff in output (i don't really care about the formatting we have in openstack... i know that's usually a massive overhead to ux).

personally, i don't see openstack-ness as a con (or pro). i just don't want us to remove openstack just because it's openstack. ie. i'd prefer we look at alerting engine, clean up carbonara's pandas usage before this.

disclaimer: my benchmarks don't use gnocchiclient so i have very little performance experience against it.

[jd]

i don't understand the 'slow to start'? is it just a one time thing?

gnocchi help > /dev/null 1.49s user 0.50s system 97% cpu 2.040 total

2s to print help. 2s to start basically.

I've been chatting with a sysadmin recently that wrote a bash script using gnocchi CLI, and it was impossible to use since every gnocchi command took 2s to start.

what's the expected diff in output

We probably need a new format that do not exist neither in cliff nor click. Tables are cool but when nothing fits in width, it's useless. You can't copy/paste any uuid easily… It's terrible UX.

i don't see openstack-ness as a con (or pro)

We're trying to build an opensource project, so it's a con in that regard. Consequently cliff is barely maintained by just one dev AFAICS.

I don't disagree with what you consider priorities, but this is also huge. It's part of our UX, and our UX sucks right now because of that. Gnocchi seems slow because the first thing sysadmin do is "gnocchi metric list" and it takes more than 2 seconds to list 0 metric. :(

[chungg]

is that 2s overhead every single command?

i find the table formatting (cliff?) is what really sucks.

[sileht]

I think it's python entry_points/pkg_resource that's slow, and cliff is not the only lib that use the use them.

Until we remove all libs that use them, we will not remove the 2s overhead.

[jd]

is that 2s overhead every single command?

Yep

Until we remove all libs that use them, we will not remove the 2s overhead.

Agree, it's a first step. :)

[larsks]

I don't think the output of cliff is as bad as you make it out to be. Remember that the default output is meant to be human readable, so it's formatted to look pretty in a terminal, but if you're passing it too much information there's not much it can do with a stanard 80 column window. The output isn't so bad by default if you work regularly with wider terminals, and you have a lot of control over what the output looks like.

For example, you can limit it to only specific fields:

$ gnocchi metric list -c  id -c name
+--------------------------------------+-----------------------------------------------------+
| id                                   | name                                                |
+--------------------------------------+-----------------------------------------------------+
| 0004e5a6-964b-4c75-b8c2-c70dbb6c256d | bugzilla.keywords.tracking                          |
| 01f565e4-5ecd-46d1-91dd-0e476991038c | bugzilla.component.openstack-tempest                |
| 04bc9668-61d5-40d1-be29-a6cfddb8cb83 | bugzilla.keywords.tracking                          |

That fits on my terminal just fine. And if I want machine readable output suitable for input to a script, I can select, e.g., csv output:

$ gnocchi  metric list -f csv --quote none | head -4
id,archive_policy/name,name,unit,resource_id
0004e5a6-964b-4c75-b8c2-c70dbb6c256d,bugzilla,bugzilla.keywords.tracking,,294ef1fa-fe18-4aca-a9ce-5aa2369ca3ef
01f565e4-5ecd-46d1-91dd-0e476991038c,bugzilla,bugzilla.component.openstack-tempest,,3dacc378-9095-44fd-96c5-ab74180628e1
04bc9668-61d5-40d1-be29-a6cfddb8cb83,bugzilla,bugzilla.keywords.tracking,,3dacc378-9095-44fd-96c5-ab74180628e1

Or even JSON:

$ gnocchi metric list -f json
[
  {
    "resource_id": "294ef1fa-fe18-4aca-a9ce-5aa2369ca3ef", 
    "archive_policy/name": "bugzilla", 
    "id": "0004e5a6-964b-4c75-b8c2-c70dbb6c256d", 
    "unit": null, 
    "name": "bugzilla.keywords.tracking"
  }, 
  {
    "resource_id": "3dacc378-9095-44fd-96c5-ab74180628e1", 
    "archive_policy/name": "bugzilla", 
    "id": "01f565e4-5ecd-46d1-91dd-0e476991038c", 
    "unit": null, 
    "name": "bugzilla.component.openstack-tempest"
  }, 

The ability to select the field that appear in the output as well as the format of the output is very useful. I think it would be a bad idea to abandon cliff without a lot of thought, because it would be silly to re-implement all of this in Yet Another Framework.

I'm also not sure why you're seeing such a slow startup time. On my own system:

$ /usr/bin/time gnocchi help > /dev/null
0.45user 0.03system 0:00.50elapsed 96%CPU (0avgtext+0avgdata 30308maxresident)k
0inputs+0outputs (0major+13359minor)pagefaults 0swaps

[jd]

The ability to select the field that appear in the output as well as the format of the output is very useful. I think it would be a bad idea to abandon cliff without a lot of thought, because it would be silly to re-implement all of this in Yet Another Framework.

Yeah I agree, that's why I've put in in a pro for cliff and cons for $other. :)

I'm also not sure why you're seeing such a slow startup time. On my own system:

Hum that might depend on the number of other libraries you have installed and that register entry points. As @sileht pointed out, keystoneauth also suffers from this syndrom, so that might be one reason my startup is so slow. I'll need to dig further!

[jd]

$ time python -c 'import pkg_resources'
python -c 'import pkg_resources'  0.69s user 0.46s system 97% cpu 1.167 total

1.1s to import pkg_resources, which is imported by stevedore, which is imported by cliff and keystoneauth1. This is really a problem.

I've less entry points and packages listed on my Python 3 system but still:

$ time python3 -c 'import sys'
python3 -c 'import sys'  0.04s user 0.01s system 85% cpu 0.053 total
$ time python3 -c 'import pkg_resources'
python3 -c 'import pkg_resources'  0.25s user 0.03s system 96% cpu 0.293 total

0.3s on startup for extensions we don't really need. :(

[jd]

Find an interesting discussion around that here: pypa/setuptools#510

[jd]

Started to profile and hack on pkg_resources then.
pypa/setuptools#1134