FYI, there are a few images that are served from non-PP servers, even if they appear to be a single pixel.

I can't cut/paste the text, so here's a screen cap to show you.http://forums.pelicanparts.com/uploa...1323127939.jpg

(Also sucks that PNG isn't an allowable upload graphic format)

Sure, it may be that the core PP pages are served from you, but the reality is that more than a few pages have embedded content in them of some sort or another.

To be clearer about my last post, I meant that the embedded content is a result of other posts in the thread, and realistically there's nothing you can do about it on your end.

Oh... and one other thing I've noticed is that a page load (even a virgin one), can sometimes hang for a 2-Mississippi on Google Analytics, even if it's not actively serving content to the page.

There have been three threads regarding these issues in the last few weeks.. And numerous people have chimed in that they are having page loading issues...

Perhaps there is a problem in the pipeline... When people from all over the country(world) say there is a problem.... then perhaps there is...

I can surf PP on instance and it loads blindingly fast... a few minutes later pages loads time out...

I just did a tracert... not sure where these hops got hung up


http://forums.pelicanparts.com/uploa...1323130831.jpg

oops the pic isn't that clear..... after 13 hops.... it times out at 216.3.101.50

I've seen spotty performance issues over the past 3 weeks or so using at least 4 browsers (FireFox, Chrome, Safari and IE). My daily driver is Chrome but the site seems to be "stuttering" and all other sites come up fast. No pattern to the slowdowns that I can see...

It just slowed down at 7:35. Nothing happened for three minutes...Than it went back to normal.

Sometimes when I go from page 1 to page 2 on off-topic for example it can take 30 seconds to a minute.
It happens only on this website. Watching the video Wayne posted showing the website it stopped on me at 22 seconds then started again.

12:04 am EST, just happened again. Took @ 1 1/2 minutes to load a thread I clicked on. Seems to be OK now.

I'm on an iPad right now also.

It almost presents itself as if the web request is waiting for a thread to answer the request, in that when it does get a response, the response is fast, but there may be a substantial initial wait in a queue for that response to be handled. I'd also almost think the performance is related to available sockets. I generally tune a web server such that the TCP fin_wait and stuff is way, way shorter than usual... as in 15-20 seconds cleanup rather than the default.

This would show up as a non-contended box (cpu/mem/disk IO all being idle or nowhere near maxed) but would have **** for actual end-user performance.

But yeah, performance has been very hit and miss.

I'd also check your DB connection pool... see how those connections are being utilized. They can act the same way as web server threads/handlers, and can cause queuing from the app server. You could have X available DB connections, but X+1 requests from the app server, for instance.

It can be a fine line bumping up the available DB connections to provide enough to serve the app server without configuring so many that you get diminishing returns from the management of those connections/threads.

Not really sure of your technical stack, or the specifics of the configuration, but if you want to PM me I can offer some deeper advice on how to monitor and tune that stuff, if you want.

(I design and implement global online video game systems that handle 30+ million concurrent users, and specialize in tuning said systems... needless to say I've got a bit of experience doing this kind of stuff)

I hope that fixes the problem Wayne. For the last several weeks the forum would get so slow I would just leave and come back later. You might not be seeing it on your end, but plenty of us have experienced it on our end.

This is almost always an internet connectivity problem. Usually from the desktop side (your problem), sometimes from the server side (their problem). It is not the browser.

It's been better since you rebooted the servers.

For me anyway.

Thanks again for letting us hang out here.

Seems much better the past day or so. There has definitely been intermittent problems for the past month or so.

Hah, just posted that, then went to the top of the page and clicked "Off Topic Discussions" in the nav breadcrumb. Took a very long time.

Web logs only tell a small subset of the actual duration of a request from a browser.

What I've done in the past is set up some sort of network intrusion detection that detects and logs the life of the entire web request at the network layer, and then correlate that with the server web logs. In the case of internal queuing, or handler waits, etc., they won't show up in your typical web server logs because those only log the events once it actually gets to a handler. If there's a wait before that, it won't show it.

If you compare the web log duration/times with the lifespan of the socket from the ID logs, you may find a discrepancy.

Some of the stuff you have to set up to log explicitly in whatever OS you're using... like adding a specific IIS or kernel metric in the Windows Perf Log (or whatever the hell it's actually called).

$0.02

And yeah, I, too, am still getting sporadic waits, where it seem the request goes out, but up to 20 seconds for a reply.

I can do some packet sniffing/snarfing for you if you want to see what's going on from my end.

Also, you can accomplish the same thing by running something like Wireshark on your upstream box and capturing 20 mins of packets for analysis. Or, if you're running some semi-professional network gear, clone the appropriate upstream port on your firewall and use a separate box to capture the traffic so it won't interfere with your system. (Sometimes the act of measuring or monitoring stuff can adversely affect things to the point where the problem won't manifest any more).

You can fairly quickly track the sessions and look for ones that have abnormally long durations, cut them out of the data, and take a really close look at what's going on at a packet level.

That's where I'd start.

Still getting hangs and slow page loads... not as bad as last week...

pings and tracert still hang occasionally but not as bad as before... apparently the problem is in the pipe... and you don't see that since you are on the other side of the bottleneck..

going fairly good today, but my pings are not as good as yours

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\dray>ping forums.pelicanparts.com

Pinging forums.pelicanparts.com [207.136.153.227] with 32 bytes of data:
Reply from 207.136.153.227: bytes=32 time=77ms TTL=118
Reply from 207.136.153.227: bytes=32 time=76ms TTL=118
Reply from 207.136.153.227: bytes=32 time=77ms TTL=118
Reply from 207.136.153.227: bytes=32 time=77ms TTL=118

Ping statistics for 207.136.153.227:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 76ms, Maximum = 77ms, Average = 76ms