Template Generator with large number of DynamicFields was very slow
We were taking advantage of the ProcessManagement functionality and using a lot of DynamicFields to provide a much more fielded workflow of certain functions such as Release Management when we started to notice performance of Notifications decline, to the point each notification was taking 6+ seconds. After quite a bit of investigation the root cause was in TemplateGenerator.pm. The system loads up every single active DynamicField, loads it's Key and Viewable Value and creates a large hash that it then cycles through and attempts to do a string replace. This is especially painful since we didn't even use any DynamicFields in our response templates. Therefore I patched ours to find out which fields are needed and only load those. It resolved our performance issue while maintaining the functionality. Providing the patch here, in case you want to include it in a future release. -- Keith Moore TemplateGenerator.patchhttps://docs.google.com/file/d/0B5_W7RGI9GFpUzhJQ3pWLTRnMlE/edit?usp=drive_w...
Make a push request to the main git repo? They might accept it there. Anyways - this is an awesome patch and probably an oversight in scalability. From: dev-bounces@otrs.org [mailto:dev-bounces@otrs.org] On Behalf Of Keith Moore Sent: Tuesday, August 20, 2013 4:24 PM To: dev@otrs.org Subject: [dev] Template Generator with large number of DynamicFields was very slow We were taking advantage of the ProcessManagement functionality and using a lot of DynamicFields to provide a much more fielded workflow of certain functions such as Release Management when we started to notice performance of Notifications decline, to the point each notification was taking 6+ seconds. After quite a bit of investigation the root cause was in TemplateGenerator.pm. The system loads up every single active DynamicField, loads it's Key and Viewable Value and creates a large hash that it then cycles through and attempts to do a string replace. This is especially painful since we didn't even use any DynamicFields in our response templates. Therefore I patched ours to find out which fields are needed and only load those. It resolved our performance issue while maintaining the functionality. Providing the patch here, in case you want to include it in a future release. -- Keith Moore [https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png] TemplateGenerator.patchhttps://docs.google.com/file/d/0B5_W7RGI9GFpUzhJQ3pWLTRnMlE/edit?usp=drive_w...
Thanks, I submitted my contributor paperwork and will send a request to the
main repo.
-- Keith Moore
On Tue, Aug 20, 2013 at 4:27 PM, McMahon, Mike (HQP)
Make a push request to the main git repo? They might accept it there. Anyways – this is an awesome patch and probably an oversight in scalability. ****
** **
** **
*From:* dev-bounces@otrs.org [mailto:dev-bounces@otrs.org] *On Behalf Of *Keith Moore *Sent:* Tuesday, August 20, 2013 4:24 PM *To:* dev@otrs.org *Subject:* [dev] Template Generator with large number of DynamicFields was very slow****
** **
** **
We were taking advantage of the ProcessManagement functionality and using a lot of DynamicFields to provide a much more fielded workflow of certain functions such as Release Management when we started to notice performance of Notifications decline, to the point each notification was taking 6+ seconds.****
** **
After quite a bit of investigation the root cause was in TemplateGenerator.pm. The system loads up every single active DynamicField, loads it's Key and Viewable Value and creates a large hash that it then cycles through and attempts to do a string replace. This is especially painful since we didn't even use any DynamicFields in our response templates.****
** **
Therefore I patched ours to find out which fields are needed and only load those. It resolved our performance issue while maintaining the functionality.****
** **
Providing the patch here, in case you want to include it in a future release.****
** **
-- Keith Moore****
** **
** **
* TemplateGenerator.patchhttps://docs.google.com/file/d/0B5_W7RGI9GFpUzhJQ3pWLTRnMlE/edit?usp=drive_w... *
** **
** **
** **
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
participants (2)
-
Keith Moore -
McMahon, Mike (HQP)