I’ve come across an interesting situation where impatient users get
punished for clicking around too fast. If a page load is interrupted,
especially one returning a good-sized chunk of data (like a ticket
search or detail), the socket connection gets put into a CLOSE_WAIT
state that takes a long time (hours) to go away. For that user, RT
becomes unusable until s/he restarts the browser, at which point
everything is fine again.
Apparently this is a known HTTP flaw, but it is much more pronounced
here than on any of my other webapps (none of which use Mason). Both
the web and database servers have plenty of CPU/RAM/swap, etc. Anything
I can do to speed up database queries and pageloads? Sorry this
question is so general, but so is the problem.
I’ve come across an interesting situation where impatient users get
punished for clicking around too fast. If a page load is interrupted,
especially one returning a good-sized chunk of data (like a ticket
search or detail), the socket connection gets put into a CLOSE_WAIT
state that takes a long time (hours) to go away. For that user, RT
becomes unusable until s/he restarts the browser, at which point
everything is fine again.
Apparently this is a known HTTP flaw, but it is much more pronounced
here than on any of my other webapps (none of which use Mason). Both
the web and database servers have plenty of CPU/RAM/swap, etc. Anything
I can do to speed up database queries and pageloads? Sorry this
question is so general, but so is the problem.
RT 3.4.4
Apache 1.3.33
Oracle 9.2.0.4
Solaris 8
I’m having the same config except we are running RT 3.4.3 and haven’t
had this problem. I just tried a couple of heavy operation like
searching on ticket content and aborting the search but I can start a
new query right away. Maybe it is because we’re running RT using
mod_perl (Apache/1.3.33 (Unix) PHP/4.4.0 mod_fastcgi/2.2.12 mod_perl/1.29 mod_ssl/2.8.23 OpenSSL/0.9.8)
Further info that might help. System is a Sun/Sparc Solaris8 420R with
4CPU and 4Gb of memory. Its main use is running RT with a couple of
other light webapps such as Openwebmail/WebCalender/FaqOmatic. Oracle
9.2.01, relevant parts from init.ora:
large_pool_size=8388608
shared_pool_size=115343360
db_block_size=8192
db_cache_size=25165824
db_file_multiblock_read_count=16
So almost no tuning, except for a context index on attachments.content
and a modification in Searchbuilder to use that index when searching for
ticket content.
Apparently this is a known HTTP flaw, but it is much more pronounced
here than on any of my other webapps (none of which use Mason). Both
the web and database servers have plenty of CPU/RAM/swap, etc. Anything
I can do to speed up database queries and pageloads? Sorry this
question is so general, but so is the problem.
I’m having the same config except we are running RT 3.4.3 and haven’t
had this problem. I just tried a couple of heavy operation like
searching on ticket content and aborting the search but I can start a
new query right away. Maybe it is because we’re running RT using
mod_perl (Apache/1.3.33 (Unix) PHP/4.4.0 mod_fastcgi/2.2.12 mod_perl/1.29 mod_ssl/2.8.23 OpenSSL/0.9.8)
Actually, what’s going on is that Apache-Session locks your session
object to prevent corruption from a second hit whilst the first is
rendering. It might be safe to turn off Apache::Session locking.
Apparently this is a known HTTP flaw, but it is much more pronounced
here than on any of my other webapps (none of which use Mason). Both
the web and database servers have plenty of CPU/RAM/swap, etc. Anything
I can do to speed up database queries and pageloads? Sorry this
question is so general, but so is the problem.
I’m having the same config except we are running RT 3.4.3 and haven’t
had this problem. I just tried a couple of heavy operation like
searching on ticket content and aborting the search but I can start a
new query right away. Maybe it is because we’re running RT using
mod_perl (Apache/1.3.33 (Unix) PHP/4.4.0 mod_fastcgi/2.2.12 mod_perl/1.29 mod_ssl/2.8.23 OpenSSL/0.9.8)
Actually, what’s going on is that Apache-Session locks your session
object to prevent corruption from a second hit whilst the first is
rendering. It might be safe to turn off Apache::Session locking.
I’m testing this in development (2-line change in SetupSessionCookie)
and it definitely speeds things up. I also discovered that regularly
reaping the files in $RT/var/session_data is a must.
I also played around with enabling Apache::Session::Oracle but got some
strange behavior. Was this your experience too?