Patch (not perfect but half way there) for DBIx::SearchBuilder...

[Matthew Seaman]

On 03/07/2014 03:52, Michelle Sullivan wrote:
> Matthew, "Demon" (cc'd you two specifically because the patch affects
> ports you maintain directly)
> 
> 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-Tracker.
> 
> 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=96902 )
> 
> 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 has
> 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

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1036 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140703/3ef0c9c0/attachment.sig>