This is not a complaint about the board’s performance. I am only vaguely aware of the problems, as I don’t post nearly as much as I used to. Rather, I am simply curious from a technical perspective.
In Tuba diva’s announcement, which I just listen to, she used the phrase “death throes” to describe the problems others seem to be having with the board’s performance. This clearly implied that the problem is due to the age of the software. Can somebody explain how that works?
Again, I am not complaining about how the board is performing. I rarely experience the issues alluded to my ownself. I’m just wondering what it means for software to age, something i have heard about in other contexts but rarely.
Software engineers will facetiously talk about “bit rot” causing software to wear out or suffer from old age.
In reality the problem is that most software does not exist in isolation. The environment it operates in isn’t static. The operating system it was initially written to run in, the database it uses to manage its data, the http agent, the user’s browsers that read it, plus the whole evil environment of script libraries that pervade the www. They all change. Eventually things get to the point where operation is unreliable for some reason or another. Something something just plain breaks. Like when an old, long deprecated feature your software uses, in finally actually removed from new versions of systems your software depends upon. Other times stuff you use is abandoned, with maintenance ceasing, and it starts to suffer, passing its ills onto your system.
In this case, it probably means database tables are filling up to capacity, memory usage is increasing to a point where swapping occurs regularly, and the system is beyond its design capacity.
I’ve piles of software , some great stuff too, that won’t run under modern operating systems. I keep old computers around, with old OSes, just so I can use them as needed. Software that relies on someone else’s server farm to run do not have that luxury. They have to ditch the stuff when it stops running well on modern servers. The switch from 32 bit to requiring 64 bit applications has killed a lot of apps, but It’s far from the only thing that kills old apps. Application programming interfaces (APIs) get deprecated and dropped too.
With the rise of iOS and Android phones, a lot of desktop APIs are being stripped of phone unfriendly elements. That can kill or cripple applications too.
A reliable database wouldn’t be running on your phone, though (no reason in principle why a phone might seldom or never crash, but the requirements are different to eg a mainframe or server).
As for modern vs old hardware, I would naively expect the newer hw to be faster, have more memory, etc. so your app would run better. And even super old hardware can be emulated…
That’s not always entirely true IMHO, as changes are made to a piece of software the number of “patches” accumulate and the original elegant architecture begins to degrade, eventually the software ends up being patches on patches on patches and anything you fix in one part breaks something in another, at that point the software is senescent and the better option is to code it again from zero.
I don’t have any inside info but formerly worked in database engine development and support. The current situation is often seen. It is not age of the software per se.
The most common cause is the SQL statements embedded in the client-side app were not properly analyzed and performance tested by the original app developers. The client/server system worked OK at a certain database size and number of concurrent users. But invisibly, under the covers, each statement was taking more resources than it should. As time passes the database has more content and/or concurrent users increase. The aggregate load then becomes unsustainable on the current hardware, causing sudden and rapid performance degradation, similar to how a highway traffic jam suddenly materializes.
By that time the original app developers are long gone, leaving the poor IT people trying to tune the server as a workaround. In a two-tier system, you cannot generally change the SQL statements since they are a designed-in element of the app UI. In a three-tier system it’s more possible they can be changed.
Typical solutions are “shed load” by disabling certain resource-intensive operations such as search, or beef up the hardware. In some cases the database can be physically reorged or indexes optimized while keeping the current app. The benefit and feasibility of those steps vary.
I had some very nice programs (a spell checker that I had carefully trained for TeX, a useful version of BASIC,…) that were 16 bit and Win 7 and beyond simply stopped running it. There were no upgrades available. And I still have not found an adequate replacement for the program–what was it called–that allowed access to French and other accented letters in the upper 128 extended ASCII set. I have a program called Win-Compose, but it never worked right.
In the present case, I think SDMB has fewer users and so running out of memory is not the issue.
This is the generally correct answer, with the additional variable that it’s possible the system could keep up with current load with better infrastructure/resources but it’s not a guarantee. Sometimes people code things in a way that the growth in data volume causes the need for resources to grow exponentially.
Others mentioned a couple other factors:
1 - Evolution of surrounding ecosystem (os’s, db’s, frameworks, libraries, etc.) causing instability
2 - Evolution of the system itself causing instability due to piece-meal changes without overall refactoring
Both of those are real factors that happen all of the time, but I don’t think they apply in the case of the SDMB:
1 - SDMB performance issues have existed on and off for decades - I assume it’s due to mysql ISAM table locking and limited hardware resources. If it’s partially due to mysql table locking then that is a known weakness and generally very poor design for any kind of concurrency.
2 - I doubt the vbulliten SQL code has been frequently customized, I’m betting it’s generally unchanged
Which immediately reminds me that virtualization of WinXP and Win2003 is very poor, requiring an inordinate amount of cache swapping, similar to the effect of the “Meltdown” and “Spectre” and “Zombie Load” mitigations.
We don’t know the environment in which TDSMB is running: certainly there is no money to improve it.
It helps me to think of software as similar to a house.
My brick house doesn’t really have ‘brick rot’, but it will stop working without maintenance.
There is maintenance needed on the house itself: roof shingles needed replacing a few years ago, mortar needs patching occasionally, etc. And one bathroom recently effectively stopped working. There were problems with pipes leaking, poor water pressure, etc. so that I gutted it and replaced the plumbing & most fixtures. The plumber remarked that he could see a century of plumbing technology in the walls – every type of the past century was present in the additions & patches inside the walls.
And there is maintenance needed to keep my house working with the other systems it’s connected to. The gas company is changing the gas pipes in the streets, replacing them with higher-pressure ones, and when the get to my neighborhood they need to put a new reducing valve at my gas meter. And the water department has replaced the whole meter twice during the years I’ve lived here. And I wanted more electricity, which the electric company was happy to supply, but I had to pay an electrician to add bigger wires from their pole to my house.
Software is similar. Like my plumbing, over the years it accumulates so many patches & additions (by many different workers besides the original designer) that it stops working. And like my house, it connects to outside (operating) systems, and has to adjust when those systems are upgraded.
It helps me to think of software as similar to a house.
My brick house doesn’t really have ‘brick rot’, but it will stop working without maintenance.
There is maintenance needed on the house itself: roof shingles needed replacing a few years ago, mortar needs patching occasionally, etc. And one bathroom recently effectively stopped working. There were problems with pipes leaking, poor water pressure, etc. so that I gutted it and replaced the plumbing & most fixtures. The plumber remarked that he could see a century of plumbing technology in the walls – every type used in the past century was present in the additions & patches inside the walls.
And there is maintenance needed to keep my house working with the other systems it’s connected to. The gas company is changing the gas pipes in the streets, replacing them with higher-pressure ones, and when they get to my neighborhood they will need to put a new reducing valve at my gas meter. And the water department has replaced the whole meter twice during the years I’ve lived here. And I wanted more electricity, which the electric company was happy to supply, but I had to pay an electrician to add bigger wires from their pole to my house.
Software is similar. Like my plumbing, over the years it accumulates so many patches & additions (by many different workers besides the original designer) that it stops working. And like my house, it connects to outside (operating) systems, and has to adjust when those systems are upgraded.
Imagine your software is a car. It does what it needs to do, gets you where you need to go, and you are happy with it.
Over time they develop hover cars. Hover cars can zoom around everywhere without roads, can travel on straight lines regardless of geography, and so on. People love them and quickly ground cars become antiquated. But you keep your car because it runs fine and does what you need and you already own it.
Years pass and roads stop being maintained. It’s a waste of money to maintain them, since few people use them. Everyone is flying everywhere. You lose access to highways because they get shut down as public dangers. You can still drive around town. It’s bumpy with all the potholes but you can go to the store or head over to see a movie. Parking is awkward because parking lots are replaced with hover pads you can’t go on, but you manage. Also, bridges are all gone because they aren’t needed and are unsafe now that they aren’t being maintained so you’re really limited.
More years pass. Roads everywhere are being removed so that more trees and parks can be planted in their place. You can’t really drive your car anywhere because it’s not designed for off-road travel. You could get it towed to one of the nostalgic race tracks people use to watch old-style ground cars but it’s not really worth the expense and time. Your car can run perfectly fine but since the rest of the world has moved on, it is for all intents and purposes a “dead” technology. Your best bet is to donate to a museum or sell to a collector and buy a practical hover car.
This is basically what happens to software. The code doesn’t stop being good, but finding an environment to run it in is hard. You could run it in an emulator that mimics an old game environment (like the nostalgic race track) but that’s often impractical compared to just getting new software that is probably superior anyway.
Speaking as someone who knows bupkis about software design, I’d like to acknowledge that both of these metaphors are illustrative and illuminating. Thanks!
Don’t 500 series error messages indicate problems with the servers themselves – e.g., misconfiguration or trouble talking to other servers – and not problems with application software? Perhaps the SDMB hosting service is having problems that have nothing to do with the SDMB bulletin board software.
As has been said, it’s not ‘tired’ or worn out. its just that it no longer plays nice with others. Or really, others don’t play nice with it and it gets left behind. Imagine a friend that still acts like they are in third grade when you are in High School. Environments change.
I’ve two legacy systems at work that we are replacing. I wrote one of them. It can be a difficult situation if you also have ‘legacy’ employees that are used to a product that works for them.
I wasn’t looking for insight information on the board. I don’t post enough these days to have really noticed the errors people seem to be complaining about; yesterday was the first time I had gotten a 504 error, and it wasn’t a real problem for me. My question was born simply from curiosity.