Date: Thu, 03 Jul 2014 07:27:42 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: Michelle Sullivan <michelle@sorbs.net>, demon@FreeBSD.org, ports@freebsd.org Subject: Re: Patch (not perfect but half way there) for DBIx::SearchBuilder... Message-ID: <53B4F7DE.9090300@FreeBSD.org> In-Reply-To: <53B4C581.5060508@sorbs.net> References: <53B4C581.5060508@sorbs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bHnV2egvcf31BgHfCQ4aMAdM8kiAaNmBb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/07/2014 03:52, Michelle Sullivan wrote: > Matthew, "Demon" (cc'd you two specifically because the patch affects > ports you maintain directly) >=20 > I created a patch a while ago and sent it off to Jesse and the RT-Users= > mailing list to fix extremely slow loading of tickets for Request-Track= er. >=20 > The patch is for DBIx::Searchbuilder->Fields() and you can see it here:= > https://rt.cpan.org/Public/Ticket/Attachment/WithHeaders/733854 (bug: > https://rt.cpan.org/Public/Bug/Display.html?id=3D96902 ) >=20 > If it were to be shipped as an 'option' in FreeBSD ports would it be > attached to DBIx::SearchBuilder or RT 4.x? (the patch is against > DBIx::SearchBuilder, but very specifically affects RT) The rt4x ports can't patch files belonging to DBIx::Searchbuilder -- that's not allowed. The options are: * Unconditionally patch DBIx::Searchbuilder -- given the patch hasn't been accepted upstream and it looks like it could have a deleterious impact in some setups, this doesn't seem a good idea to me * Add an option to DBIx::SearchBuilder -- Apply the patch only by user choice. Doesn't help with pre-compiled packages, but seems like a reasonable alternative to me. * Do nothing -- Means you'ld have to maintain a locally modified version of DBIx::SearchBuilder I think if you prepared a patch implementing the second case for the databases/p5-DBIx-SearchBuilder port to "improve performance under high network latency" (which should be off by default, so not changing behaviour for other users unexpectedly) there's a good chance we'd accept it. > For a brief background on it... I've been trying to upgrade SORBS > Support from RT3.8 to RT4.0 and ticket loads are 4-6 minutes in RT4.0 > compared to my old 3.8 system.. The cause being that the new System ha= s > a Pg cluster of 4 servers which are in their own datacentres.. the RT > 'Front Ends' being in public network space in other datacentres. This > is a fairly standard security model.. put your application servers in a= > DMZ (or public network) and keep the Database Servers locked in their > own network.. Just a modest 20ms Ping time and 3 schemas (RT (public),= > Bucardo and Postgres) causes the ticket load to be 4-6 minutes per > ticket - single user, 2 frontends. Patching DBIx::SearchBuilder with > the patch in the bug, drops that down to 7 seconds. Yes, the patch is an obvious win for your circumstances. The question is what will it do for the majority of installations where the PostgreSQL database is on the same machine as the web frontend, or on a very nearby machine? > Best Practical have been less than helpful, so thinking about writing a= > patch for FreeBSD ports as a new 'option' as most of my servers are > FreeBSD with my own Pkg Repo... Thoughts? In this case you can quite easily maintain a local patch in your checked-out ports tree. You know about 'make makepatch' ? That will create a files/patch-Mumble file which will be applied automatically every time you re-build p5-DBIx-SearchBuilder. > (Read the bug for the 'half way there' bit - the whole ->Fields() call > has a bad flaw.. and FWIW, a user running MySQL will not be affected by= > my patch in any negative way as MySQL is case insensitive for table > names - unlike PostgreSQL and others.) Your patch does seem to be fixing the problem --- DBIx::SearchBuilder pulling data out of too many schemas --- in a fairly non-obvious way. It's not clear to me that it is a generic fix for everyone whose databases are a long way away from their frontends either. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --bHnV2egvcf31BgHfCQ4aMAdM8kiAaNmBb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTtPfoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATRHsP/1evXZbkhf+I3zbocmrkOloQ 9G1Vml9k520Sboa4HOugzUsC4Yj/LewoSc7OLA70t2gF7OihIQaBOXP8zMoRgl6R s+nyYOXBPger1mSl8E3vQZmYTeZ4zJdj78JjVXhVXPGVWAy7zjQCHbz2I8l07XCk 8m9e5UAqhs1upzFV2lgVgV3UswQDR8fw1y1tudkFIPW6nbN9BqPyOOs7tSQMo6g0 KKpaYnpupeWuC7o+QcP4QkeXkZg0F56V7O/nPZ62sYwtkxQlGogGIEy1JU6ELSNZ vxfy4G+KrbBudpxH9lEcVLVJAHOtlef1ufPmeuZXa8ODPi6Amtz0OtqW/ovQoPeS Fg+jhyAGs35vwEXBEWYowbJsWATqEOQ5dIJ0oVBpEyTPJ5e8+/DW427RkX78J9Nw SKKPpMLm2zqnF1/o0Zbduh8heM7zrTBcsVmdsPAoIiR9pd75xqHixGcQ+xrc/xv8 KFmEAOBV5CBS2CUAK2OzZ4wZF8WbBreooxOIhgMNAVxV8rOYVdjwcp4lnehImgER XudA59x/f5QsS7J30F1b3340z53Rg7nn6hKxZ8K3b/WkGACrQq0F9s2kdYfayyoX ilg3nq2Yc397hoS28vW0ckzHEDyIivxuVeOXseMPjW1+cxal6/XHpTm1a1UjdO51 oYykYEM02aW9LTEggS1Y =5hX9 -----END PGP SIGNATURE----- --bHnV2egvcf31BgHfCQ4aMAdM8kiAaNmBb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B4F7DE.9090300>