Performance problems in OutputFilterTextURL

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, at a customer's place we noticed a performance problem while rendering some (mostly large) pages. The culprit turned out to live in Kernel/Output/HTML/OutputFilterTextURL.pm, somewhere here: | for my $Key ( sort keys %{ $Self->{LinkHash} } ) { | my $LinkSmall = $Self->{LinkHash}->{$Key}; | $LinkSmall =~ s/^(.{75}).*$/$1\[\.\.\]/gs; | $Self->{LinkHash}->{$Key} =~ s/ //g; | ${ $Param{Data} } | =~ s/\Q$Key\E/{LinkHash}->{$Key}\" target=\"_blank\" title=\"$Self->{LinkHash}->{$Key}\">$LinkSmall<\/a>/; | } This code compiles a new regex for each $Key and does its substitution thingy. In our case, there were over 5000 (!) $Keys, so the whole thing took about 12 seconds in total. I've replaced this by one regex, under the assumption that the $Keys have the form "##################329", i.e. a sufficient number of hash signs and a decimal number, like so: $Param{Data} =~ s/(#{10,}\d+)/$Self->_renderlink($1)/eg; with a suitable method _renderlink, which constructs the link given the Key. Now my questions: * Am I assuming right that the internal link keys have of this form? * Would you be interested in a patch? * What is this line doing up there: $Self->{LinkHash}->{$Key} =~ s/ //g; ? Thanks for any insight - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNVBRbBcgs9XrR2kYRAp7ZAJ9hIJ3R/jcCHREzafASoObRUNMeZwCcC1BW cXPZpdXFkaM9yvMBhrQ8nB4= =8Jq+ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Feb 10, 2011 at 05:37:47PM +0100, tomas@tuxteam.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
at a customer's place we noticed a performance problem while rendering some (mostly large) pages [...]
I've replaced this by one regex, under the assumption that the $Keys have the form "##################329", i.e. a sufficient number of hash signs and a decimal number, lik so:
As a colleague noticed, it's rather "[##################329]", i.e. I forgot the square brackets. The rest of the mail still stands. I'd be delighted to send in a patch, if desired. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNVRuJBcgs9XrR2kYRAtGoAJ4idY0VLWlT7E/4dHI7hXCesL+x5wCfTfse XhWwjmLN5N4KJBX+VkB//I0= =/xt8 -----END PGP SIGNATURE-----

Hi Thomas, we would definitely be interested. Can I ask you to do the following: - open a bug report for this - attach a test case which shows the performance problem (e. g. a file with data which causes the problem when fed into the function) - attach your patch Then send the link to the bug to this list and to me (martin.gruner@otrs.com). I cannot give an estimate on when we will be able to review it, but we currently plan to include it into OTRS 3.1 if possible. Thank you very much in advance. Regards, mg Am 11.02.11 12:20, schrieb tomas@tuxteam.de:
On Thu, Feb 10, 2011 at 05:37:47PM +0100, tomas@tuxteam.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
at a customer's place we noticed a performance problem while rendering some (mostly large) pages [...]
I've replaced this by one regex, under the assumption that the $Keys have the form "##################329", i.e. a sufficient number of hash signs and a decimal number, lik so:
As a colleague noticed, it's rather "[##################329]", i.e. I forgot the square brackets. The rest of the mail still stands.
I'd be delighted to send in a patch, if desired.
Regards -- tomás
OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs -- Martin Gruner Senior Developer R&D OTRS AG Europaring 4 94315 Straubing T: +49 (0)6172 681988 0 F: +49 (0)9421 56818 18 I: www.otrs.com/ Geschäftssitz: Bad Homburg, Amtsgericht: Bad Homburg, HRB 10751, USt-Nr.: DE256610065 Aufsichtsratsvorsitzender: Burchard Steinbild, Vorstand: André Mindermann Steigern Sie Ihre Effizienz um 30% - mit OTRS Help Desk 3.0: http://www.otrs.com/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Feb 16, 2011 at 10:17:17AM +0100, Martin Gruner wrote:
Hi Thomas,
[...] Thanks, Martin, for your reply. I'll gladly do as requested (in the meantime I found another very similar case in another place). It might take a couple of days, though. Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNW558Bcgs9XrR2kYRAt5RAJ4tHf8ioYWyAvDUR9SuYN58F+Vr0gCfaday 8bB7p366vo97cbxWC9W6hyY= =qvR6 -----END PGP SIGNATURE-----

On Wed, Feb 16, 2011 at 10:17:17AM +0100, Martin Gruner wrote:
Hi Thomas,
we would definitely be interested. Can I ask you to do the following: - open a bug report for this - attach a test case which shows the performance problem (e. g. a file with data which causes the problem when fed into the function) - attach your patch
After wrangling for a while with Bugzilla, I gave up (too tight in time). Anyway, I attach two patches here, in case they are useful: * output_filter_text_url.patch * html_utils.patch Both patches are taken against 2.4.7. The first one applies cleanly to HEAD, the second doesn't (although the code follows the same pattern). Both are variations on the same theme: replace a loop doing substitutions over and over by just one substitution. Both cut page latencies in some cases by as much as 30 seconds (on very big pages, when there are lots of links). I hope it's useful as is. Regards -- tomás
participants (2)
-
Martin Gruner
-
tomas@tuxteam.de