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.
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!!
Interesting analysis, it sounds like you have some expertise in database design and optimization. FR is a treasure trove of expertise in countless disciplines. Given your expertise don't miss his quoted post below.
FR is broken. Hours before the last debate half the posts concerned when FR would crash.
Even today I get "Server busy" errors day and night - even at "non-peak" times on short threads with 5 posts. I'm on cable with 20MBPS guaranteed and tested. During the debates any site I visit just pops up like magic - except FR, my home. Sigh.
FR software is proprietary - homegrown but the compilers, language base, support routines, hardware, etc. all could figure into the problem but our expert FReeper user base have no idea what the layout is so its impossible to do more than offer generalized "maybe its this ..." suggestions.
My proposal:
POST AN INFORMATION/TEST THREAD - Put it in breaking news
Get JohnRob to post three paragraphs outlining the physical layout/net connection; the base software and support routine info and lastly perhaps revive access to hits, throughput, logins etc.
We used to be able to see the FR usage stats but all my old links are dead.
Give the FR community some info on the system layout above source code level and then maybe one of our own can spot a fix. Before election night would be great. ;-)
From an earlier thread, from the man himself, as "detailed" in describing the problem that I've seen:
"To: YaelleThe system is not handling the increased loads and we do not know why yet. John says the system is not getting overloaded, the db is not overloaded, the cpus are mostly idle, the load averages are low, the db load averages are low, just reaches a point where throughput stalls. I’m not a techie and I have no idea how to fix it. I thought maybe we could add another server or more RAM or replace some older servers or something, but I guess John doesn’t think that will do it. There’s something wrong in the system software or the configuration but he’s having trouble finding it.
And I’m really upset too, but there’s not a freaking thing I can do about it until John gets it figured out.
Thanks.
63 posted on Wednesday, October 17, 2012 2:01:19 PM by Jim Robinson (Resistance to tyrants is obedience to God!!) [ Post Reply | Private Reply | To 45 | View Replies | Report Abuse]"
Give us some real information to work with - your FReeper minions would be happy to analyze, assist with "Testing - Do not reply" posts, pre-election night tests, whatever. Please? ;-)
Preview gave me a "Connection timed out error" ... fingers crossed.