I am currently facing a performance issue in the rest API ...
through profiling i found out that most time gets consumed by calls to gettext and struct.unpack ...
digging deeper into the code and discussing with ralf we found out that the time gets consumed by calling roundup.cgi.TranslationService.get_translation (takes about 2ms).
which is not much, but ralf calls it in every detector as he wants to have i18n in the detector and there is no way to get it otherwise ... for 25 detectors, this adds a total of 60ms.
digging further into the logic of where get_translation gets called we found out that it's also not working as expected:
mail_gw: the setting in config.ini (mailgw.language) is ignored, uses ENV setting if found, default "en"
client.py: uses setting tracker.language (which, to me, is not obvious - web.language would be wore intuitive, but it's ok for me), browsers language (if enabled in settings), some "@language=code" form field (why?), ENV or "en"
for the rest api it could be optional if one wants translated error messages or speed - using the NullTranslatior i gain another 2ms in speed per request
to sum up what we (ralf and me) suggest as an enhancement:
put the "get_translation" functionality somewhere in the hyperdb, to have a i18n object there
initialise it with the NullTranslator (as this merely costs nothing) and
change this if needed down the way (be it in the mail_gw, cli or cgi handler)
add config item rest_no_translation and xmlrpc_no_translation (or maybe own sections for rest and xmlrpc)
detectors can access gettext (through db.i18n) and provide localized error messages,
web_interface, cli and mail_gw can change the language if needed
if nothing gets set by the user, we have maximum speed :)
free for discussion .. ;)
+ marcus.priesch, schlatterbeck|
|2021-12-16 13:37:21||marcus.priesch||set||messageid: <email@example.com>|
|2021-12-16 13:37:21||marcus.priesch||link||issue2551184 messages|