Httpd speed on rt3

In that case:

If youhave already made the change I suggested, replace the:
% while (my $Transaction = $Transactions->Next) {
% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/);

With:

%my $firstprinted=0;
% while (my $Transaction = $Transactions->Next) {
% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/ && $firstprinted==1);
% $firstprinted=1;

That will show you the first and last.

A.J.From: Scott Hebert [mailto:scott@cae.com]
Sent: Friday, January 23, 2004 9:29 AM
To: ‘AJ’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

AJ,

This has sped things up for me.

However, my users want to see this first transaction (typically the body of
an email sent in to create the ticket) and the last one.

What would be the fix for that?

Thanks,

SH

From: AJ [mailto:rt@musefoundry.com]
Sent: Thursday, January 22, 2004 8:08 PM
To: ‘AJ’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

Actually Mike reminded me that I should put a correction to what I put
before.

Only one line.

Right under the following line in the html/Ticket/ShowHistory component:
% while (my $Transaction = $Transactions->Next) {

Put:

% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/);

Display will only show last transaction. History and modify will show all.

From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of AJ
Sent: Thursday, January 22, 2004 2:50 AM
To: ‘Mike Husband’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

in Ticket/Elements/ShowHistory:

ABOVE:
% while (my $Transaction = $Transactions->Next) {

Put:

% if ($m->request_comp()->title=~/Ticket/Display.html/) {
% my $Transaction = $Transactions->Last;
<& ShowTransaction, Ticket => $Ticket, Transaction => $Transaction,
ShowHeaders => $ShowHeaders, Collapsed => $Collapsed, RowNum => $i,
ShowTitleBarCommands => $ShowTitleBarCommands, %ARGS &>
%}

Moves cursor to the last one and prints it. The hits the while loop but
since you are already at the end goes right over it.

What version of Solaris you run? I originally had the front end of RT on a
fully loaded E250 with Solaris 9 and the db on an 8 processor E3500 with 4.5
gigs ram and it was still slow. I moved the front end to linux and it made a
big difference. Also, there is one param that should be set on Solaris that
will take care of the possible Log::Dispatch errors and allow you to log to
syslog if you want.

A.J.

From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Mike Husband
Sent: Wednesday, January 21, 2004 8:46 PM
To: Rt-Users (E-mail)
Subject: RE: [rt-users] httpd speed on rt3

I have a few timings which might throw some more light on this.

I’m running RT 3.0.7 over postgresql 7.4 on Solaris.

A ticket with 2 small comments takes about 5 seconds to retrieve,
but a ticket with 10 small comments (200 to 500 bytes) and 4 attachments
(50K each)
takes about 18 seconds to retrieve.

My profile of executions shows that there are 106 SELECT statements, most
of which take less than 5 ms. There are 8 permissions checks which take
about 20 to 30 ms each. This gives a total sql time of less than 1 second.

The break down of wall-clock execution time is roughly as follows:

Check permissions; get ticket, custom fields, transaction list - about 3
seconds
Get comments/attachments - 14 seconds.

So it seems fairly clearly that the killer here is the time to process
attachments.

Is it possible to display only the last comment by default, and display all
only
if the user asks for history? Would this be an acceptable compromise?

Mike

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of Jesse
Vincent
Sent: Thursday, 22 January 2004 3:26 AM
To: Douglas E. Warner
Cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] httpd speed on rt3

After fresh restart:
displaying ticket: 10s
replaying queries: 1.5s

Then (not restarted):
displaying ticket: 9s
replaying queries: 0.06s

I’m not seeing the same queries over and over again like
Palle was; there 227
queries for the page load, but there’s 88 transactions
(that includes
comments, correspondance, and actions).

Ok. I think there’s the thing that’s taking the time. how long are the
comments and correspondence? Are there attachments to the ticket? I’m
betting that you don’t see such performance issues on shorter
tickets.

This is a known issue with long tickets with a lot of attachment
content, especially “binary” attachments that aren’t
displayed inline. A
customer asked us to quote a fix for them. We’ve sent them
the quote and
are just waiting for them to decide whether or not to go for it. (It
involves a bunch of changes to RT’s core.) Ruslan sent a draft of a
possible fix to rt-devel as well, which may work for you.

Jesse

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADrCVJV36su0A0xIRAsZjAJ9T4bcmFklLUi/tWCW+MuE5Ja5UWACg3jEw
P4Ti1N5piu5t7htri1lrRNk=
=3w72
-----END PGP SIGNATURE-----


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Scott & AJ
Thanks for the question, and the response.

I was thinking of doing something like this, and possibly
displaying the last 2 transactions.
However, the question I have is:

  • what if there is only one transaction?

Will displaying first and last display the same transaction twice?
Will displaying the last two get in trouble?

I haven’t looked at the code in detail to figure this out yet,
but if it’s easy for you to resolve, AJ, it will be appreciated.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of AJ
Sent: Saturday, 24 January 2004 3:36 AM
To: ‘Scott Hebert’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

In that case:

If youhave already made the change I suggested, replace the:
% while (my $Transaction = $Transactions->Next) {
% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/);

With:

%my $firstprinted=0;
% while (my $Transaction = $Transactions->Next) {
% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/ &&
$firstprinted==1);
% $firstprinted=1;

That will show you the first and last.

A.J.

-----Original Message-----
From: Scott Hebert [mailto:scott@cae.com]
Sent: Friday, January 23, 2004 9:29 AM
To: ‘AJ’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

AJ,

This has sped things up for me.

However, my users want to see this first transaction
(typically the body of
an email sent in to create the ticket) and the last one.

What would be the fix for that?

Thanks,

SH

-----Original Message-----
From: AJ [mailto:rt@musefoundry.com]
Sent: Thursday, January 22, 2004 8:08 PM
To: ‘AJ’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

Actually Mike reminded me that I should put a correction to what I put
before.

Only one line.

Right under the following line in the html/Ticket/ShowHistory
component:
% while (my $Transaction = $Transactions->Next) {

Put:

% $Transaction = $Transactions->Last if
($m->request_comp()->title=~/Ticket/Display.html/);

Display will only show last transaction. History and modify
will show all.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of AJ
Sent: Thursday, January 22, 2004 2:50 AM
To: ‘Mike Husband’; ‘Rt-Users (E-mail)’
Subject: RE: [rt-users] httpd speed on rt3

in Ticket/Elements/ShowHistory:

ABOVE:
% while (my $Transaction = $Transactions->Next) {

Put:

% if ($m->request_comp()->title=~/Ticket/Display.html/) {
% my $Transaction = $Transactions->Last;
<& ShowTransaction, Ticket => $Ticket, Transaction => $Transaction,
ShowHeaders => $ShowHeaders, Collapsed => $Collapsed, RowNum => $i,
ShowTitleBarCommands => $ShowTitleBarCommands, %ARGS &>
%}

Moves cursor to the last one and prints it. The hits the
while loop but
since you are already at the end goes right over it.

What version of Solaris you run? I originally had the front
end of RT on a
fully loaded E250 with Solaris 9 and the db on an 8 processor
E3500 with 4.5
gigs ram and it was still slow. I moved the front end to
linux and it made a
big difference. Also, there is one param that should be set
on Solaris that
will take care of the possible Log::Dispatch errors and allow
you to log to
syslog if you want.

A.J.

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Mike Husband
Sent: Wednesday, January 21, 2004 8:46 PM
To: Rt-Users (E-mail)
Subject: RE: [rt-users] httpd speed on rt3

I have a few timings which might throw some more light on this.

I’m running RT 3.0.7 over postgresql 7.4 on Solaris.

A ticket with 2 small comments takes about 5 seconds to retrieve,
but a ticket with 10 small comments (200 to 500 bytes) and 4
attachments
(50K each)
takes about 18 seconds to retrieve.

My profile of executions shows that there are 106 SELECT
statements, most
of which take less than 5 ms. There are 8 permissions checks
which take
about 20 to 30 ms each. This gives a total sql time of less
than 1 second.

The break down of wall-clock execution time is roughly as follows:

Check permissions; get ticket, custom fields, transaction
list - about 3
seconds
Get comments/attachments - 14 seconds.

So it seems fairly clearly that the killer here is the time to process
attachments.

Is it possible to display only the last comment by default,
and display all
only
if the user asks for history? Would this be an acceptable compromise?

Mike

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com]On Behalf Of Jesse
Vincent
Sent: Thursday, 22 January 2004 3:26 AM
To: Douglas E. Warner
Cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] httpd speed on rt3

After fresh restart:
displaying ticket: 10s
replaying queries: 1.5s

Then (not restarted):
displaying ticket: 9s
replaying queries: 0.06s

I’m not seeing the same queries over and over again like
Palle was; there 227
queries for the page load, but there’s 88 transactions
(that includes
comments, correspondance, and actions).

Ok. I think there’s the thing that’s taking the time. how
long are the
comments and correspondence? Are there attachments to the
ticket? I’m
betting that you don’t see such performance issues on shorter
tickets.

This is a known issue with long tickets with a lot of attachment
content, especially “binary” attachments that aren’t
displayed inline. A
customer asked us to quote a fix for them. We’ve sent them
the quote and
are just waiting for them to decide whether or not to go for it. (It
involves a bunch of changes to RT’s core.) Ruslan sent a draft of a
possible fix to rt-devel as well, which may work for you.

Jesse
  • -Doug

Douglas E. Warner dwarner@ctinetworks.com
Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADrCVJV36su0A0xIRAsZjAJ9T4bcmFklLUi/tWCW+MuE5Ja5UWACg3jEw
P4Ti1N5piu5t7htri1lrRNk=
=3w72
-----END PGP SIGNATURE-----


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm


Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I finally got the stuff to work (after a reboot; very wierd).

I ran my big ticket a couple time times; interesting stuff as follows:

$ egrep -v ‘(0.|ENDS|BEGINS)’ bigticket-*
bigticket-1.txt:=Mason= * - /Ticket/Elements/ShowAttachments
4.0983
bigticket-1.txt:=Mason= * - /Ticket/Elements/ShowSummary 4.7828
bigticket-1.txt:=Mason= * - /Ticket/Elements/ShowHistory 12.6187
bigticket-1.txt:=Mason= * - /Ticket/Display.html 17.6879
bigticket-1.txt:=Mason= * - /autohandler 17.7271
bigticket-2.txt:=Mason= * - /Ticket/Elements/ShowAttachments
1.0011
bigticket-2.txt:=Mason= * - /Ticket/Elements/ShowSummary 1.4472
bigticket-2.txt:=Mason= * - /Ticket/Elements/ShowHistory 13.0363
bigticket-2.txt:=Mason= * - /Ticket/Display.html 14.7110
bigticket-2.txt:=Mason= * - /autohandler 14.8063
bigticket-3.txt:=Mason= * - /Ticket/Elements/ShowAttachments
3.3127
bigticket-3.txt:=Mason= * - /Ticket/Elements/ShowSummary 3.7440
bigticket-3.txt:=Mason= * - /Ticket/Elements/ShowHistory 12.6374
bigticket-3.txt:=Mason= * - /Ticket/Display.html 16.5523
bigticket-3.txt:=Mason= * - /autohandler 16.5956

So, the things that eat up a bunch of time seem to be
/Ticket/Elements/ShowSummary, of which /Ticket/Elements/ShowAttachments seems
to use most of the time, and all of the /Ticket/Elements/ShowTransaction’s
that make up /Ticket/Elements/ShowHistory.
Each of the /Ticket/Elements/ShowTransaction’s are appear to be around 0.15
seconds, but there are litterally 87 of them (bc shows that to be around 13
seconds for the first ticket; pretty close to ShowHistory’s total).

I also have a much shorter ticket (it’s new) that /Ticket/Elements/ShowSummary
takes up about 60% of the page load, as opposed to about 25% of the bigger
tickets (at least it scales well).
If anybody would like to see the full output, let me know.

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAF/3qJV36su0A0xIRAgWXAJ9IXdPWbrcKQwZBwOVi6jG3FADhswCghVtj
dg2Tw4kACTcDEcQz8RYpSLw=
=RLi3
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Thursday 29 January 2004 03:13, Ruslan U. Zakirov wrote:

I’d like to see output from Profiler
dprofpp -S qwe.out

For big ticket and small one.
And full from Mason Profiler.

Here’s a tarball with everything (only way to keep it under the list message
size maximum).

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAH9MxJV36su0A0xIRAqPkAJ44Ul0KR534HfFXHJQI5bbeSrOyowCgnS8/
RthJCL4oCxRctvmm0kwAv0A=
=ssxg
-----END PGP SIGNATURE-----

ticketprofile.tar.bz2 (20.3 KB)

Content-Description: clearsigned data

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’d like to see output from Profiler
dprofpp -S qwe.out

For big ticket and small one.
And full from Mason Profiler.

Here’s a tarball with everything (only way to keep it under the list message
size maximum).

So, this looks pretty much like the “tickets with large attachments take
a long time to display” issue that we identified a while ago. A
potential customer had approached us about underwriting the changes that
would need to happen to fix it, but then backed off. Ruslan had a
preliminary hack of a patch as well. At this point, without a sponsor
for the work, it’s something we’re looking to fix for 3.2.

Jesse
  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAH9MxJV36su0A0xIRAqPkAJ44Ul0KR534HfFXHJQI5bbeSrOyowCgnS8/
RthJCL4oCxRctvmm0kwAv0A=
=ssxg
-----END PGP SIGNATURE-----


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Jesse Vincent wrote:

Content-Description: clearsigned data

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’d like to see output from Profiler
dprofpp -S qwe.out

For big ticket and small one.
And full from Mason Profiler.

Here’s a tarball with everything (only way to keep it under the list message
size maximum).

So, this looks pretty much like the “tickets with large attachments take
a long time to display” issue that we identified a while ago. A
potential customer had approached us about underwriting the changes that
would need to happen to fix it, but then backed off. Ruslan had a
preliminary hack of a patch as well. At this point, without a sponsor
for the work, it’s something we’re looking to fix for 3.2.

Jesse

Hello, Douglas and Jesse and other.

Ok. This is really problem.
I’ve attached patches.
Instructions below.

Check it please and some feedback on it.
Profiles would be helpful.

		Best regards, Ruslan.


Installation guide, read everything before applying.

tar -xzvf DBIx-SearchBuilder-0.96.tar.gz
cd DBIx-SearchBuilder-0.96
cat noprefetch.patch | patch -p1

You’ll see warns here, but it’s ok,

this patch was writen for 0.94 version.

perl Makefile.PL
make && make test && make install

backup RT tree with something like tar -czvf rt.tar.gz rt3

cd /opt/rt3
cat noprefetch_rt.patch | patch -p1

apache full restart

check

this patches can’t corrupt your data.

functionality is triggered only pages where attachments info is used.

you can revert them

  1. reinstall plain DBIx-SearchBuilder
    tar -xzvf DBIx-SearchBuilder-0.96.tar.gz
    cd DBIx-SearchBuilder-0.96
    perl Makefile.PL
    make && make test && make install

  2. clean RT code with -R option to patch.
    cat noprefetch_rt.patch | patch -p1 -R

noprefetch.patch (5.64 KB)

noprefetch_rt.patch (4.24 KB)

Hello, again.

I’ve check again patches.

Results:

  1. Transaction recordsman (260 Trs without binary attachments all text
    inlined in history).

~ 60 sec with and without patches.

Here is I see a little slowdown because of additional selects for
content fetching. It’s suspected.

  1. Binary attachments length recordsmen. (10 bin attachs with summary
    length 32Mb)

Speedup from 34 to 28 sec(~6 sec saved).

Yeh, speed up, but not so large as wanted.

Future ideas:

  1. Refactor code of History’s html. I don’t think this could help a lot,
    but we can give it a try.

  2. As we can see from MasonXProfile:
    Mason component Counter Summary time(a little wierd
    info, but consistent with reality)
    /Ticket/Elements/ShowHistory 1 12.6187
    /Elements/Footer 1 0.0142
    /Ticket/Elements/ShowAttachments 1 4.0983
    /Elements/SelectNewTicketQueue 1 0.0084
    /Elements/ListActions 1 0.0041
    /Ticket/Elements/ShowTransaction 87 11.9785
    /Ticket/Elements/ShowMembers 1 0.0203
    /Ticket/Elements/ShowDates 1 0.078
    /Ticket/Elements/Tabs 1 0.1348
    /Elements/SetupSessionCookie 1 0.0054
    /Ticket/Elements/ShowMessageHeaders 69 0.7705
    /Elements/Callback 403 2.02620000000001
    /Ticket/Elements/ShowPeople 1 0.1223
    /autohandler 1 17.7271
    /Elements/Menu 4 0.0734
    /Elements/CreateTicket 1 0.0202
    /Ticket/Elements/ShowSummary 1 4.7828
    /Ticket/Elements/ShowLinks 1 0.1996
    /Ticket/Elements/ShowMessageStanza 72 1.4281
    /Ticket/Elements/ShowRequestor 1 0.0322
    /Elements/TitleBoxEnd 5 0.0203
    /Elements/Header 1 0.0284
    /Elements/PageLayout 1 0.0392
    /Elements/TitleBoxStart 5 0.0222
    /Ticket/Elements/ShowBasics 1 0.0569
    /Elements/Tabs 1 0.0824
    /Ticket/Display.html 1 17.6879
    /Elements/SimpleSearch 1 0.0104

Callback subsystem eats a lot of time even if there is no callbacks found.

  1. Commenting eval around text qoutting gave me speedup first test to
    51sec(~9 sec)(Ticket/Elements/ShowTransaction)

Turned off quotting at all and got ~48(12 sec speedup)

Waiting for your feedback.
Ruslan.

Waiting for your feedback.

Autrijus and I are currently working on prepping our version of the
patches. I hope to have something for you to play with within the next
day or two.

  	Ruslan.

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Hi all,

This is very interesting. If we can find a way to get rid of these
performance issues, RT will become the killer app it deserves to be.

Where can get I get more information on Mason profiling? I’d love to get
in there and see if I can’t find something.

Thanks a lot,

PatrickOn Wed, 2004-02-04 at 10:58, Jesse Vincent wrote:

Waiting for your feedback.

Autrijus and I are currently working on prepping our version of the
patches. I hope to have something for you to play with within the next
day or two.

  	Ruslan.

Patrick LeBoutillier wrote:

Hi all,

This is very interesting. If we can find a way to get rid of these
performance issues, RT will become the killer app it deserves to be.

Where can get I get more information on Mason profiling? I’d love to get
in there and see if I can’t find something.

Thanks a lot,

Patrick

search.cpan.org
Apache::DProf and then go by SeeAlso links.
MasonX::Profiler

	Best regards. Ruslan.

PS: As thought It will be very useful if some one will merge it modules.
With Apache::DProf we can’t split exec tree info by Mason components.
With MasonX::Profiler we can’t see more info about perl code in components.

Ok. Autrijus patches are in SearchBuilder 0.97_02 and RT 3.0.9pre3, both
of which are available from the usual places. The performance
improvements seem to be inline with your versions, though the
architecture makes it a little easier to “hint” things down the road
here. I’m seeing a 30% improvement on load times for long tickets,
which is good, but not the magic bullet I’d hoped for.

One change that could make a BIG difference in perceived speed

is turning on mason’s autoflushing and restructuring the html to be
friendlier to progressive rendering. It’s something we’re looking at,
but initial experiments weren’t as “magic” as I’d hoped.

-jesse

Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.

Jesse,

This patch is required to do Mason profiling under FastCGI:

cvs server: Diffing .
Index: Web.pm
RCS file: /var/lib/cvs/RT-3.0.8-support/lib/RT/Interface/Web.pm,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 Web.pm
*** Web.pm 30 Jan 2004 13:52:53 -0000 1.1.1.1
— Web.pm 5 Feb 2004 13:36:44 -0000
*** 98,104 ****
],
data_dir => “$RT::MasonDataDir”,
default_escape_flags => ‘h’,
! allow_globals => [qw(%session)]
);

— 98,105 ----
],
data_dir => “$RT::MasonDataDir”,
default_escape_flags => ‘h’,
! allow_globals => [qw(%session)],
! @_
);

It was probably just a mistake, @_ was not being passed on to the Mason
handler.

Patrick

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok. Autrijus patches are in SearchBuilder 0.97_02 and RT 3.0.9pre3, both
of which are available from the usual places. The performance
improvements seem to be inline with your versions, though the
architecture makes it a little easier to “hint” things down the road
here. I’m seeing a 30% improvement on load times for long tickets,
which is good, but not the magic bullet I’d hoped for.

Initially, it seems you’re right. My very basic timing (counting) using RT
3.0.9pre4 + SB 0.97_99 while loading the ticket seems to be about 4 seconds
faster (14 seconds vs 18). Unfortunately, I’m having problems getting
MasonX::Profiler to work with these new versions; do you know if anything
would have changed in DBIx::SB that might affect this? My reboot ‘solution’
didn’t work this time, either.

One change that could make a BIG difference in perceived speed

is turning on mason’s autoflushing and restructuring the html to be
friendlier to progressive rendering. It’s something we’re looking at,
but initial experiments weren’t as “magic” as I’d hoped.

I was curious as to whether Mason auto-flushed or not (similar to PHP); I
guess that answers that.
Some observations: the first part of the page loads very fast (up to and
including the ‘History’ bar), then hangs while the history is being
formatted, it seems. I think this will help people wait around, especially
for the shorter tickets, though. Of course, this is using Mozilla as a
browser; I don’t think IE will render un-terminated table’s progressively,
though.

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAIrunJV36su0A0xIRAvqFAKDTDNA16fDlfpwpwxdwMGTj7C5zggCeOdTR
/2vE5Na7N7fa+QFzNSF4IuQ=
=/ufI
-----END PGP SIGNATURE-----