Skip to comments.Suggestions to possibly make your FR pages load faster [thread II]
Posted on 10/31/2012 6:35:41 PM PDT by Jim Robinson
Very sorry about the problems with our servers causing FR to get bogged down under peak traffic loads. Praying that John finds a solution or workaround soon.
In the meantime, here are some suggestion you can use to possibly make your FR 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:
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 next week after Obama is evicted and the tea party tsunami sweeps the socialists out of office from sea to shining sea, 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 reset your number of threads and replies per thread preferences.
Also, we have FR contingency standby pages on yahoo and facebook. You may wish to visit and bookmark these pages:
Our system didn't actually crash during the debates, but when a hundred thousand or more users tried to access it all at once during a short two hour window, it bogged down to a crawl. Hopefully it won't do that on election day as the window will not be so short. The news and results will be coming in all day and all night. But if it does crash, we can leave messages on the contingency sites linked above.
Thank you all very much and good luck.
Prayers up for our nation.
Thanks for all you do!
Can you make all that the default on election day?
Mine loads just fine—couldn’t be faster.
I’m on a Mac—if that could make a difference.
Mine’s a Mac too, but I had trouble. Did what Jim recommended above and my load time is now 90% faster.
To reset your preferences next week after Obama is evicted and the tea party tsunami sweeps the socialists out of office from sea to shining sea, 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 reset your number of threads and replies per thread preferences.
Thanks - I’ll reduce components.
Jim - this is database contention. Either the database is not a robust enough product, or it’s being bogged down by unnecessary or un-optimized queries and/or stored procedures. ( I posted something about this on the last thread but it timed out :-))
I’m assuming that over time, as features were added, they included an increasing number of queries per request. However, requests to reply and to actually post the reply are what take the longest.
While it’s true that at peak times all queries, including just viewing, get bogged down, at medium-peak, when ‘view’ requests do okay, web requests to reply to posts and then to commit posts are delayed, hang or time out.
Since FR only delivers text and doesn’t actually do the delivery of images or anything heavier, and since there is a discrepancy between ‘view’ requests and ‘insert edit’ requests, I don’t think it’s the web server or pipe-traffic issues.
The discrepancy can be explained by the database itself or communication with the database. Perhaps even a request to post a reply, not the post itself, requires an insert in the database in order to acquire an ID, and perhaps it re-queries to get that ID. otherwise it should behave as a ‘view’ page.
Can’t say - but I’m willing to bet it’s 80% database issues, and the rest is just a result of traffic backup caused by DB issues.
if the database is robust enough for the traffic but still failing, then it’s embedded SQL fired from web server scripts (or against stored procs) - either too many per request, or not optimized (either the sql itself or internally at the DB server.)
There need to be prepared, cached and optimized queries and views, fewer separate queries from page requests and probably an indexing strategy is interfering with inserts based on the discrepancy between read-only page load times and insert/update load times. Could also be a DB resource locking strategy problem explaining the increased time during edits/inserts.
I’m happy to donate time to help, but having dealt with all of this before, unless there are memory issues, which I doubt because the architecture isn’t that complex, diagnosing this shouldn’t be insurmountable.
Regardless - hope it gets worked out, it’s a great community and while I’m sure it won’t get worked out by election time (especially if it is in fact script and/or DB code - which I strongly suspect - rather than hardware or pipe replacement or increase) ... it’s not necessary for it to continue.
I’m not a monthly donor (yet)- kind of waiting for this to get identified. But I don’t think it’s a money issue to diagnose. Again - happy to donate help, and possibly I’m off since I can’t see the code itself - not trying to be presumptuous.
Best - and continued thanks for the site.
Pages seem to load faster with Safari — but it’s still unbearably slow.
not sure how this helps, since I get errors just going to the settings pages.
It took me about 20 tries just to post one small message the other night.
this seems to be the only site that I’ve been consistently having these problems (doesn’t seem to matter when), so it would seem to be either a configuration/database/programming problem.
I managed to open a cached version of the configuration page with Firefox's "undo close tab" and fixed it.
I’m also using Safari—and mine is loading lickety split. Don’t know what the difference could be....
“””””How about setting up FR with levels of services corresponding to what people pay? Free riders would get the forum and a limited self-search, FR mail, etc, but no sidebars or bookmarks.”””””
because it’s jim’s way or the highway.....no ideas from outside are allowed lest you be belittled and put down for offering legitimate suggestions.....
full disclosure....i am a past $1.00 a day donor.....
Yup. And we’ve concluded the same. It’s back to the drawing board design wise to grow to the next level. Thank you very much!!