Slow data rate

7 views
Skip to first unread message

AMusella

unread,
Nov 8, 2009, 9:08:59 PM11/8/09
to FusionReactor
Hi
I am new to this... so please be easy on me:)

I am trying to figure out why some pages are really slow sometimes and
not others.. there is one page in particular.. when I hit the page
myself, it is pretty fast.. it is a big page, but when I go to the
url, it takes about 2 -3 seconds to load.
However, it routinely pops up in the longest requests page of fusion
reactor... taking 3 minutes to complete.
the key seems to be the data rate.. when I hit the page, the data rate
is 5 MBytes/s and the page takes 125msec. here is a sample of when it
is slow. the data rate is 2 kbytes/sec,

Is the data rate controlled by my server or is it a function of a slow
connection of the user?

Request
Status: Finished
Status Code: 200 OK
Request Id: 519038
Date: 09:25:35.211 07-Nov-2009
Client Address: 83.25.39.232
Script Name: /btcenters.cfm
Servlet Path: /btcenters.cfm
URL: http://www.virtualtrials.com/btcenters.cfm
Content Type: text/html; charset=UTF-8
Execution Time
Execution Time: 199,218ms
Started Time: 09:22:15.993 07-Nov-2009
Finished Time: 09:25:35.211 07-Nov-2009
Stream Metrics
Bytes Sent: 438,919
Data Rate: 2 KBytes/s
Time To First Byte: +46ms (09:22:16.39 07-Nov-2009)
Time To Last Byte: +199,218ms (09:25:35.211 07-Nov-2009)
Stream Opened: +46ms (09:22:16.39 07-Nov-2009)
Stream Closed: +199,218ms (09:25:35.211 07-Nov-2009)
Flushes: 2
Flags
Is Aborted: false
Stopped: false
Soft Kill Active: false
CP Exclusion: false
Compressed: false
Memory
Used Memory: 89,944,880 bytes (17%)
Max Memory: 517,013,504 bytes
Total Free: 427,068,624 bytes
Allocated Memory: 116,523,008 bytes
Free Memory: 26,578,128 bytes
JDBC
Number of Queries: 1
Average Query Time: 0ms
Total JDBC Execution Time: 0ms
Thread
Thread Name: jrpp-3217

charlie arehart

unread,
Nov 9, 2009, 10:01:16 AM11/9/09
to fusion...@googlegroups.com
The data rate is typically going to be a factor of the client. The common
conclusion is that it's a slow client, like a dial-up user, or perhaps
someone on a phone, but it could be caused by many other things (network
contention among apps within a computer with a fast network connection), so
we ought not jump to conclusions.

Indeed, I would recommend AMusella that you look at the request details (the
blue button to the left of a running request) if you can catch it while
running (or you may be able to see it in the slow/long-running request
page). See the "headers" tab there, and then look at the user-agent, which
often identifies details about the specific client. You may see it's a
phone, or it could even be a bot. Let us know what you see.

But bottom line is, yes, it's a cool thing that FR lets us see these
details. Sometimes people conclude that CF is at fault for such "hang ups",
when it's really the victim. FR shows this happening better than anything
else out there, in many different scenarios.

/charlie

Darren Pywell

unread,
Nov 9, 2009, 7:45:06 PM11/9/09
to FusionReactor
@Charlie: Great explanation!

@AMusella: the group is very friendly :-) We're all out here trying to
keep our servers running healthy. It's a difficult job troubleshooting
problem servers and it can be very stressful too! Everyone needs a bit
of help sometime or other and we all have to start somewhere... :-)

Darren


On Nov 9, 4:01 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:
Reply all
Reply to author
Forward
0 new messages