In my case there are times when I can’t access the site at all for long periods of time. A half an hour or more. Which may represent the only free time I have for most of the day to browse and respond. It’s not a matter of, “oh I need to click again”, it’s a matter of having to completely give up on the site and find somewhere else to visit. (For that time, I don’t mean forever of course; I’m still here after all!)
So, no, you’re not experiencing the real issues. You are fortunate.
Another way is to use your browser’s back button, then click preview post, scroll down a bit and see if your post has already gone through. Modern browsers should remember what you typed, so you have another chance to copy your post to the clipboard.
I do either of the ways you described, and they almost always work. I think your mention of “modern browsers” is significant, because the trick with the back button never used to work. You used to lose your entire input when you backed up. It’s some progress that the browser now holds onto it.
One thing that may be beneficial to saving the membership is to increase the timeout of the gateway. It won’t make the board faster, but it will allow the pages to eventually load rather than getting a 5xx error.
That is kind of how the board used to work a long time ago when it had performance problems. The board was so slow I would often open threads in new tabs and then go surf somewhere else while the tabs loaded. Even though the tabs took a while to load, I didn’t really mind since they eventually came up. I prefer that kind of sluggish behavior to the 5xx errors where I have to reload. Setting a longer timeout in the gateway should make the behavior more like the the old performance problem.
Was the suggestion that people write in tiny font serious? I have vision issues and can’t read the tiny font.
I get Time Out errors no matter what tricks I try. Just clicking on one of the boards often means a long delay. I’ve tried stopping the page from loading after the little loading circle makes 12 circuits (because I’ve found if it goes longer, I get the error message). I’ve tried Preview Post. I’ve tried waiting 30 minutes after two tries are unsuccessful. When the server is in a mood, nothing I do makes it cooperative.
I’m at a loss to understand why trying to post often means a long wait and then the time out error message when the post has, in fact, appeared on the thread.
I wish I could say “Of course not!” But in light of recent events, yeah, we have to admit it’s a possibility.
DON’T PANIC. DON’T PANIC NOW. WAIT AND PANIC LATER.
Management is doing its best to keep it as stable as possible until it can go to The Next Thing. In that light and in view of the fact that we are not working with bottomless pockets here, looking at the fact that this Next Big Thing is what we will have to deal with for years and years, it’s no good to throw resources at the current system but rather use what we have for the best possible solution going forward.
That is what’s happening. I realize this is awful for what you’re having to use now but I hope you can understand the rationale behind these choices.
Has anyone on in the SDMB or its owners gone so far as to estimate how much the Next Big Thing will cost? Because you mentioned, I think, that you might be willing to accept contributions from the members and I’m wondering if it’s an amount that we could cover. (Are we talking $500, $5,000, $50,000 or $500,000?) I know that people have suggested, in years past, that members would be willing to contribute but we were told, by the prior administrator, that this was not possible, since the board was owned by a for-profit company.
That may be more transparency than I was prepared for :eek:
Here’s an out of the box thought. Let Sun-Times Media spin the board into some sort of LLC, with 51% ownership. The other 49% would be sold off in an IPO to the Teeming Millions, with the funds going to the shiniest, most spiffy, up to date, speediest whatever this thing is under the hood.
Heck, we’ll even let TPTB keep all the advertising revenue!
Unofficially I got offhand quotes that totaled a little over a couple thousand dollars; could be more if the details were right.
People were cautious and understandably so. People that I know are on little budgets said they would give what they could and that touched me more than anything. I know myself how hard come by that kind of thing is.
Everyone was generous within the limits of what they could do and what they were willing to commit to.
I thank everyone who wants to support in every possible way.
Asked management about that and they would like to investigate that further but asked that we belay everything until we are on the new thing. They are seriously interested in ways to monetize the Dope in useful ways that helps haul the freight.
We will get into all of this at the appropriate time. In the meantime, stand by and thanks.
When a database engine is designed there is a tradeoff between locking granularity, overhead and concurrency. Coarse-grained locks (like table locks) have low overhead but poor concurrency. Row-level locks have high overhead but good concurrency. Page-level locks are in between.
In a two-tier client/server system, the client-side app uses SQL statements which are tied to certain UI elements. This in turn depends on specific server-side locking behavior. After a system is deployed the IT people can typically only adjust server-side tuning such as indexes. They cannot generally adjust client-side SQL statements which are a designed-in part of the app UI, nor locking behavior.
It is unfortunately common that the original app developers use SQL statements and a back-end database design which has scalability problems which only becomes apparent as the database grows or as concurrent users increase. By the time that happens, the app developers are gone and the poor IT/admin people are stuck trying to tune around the problem.
The most common cause is the original designers and testers did not do adequate scalability testing. Each SQL statement must be designed as “lightweight” as possible, so when inevitable growth later happens the aggregate load is sustainable. This requires the app developers to be diligent, analyze I/O behavior of each SQL statement, understand how the SQL query optimizer works, and do scalability testing. That is often not done adequately.
Less frequently, the server hardware is not sufficiently upgraded to keep pace with growth in data and concurrent users.
By the time the problem becomes serious, typical solutions are buy faster hardware, or adjust database indexes. This may be expensive or have limited benefit. It also requires significant technical expertise to analyze and understand what server-side parameter is limiting performance and how to address that - if possible.
In some cases the app allows disabling resource-intensive operations such as search, so you often see forum software with search disabled or severely restricted. If the forum content is available to Google indexing, sometimes the forum will just say “use Google”.
In a three-tier design there’s a database, a middle server with business logic (inc’l SQL statements) and the client side app. This decouples the UI part from the SQL statements so in theory allows changing databases without major client-side app changes: Multitier architecture - Wikipedia