#16 Bump bodhi limits
Opened 3 years ago by frantisekz. Modified 3 years ago
frantisekz/fedora-easy-karma bump_bodhi_limits  into  master

file modified
+3 -3
@@ -440,7 +440,7 @@ 

                            dest="bodhi_request_limit",

                            help="Maximum number of updates to request at "

                            "once from Bodhi, default: %default",

-                           default=25,

+                           default=50,

                            type="int")

  

          (self.options, args) = parser.parse_args()
@@ -484,7 +484,7 @@ 

                           retries=self.options.retries)

          self.bc = bc

          # Bodhi is too slow for our queries, therefore wait longer

-         bc.timeout = 300

+         bc.timeout = 120

          pkghelper = PkgHelper()

  

          if not self.options.releasever:
@@ -689,7 +689,7 @@ 

          single list of updates."""

  

          query_args = {"release": release,

-                       "limit": self.options.bodhi_request_limit,

+                       "rows_per_page": self.options.bodhi_request_limit,

                       }

          if pending:

              query_args["request"] = "testing"

  • Bump default results per page from 25 to 50
  • Stop using deprecated limit param and use rows_per_page
  • Change timeout from 300 to 120 secs

Default bodhi server timeout seems to be 60 seconds anyway, so there is no point in waiting 300 seconds. Having higher results per page makes querying bodhi a little bit faster by cutting overhead to make a single query.

Bump default results per page from 25 to 50

Just be aware that a high number here will make the queries time out when Bodhi is under load. I performed some testing a very long time ago, but it definitely changed since than, and I have no idea what is a reasonable number nowadays. So just a note.

@asaleh @cverna wdyt?

Did you perform some tests ? I honestly don't have an idea I know that some performance improvement were made on the update database table to make it much faster (this was done last year) so I guess it is worth a try.

I don't really think these should be hard-coded in the code, and you should be able to tweak them in your config. Or over-ridable from cli?

I assume you use this from your cli? Or is it part of some batch-jobs?

Note-to-self: I should really look at gathering bodhi metrics again :)

I don't really think these should be hard-coded in the code, and you should be able to tweak them in your config.

Technically true, but this is a consumer app, and we are seeking sane defaults.

Or over-ridable from cli?

No, and nor should it be - "number of rows collected from backend API" is an implementation detail, not something the user should be concerned with.

I assume you use this from your cli? Or is it part of some batch-jobs?

This is an user-facing application that helps with identifying which updates you have installed on your system, and submitting karma.
We'll be using bodhi from an automated script too, though, so once again, sane defaults are the goal here.

We are shooting for "not DOSing Bodhi, and not waiting ages for responses" ballpark.

Hopefully this made the intent a bit clearer, and we'd be glad for any tips. Thanks!

Metadata