Ok, I’ve now been able to successfully use Devel::DProf to profile using
standalone_http. For a larger ticket (that I am currently working on, and
is still open and occasionally added to) here is what I’m facing:
Using &Debug=1 results in:
Time to display: 27.229506
dprofpp -F (won’t run without this, as I hinted at in another
thread; not sure if it matters) results in:
Total Elapsed Time = 36.76373 Seconds
User+System Time = 6.028711 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
16.2 0.979 2.218 48968 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::new
14.4 0.868 4.497 14592 0.0001 0.0003 RT::Principal::HasRight
13.7 0.830 1.363 49094 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::_fetch
13.4 0.810 1.289 74161 0.0000 0.0000 RT::Record::__Value
13.1 0.790 4.448 49094 0.0000 0.0001 RT::Record::LoadByCols
12.7 0.770 0.689 49094 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::_gen_alternate_RecordCache_ke
y
12.2 0.740 0.506 155914 0.0000 0.0000 DBIx::SearchBuilder::Record::id
11.9 0.720 0.777 99069 0.0000 0.0000 Cache::Simple::TimedExpiry::fetch
11.6 0.700 3.840 49094 0.0000 0.0001 DBIx::SearchBuilder::Record::Cacha
ble::LoadByCols
10.2 0.620 0.775 74161 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::__Value
8.96 0.540 0.490 50630 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::_RecordCache
8.46 0.510 0.360 99879 0.0000 0.0000 Cache::Simple::TimedExpiry::expire
8.29 0.500 0.531 49249 0.0000 0.0000 DBIx::SearchBuilder::Record::Cacha
ble::_KeyCache
8.13 0.490 1.279 48968 0.0000 0.0000 DBIx::SearchBuilder::Record::new
7.96 0.480 0.377 74799 0.0000 0.0000 DBIx::SearchBuilder::Record::__Val
ue
Does this tell me anything? Where should I take this next?
perl 5.8.5
RT 3.2.2
DBIx::SearchBuilder 1.12_01 (grabbed this off of CPAN this past week, can
try 1.11 too)
-jd
Ok, I’ve now been able to successfully use Devel::DProf to profile using
standalone_http. For a larger ticket (that I am currently working on, and
is still open and occasionally added to) here is what I’m facing:
Using &Debug=1 results in:
Time to display: 27.229506
What version of DBIx::SearchBuilder are you using? Your profiling
results imply that you’re not up to date.
-Jesse
Ok, I’ve now been able to successfully use Devel::DProf to profile using
standalone_http. For a larger ticket (that I am currently working on, and
is still open and occasionally added to) here is what I’m facing:
Using &Debug=1 results in:
Time to display: 27.229506
What version of DBIx::SearchBuilder are you using? Your profiling
results imply that you’re not up to date.
Jesse–
Thanks for your help! The profiling results I just sent were from
DBIx::SearchBuilder 1.12_01. From the bottom of the last email:
: perl 5.8.5
: RT 3.2.2
: DBIx::SearchBuilder 1.12_01 (grabbed this off of CPAN this past week,
: can try 1.11 too)
-jd
Ok, I’ve now been able to successfully use Devel::DProf to profile
using standalone_http. For a larger ticket (that I am currently
working on, and is still open and occasionally added to) here is what
I’m facing:
Using &Debug=1 results in:
Time to display: 27.229506
Next question, how big is this “larger” ticket? What SQL is RT
generating on display for the page load?
Jesse–
Next question, how big is this “larger” ticket? What SQL is RT generating on
display for the page load?
Thanks for your continued assistance.
How do you define size? Number of entries? Looks like there are 66 entries
(emails, owner changed, status change, etc) and 4 small attachments (XLS).
How do you want the SQL that RT is generating? I have attached mysql_full.log
(enabled it just for this one query, this one ticket) – I clicked on Display
for this particular ticket and here it is. If you need something else, please
let me know.
Thanks, again!
-jd
mysql_full.log (46 KB)
Jesse–
Next question, how big is this “larger” ticket? What SQL is RT generating
on display for the page load?
Thanks for your continued assistance.
How do you define size? Number of entries? Looks like there are 66
entries (emails, owner changed, status change, etc) and 4 small attachments
(XLS).
How do you want the SQL that RT is generating? I have attached
mysql_full.log (enabled it just for this one query, this one ticket) – I
clicked on Display for this particular ticket and here it is. If you need
something else, please let me know.
That SQL doesn’t look right. There’s some pre-caching that I believe
current RT to be doing that your RT instance is very clearly not doing.
What customizations have been made to your codebase?
That SQL doesn’t look right. There’s some pre-caching that I believe
current RT to be doing that your RT instance is very clearly not doing.
What customizations have been made to your codebase?
I have five files in local/:
local/html/NoAuth/images/evtclogo.gif: Our logo or the top of every page
local/html/Elements/Footer: So we have our name and URL at the bottom
local/html/Elements/Header: To put our logo at the top
local/html/Elements/MyTickets: Needed a custom field displayed on the main
page
local/html/Elements/Quit: Kills the Mason process, so dprofpp runs properly –
per your request
All changes are very minimal, however I’d be happy to send them to you if you
think I’ve dorked something up. Other than these five, this is just a
straight RT 3.2.2 instance.
Where to next? I appreciate your help …
-jd
That SQL doesn’t look right. There’s some pre-caching that I believe
current RT to be doing that your RT instance is very clearly not doing.
What customizations have been made to your codebase?
I have five files in local/:
local/html/NoAuth/images/evtclogo.gif: Our logo or the top of every page
local/html/Elements/Footer: So we have our name and URL at the bottom
local/html/Elements/Header: To put our logo at the top
local/html/Elements/MyTickets: Needed a custom field displayed on the main
page
local/html/Elements/Quit: Kills the Mason process, so dprofpp runs properly
per your request
All changes are very minimal, however I’d be happy to send them to you if
you think I’ve dorked something up. Other than these five, this is just a
straight RT 3.2.2 instance.
Where to next? I appreciate your help …
I don’t expect to have time to triage this myself in more detail any
time in the next week or two. I’d try to get a sense of whether the
precaching of transactions is busted for some reason. And have a look at
whether the SearchBuilder caching is working all right. And whether
there’s anything there that needs optimization.
I don’t expect to have time to triage this myself in more detail any
time in the next week or two. I’d try to get a sense of whether the
precaching of transactions is busted for some reason. And have a look at
whether the SearchBuilder caching is working all right. And whether
there’s anything there that needs optimization.
I understand.
Obviously, the snapshot I sent you was a freshly-started standalone_httpd, but
you’re inferring there should be PRE-caching of some sort (ie, at startup)?
Where would this data go on the local filesystem? Could I possibly have
busted permissions or some other localized problem such that SearchBuilder was
unable to cache as expected? Maybe another perl module that we rely on that
isn’t loading?
Most of our tickets don’t get this many transactions so it’s not the end of
the world, but the feedback I keep seeing on rt-users is that performance
issues are solved with the advent of SearchBuilder 1.10+ and I’d like to be
able to mirror that sort of performance.
Regardless of where this eventually ends up, I appreciate your direction &
feedback over the last few emails.
Take care,
-jd
Hello all,
One of requirements set for our ticketing system is to hide the names of
people who answer tickets by email. So we use “From:” clause in email
templates. However, it doesn’t seem to be enough. Even tough “from” email
can be faked, the email header still contains RT-Originator clause with the
real email address the reply is sent from. I greped the entire RT code and
it doesn’t seem to me that this RT-Originator clause is really used
anywhere, so I think it can be safely removed from SendEmail.pm.
We run RT 3.2.1
Can anybody confirm that this:
$self->SetHeader( ‘RT-Originator’,
$self->TransactionObj->CreatorObj->EmailAddress );
can be safely removed from SendEmail.pm (line 440)
Thanks.
Dimitry