[Rt-devel] RT3 Speed - Tickets display
jesse at bestpractical.com
Thu Nov 25 01:27:53 EST 2004
> > >
> > > In the ever continuing effort to get RT3 up to acceptable speed,
> > > currently trying to speed up Ticket display page, particularly when
> > > dealing with
> > >
> > > Large tickets.
> > Can you verify that you're testing against the latest release of RT
> Using version 3.2.2
> > DBIx::SearchBuilder (Ideally, the 1.13 test versions)
> Using 1.12 , more than happy to try 1.13 but I can't find it (or even
> any thing close to current) in
> > Cache::SimpleTimedExpirey?
> > Ideally, you could also run your tests against RT 3.3.11.
> Unfortunately I don't really have time to try against 3.3.11 at the
> moment, is the database schema much different? I'm 80% through importing
> over a million tickets into 3.2, so if the database schema is different
> then there is no chance :) Is there a release date for 3.3 stable (or
> will it be 3.4?)
Importing into 3.2? The changes from 3.0 to 3.2 were an in-database SQL
transform. Just like 3.2 to 3.3. There's no set date for 3.4.0 That's
entirely dependent on public response to the betas. But we've spent a
fair amount of time on performance for this next release. We're seeing
pages render in .5s that used to take 4-5s on the same hardware and
Anyway, your profiling numbers looked..high. Can you get us database
query logs and performance numbers from your database? For your 100 txn
ticket, how much text is there? how many attachments?
I'm starting to feel like the ticket history just needs to be paged.
Even blatting out pure html from a static file, 100 transactions is
nothing to sniff at.
> > >
> This email and any files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. Please notify the sender
> immediately by email if you have received this email by mistake and delete this email
> from your system. Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for the presence of
> viruses. The organisation accepts no liability for any damage caused by any virus
> transmitted by this email.
More information about the Rt-devel