Skip to comments.A couple of suggestions to possibly make your pages load faster [UPDATED]
Posted on 10/29/2012 11:49:58 AM PDT by Jim RobinsonEdited on 10/30/2012 2:16:38 PM PDT by Jim Robinson. [history]
Very sorry about the problems with our servers causing FR to fail under heavy traffic loads. Praying that John finds a solution or workaround soon.
In the meantime, here are a couple suggestion you can use to possibly make your pages load faster:
Select "Disabled" in the "Region" pulldown for each sidebar block you wish to temporarily disable then click "Modify":
And its simply a click to toggle "Brevity" from "Text" to "Headers" or back the other way when needed: http://www.freerepublic.com/tag/news-forum/index
If enough of us did this we would reduce the amount of data downloaded on each click, reducing the load on the database and the server and possibly increasing overall systems performance.
To reset your preferences later, click on "Account" at the top of any of the main index pages and then "Manage Blocks" to configure your sidebars and "My Preferences" to set your number of threads and replies per thread preferences.
Thank you all very much and good luck.
thank you sir
Ok, worth a try.
Thanks and done.
JimRob how about you just change everyone’s settings yourself, right now, in the database
when things are like this you HAVE TO take dramatic action.
It hurts NO ONE, but FR being crashed would be a problem.
(it would kill me - I would be jonesing in an hour)
Do you need some help? I am a computer systems engineer- I can VOLUNTEER some time and maybe even get some new servers for you
Jim, thanks. These suggestions helped some with loading speed but the big bottleneck still seems to be in the posting code. FR suffers the most when a thread is busy enough that more than a few people want to post to the same thread at the same time. Then we get the 3 Stooges in a Doorway Effect and nothing moves.
Works much faster for me. Thanks Jim!
Worked like a charm! Thanks!
A few suggestions for your consideration:
As it stands now, the only difference between a “live thread” and any other thread are the words in the title.
It might be useful to formally define the live thread as a unique thread type that would be specified at the time of the initial posting, or perhaps after the fact by a moderator.
Certain limitations would be imposed on anyone posting on that thread that would materially reduce the loading on the FR servers (and the poor little squirrels that run them).
The live thread specification would include the reduced posts-per-page setting you mentioned.
Another possible load-reducer might be to default the “I have already previewed...” selection to the checked state.
Since a lot of the activity on a live thread is just refreshing the page to see new posts, it might be helpful to block any user that posts or refreshes from another action for a short time, maybe 30 seconds or a minute, just to calm things down a bit. Maybe the block would best be just on a refresh request, and let the posters get priority. That might also cut down on duplicate posts.
Finally, a few years ago I saw a post by another FReeper, whose name I have long since forgotten, that was promoting some piece of software which overrode the FR pagination scheme and allowed a more visually appealing presentation of thread contents, with colors, indentations, linkages, and the like.
I tried it out, thought it was interesting, then deleted it.
I realized that to work, it required the entire thread to be downloaded. That wouldn’t be a problem on a short thread, but on a live thread that can easily run over 1000 posts, it would absolutely kill the server. I tried it on a long thread, and it took forever to fully load the thread.
I don’t know if anyone’s actually using this software, or if they are, if there’s any way to block it on a long thread.
Boss, I don’t think it’s FR:
Tracing route to www.freerepublic.com [126.96.36.199]
over a maximum of 30 hops:
[Redacted first 8 hops to keep fumbly fingers from bothering me]
9 25 ms 22 ms 23 ms xe-0.equinix.asbnva01.us.bb.gin.ntt.net [206.223
10 22 ms 21 ms 21 ms ae-6.r21.asbnva02.us.bb.gin.ntt.net [188.8.131.52
11 181 ms 179 ms 184 ms ae-4.r20.snjsca04.us.bb.gin.ntt.net [184.108.40.206
12 198 ms 197 ms 204 ms ae-1.r07.snjsca04.us.bb.gin.ntt.net [220.127.116.11
13 233 ms 233 ms 137 ms xe-0-2-0.r20.mlpsca01.us.bb.gin.ntt.net [129.250
14 92 ms 160 ms 96 ms xe-6-4.r03.mlpsca01.us.bb.gin.ntt.net [129.250.3
15 117 ms 96 ms 100 ms mg-2.a00.mlpsca01.us.da.verio.net [18.104.22.168
16 98 ms 96 ms 93 ms mg-1.a01.mlpsca01.us.da.verio.net [22.214.171.124
17 98 ms 100 ms 100 ms 126.96.36.199
18 93 ms 96 ms 94 ms 188.8.131.52
Those backbone servers shouldn’t be showing those triple digit latency times.
I think this should be in breaking news, so everyone will see your suggestions for a speedier FR!
Are you sure there isn’t any sand and water getting the FR servers from the hurricane that could be cleaned out?
Hope this helps!
I ran / posted tracerts on two of the debate threads, verified with info posted by others, and the nodes at ntt.net (mainly) and verio.net (lesser extent) have consistently been a huge drag on transit times.
That’s odd. I was able to reset everything without logging out and from my old Android tablet. Hmmm...maybe I better double check when I can get to my main home machine.
You might want to ping the Q&R group when you get a chance, this seems to work!
I’d do the ping but I’m on my tablet...also cooking sgetti sauce and keeping an eye on the weather. My weather radio is going off non stop.
That worked well. I disabled several blocks as recommended in #1. I did not do anything as to #2.
Result...from a 10 second delay to a 4 second delay, which is probably the best that can occur on my broadband download.