Service select in New Ticket interfase is taking too long to populate
Hi all,
I use otrs 3.1.1 with 17 queue and 483 services on debian 6.0 with postgresql 8.4
when I create a new ticket-mail, select the type, then the tail and all good, but when I select the list of customer service takes to occur more than 30 seconds, sometimes more than 2 minutes which makes it unwieldy the creation of a ticket, a period during which the rest of the site is slow, processes of apache and perl can consumier up to 30% of the CPU and RAM and I note that in postgresql are hundreds of select type queries, for example :
2012-05-14 00:04:15 VET LOG: sentencia: DEALLOCATE dbdpg_p2554_6849 2012-05-14 00:04:15 VET LOG: ejecutar dbdpg_p2554_6850: SELECT id, name FROM service WHERE name LIKE 'Telefonía Móvil::Asignación de Equipo Móvil::%' AND valid_id IN (1) 2012-05-14 00:04:15 VET LOG: sentencia: DEALLOCATE dbdpg_p2554_6850 2012-05-14 00:04:15 VET LOG: ejecutar dbdpg_p2554_6851: SELECT id, name, valid_id, create_time, create_by, change_time, change_by FROM ticket_priority WHERE id = $1 2012-05-14 00:04:15 VET DETALLE: parámetros: $1 = '3' 2012-05-14 00:04:15 VET LOG: ejecutar <unnamed>: UPDATE sessions SET session_value = $1 WHERE session_id = $2
I've checked the tuning manual for otrs, but I think my problem is different, the rest of the site works well and fast response times except when you create a ticket or services listed.
I was looking online for similar problems, the closest thing to my problem I got was this, in the same mailing list:
http://lists.otrs.org/pipermail/itsm/2012-March/001162.html
I have a video[1] where I show the process of creating a ticket and where can be seen in the bottom bar in time firebug debugging response selection combo for those who want to see it.
My questions are:
1) It is appropriate to have so many services? (I did not do the configuration of OTRS) 2) why are so many queries to the database? 3) that information is not stored in cache to make selection faster then? 4) If I type ACL Queue-> Services [2], the charging time will be faster service? and related services only appear to the queue defined in the ACL? 5) as I can make the load time of service is much faster?
Thanks, any help is appreciated
[1] http://dl.dropbox.com/u/16073962/out.ogv [2] http://lists.otrs.org/pipermail/otrs/2010-February/030668.html
Hi Edwind,
Edwind Richzendy Contreras Soto schreef op 2012-05-14 07:15:
- It is appropriate to have so many services? (I did not do the
configuration of OTRS)
Most organizations use less services, typically between 50 and 100, but sometimes also more.
- why are so many queries to the database?
- that information is not stored in cache to make selection faster
then?
OTRS 3.1.3 and up (tomorrow we'll release 3.1.5) will use much less queries to the database; it will use much more caching. What also might help is if you do not store sessions in the database, but on the file system (see Core::Session under Admin > SysConfig > Framework).
- If I type ACL Queue-> Services [2], the charging time will be
faster service? and related services only appear to the queue defined in the ACL? 5) as I can make the load time of service is much faster?
The strange thing is that the queries in your database do not take the most time, right? They all execute in the same second, apparently. It might be interesting, using a profiler, to learn where your system is spending this much time: in the database, or maybe in the application logic. If you want, you can install 'Fred' - a helper tool for OTRS development - from here:
http://ftp.otrs.org/pub/otrs/develtools/packages/Fred-3.1.2.opm
it features Devel::NYTProf integration, so you can analyze exactly what is happening. Of course you should only want to install Fred on a dev machine, NOT on production! -- Mike
2012/5/14 Michiel Beijen michiel.beijen@otrs.com:
Hi Edwind,
Edwind Richzendy Contreras Soto schreef op 2012-05-14 07:15:
- It is appropriate to have so many services? (I did not do the
configuration of OTRS)
Most organizations use less services, typically between 50 and 100, but sometimes also more.
- why are so many queries to the database?
- that information is not stored in cache to make selection faster
then?
OTRS 3.1.3 and up (tomorrow we'll release 3.1.5) will use much less queries to the database; it will use much more caching.
I updated to version 3.1.4 and in fact performance drastically change that view now takes a second or less.
I'll wait until tomorrow to leave the new version for testing and update with that.
thank you very much
What also might help is if you do not store sessions in the database, but on the file system (see Core::Session under Admin > SysConfig > Framework).
I will try this also does not hurt to optimize a bit more performance
- If I type ACL Queue-> Services [2], the charging time will be
faster service? and related services only appear to the queue defined in the ACL? 5) as I can make the load time of service is much faster?
The strange thing is that the queries in your database do not take the most time, right? They all execute in the same second, apparently. It might be interesting, using a profiler, to learn where your system is spending this much time: in the database, or maybe in the application logic. If you want, you can install 'Fred' - a helper tool for OTRS development - from here:
http://ftp.otrs.org/pub/otrs/develtools/packages/Fred-3.1.2.opm
it features Devel::NYTProf integration, so you can analyze exactly what is happening. Of course you should only want to install Fred on a dev machine, NOT on production! -- Mike
OTRS mailing list: itsm - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/itsm To unsubscribe: http://lists.otrs.org/mailman/listinfo/itsm
participants (2)
-
Edwind Richzendy Contreras Soto -
Michiel Beijen