Why is submitting/updating a ticket SO SLOW

Hi List,

I’ve gotta assume that we are all not having the performance
issues I’m having.

When submitting a update to a ticket via the web interface
it will take 18 to 35 seconds for the server to respond.

This should be a

UPDATE where ticket = ticknum

style SQL update. Otherwords its not rocket science to insert/update
this into the sytem.

Hey Best Practical!! I’ve posted a number of performance queries
haven’t heard from you guys at all.

Given the current speed issues I’m not very motivated to PAY
BP a maint contract. A DB with less than 150 tickets, 6 users
should be way faster than this…

I really need to get the performance issues resolved, or drop
this code and go purchase a commercial product.

cheers

john brown

This should be a

UPDATE where ticket = ticknum

style SQL update. Otherwords its not rocket science to insert/update
this into the sytem.

Perhaps if you looked at the code, you’d see it’s not quite as simple as
you assume.

xoxo,
Andy

Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance

I’ve gotta assume that we are all not having the performance
issues I’m having.

good assumption, we are not all having those performance
issues.

Hey Best Practical!! I’ve posted a number of performance queries
haven’t heard from you guys at all.

You’re whining to rt-users, a list full of volunteers and community
members. If you want a response from Best Practical contact them
directly, sales@bestpractical.com.

Given the current speed issues I’m not very motivated to PAY
BP a maint contract. A DB with less than 150 tickets, 6 users
should be way faster than this…

I really need to get the performance issues resolved, or drop
this code and go purchase a commercial product.

You have a weird problem, that sounds like a site issue. You have many
choices, the three obvious ones are:

You can mail rt-user, in the hopes of getting community advice, you
got some. It even seemed like good advice to me, but I admit I
wasn’t paying much attention to that thread.

You can hire hire a contractor to help, I certainly haven’t seen
you try.

You can hire Best Practical, they’re professionals. You pay them,
they help you. Further, their rates are quite reasonable.

Threatening to drop RT in favor of some unknown commercial product is
really not a very good way to make friends. And when you’re asking for
free help, friends are exactly what you need.

seph

The subject of this thread is inaccurate. John doesn’t want to actually
know why ticket updating is slow. He just wants it fixed. It’s an
important distinction, as we’ll soon see.

I really need to get the performance issues resolved, or drop
this code and go purchase a commercial product.

It’s clear that a “commercial” product would be best in your situation
situation. An open source product is not a good fit for your needs.

First, you’re not taking advantage of the technical fact that RT is open
source. The code is open, but you’ve not availed yourself of taking a
look at the code. You apparently have some programming knowledge, so
I must assume that this is an issue of not wanting to take the time,
rather than one of not understanding it. Time vs. cash is certainly a
fair tradeoff to be made, and no one would begrudge you that.

Second, you’re not aware of, or perhaps choose to ignore, the social
aspects surrounding open source. Your attitude of entitlement and
willingness to alienate all of your potential sources of help makes
this clear. Part of the price tag of someone selling software is taking
shit from customers.

If you’re not going to look at the code, and you’d rather gripe about
your problems rather than work to get them solved, then by all means, buy
the commercial product. Microsoft is right down the hall.

Andy

Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance

I have little knowledge of InnoDB, so I apologize in advance if this ends up
being a dumb question.

First, how do I know if RT is using InnoDB tables right now? I’m running
4.0.14. There are ibdata files and such.

Second, if I am using them and decide I want to tune them by using the
different settings in the my-{small|large|huge}.cnf files, I’ve noticed in
the past mysql complains when I restart. I usually have to delete the ibdata
files and then restart. Is that safe?

Third, I assume doing a mysqldump of the DB will give me everything,
including what would be in those tables, so I know my backups are complete?

I’m still reading thru the link I’ve been seeing floating around here:
http://www.innodb.com/ibman.php

So no need to provide. :wink:

Thanks in advance for answering probably simpleton questions…

Brent

At 05:19 PM 3/30/2004, Brent Wiese wrote:

I have little knowledge of InnoDB, so I apologize in advance if this ends up
being a dumb question.

First, how do I know if RT is using InnoDB tables right now? I’m running
4.0.14. There are ibdata files and such.

SHOW TABLE STATUS FROM rt3;

Look at the type column.

I usually have to delete the ibdata files and then restart. Is that safe?

Hmm, its not entirely clear to me when log file pruning happens. Generally,
for similar database formats (like Berkley DB), it is not consider highly
reliable to count on the log files for regenerating an entire data file.

Third, I assume doing a mysqldump of the DB will give me everything,
including what would be in those tables, so I know my backups are complete?

Yes, mysqldump dumps out the SQL contents of the database regardless of the
underlying table type.

Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”