On
16 January 2024 at 07:04 JasonB Said:
On
15 January 2024 at 19:03 JasonB Said:
…
Jason sorry can’t resist ‘why is the log that bad or that long ?’
H
The log in problem was first reported around the beginning of December and only affects some members, some of the time. Both Myself and Dave have suffered with it and Even Andy last week was able to replicate the problem. …
IanP mentions letting members know when each problem has been dealt with, I’ve several emails saying the log in problem “should be sorted now” but here we are with it cropping up again so I think that would make Mortons look worse if they kept posting that things had been fixed only for them to break again a few days later
The login problem is one of several bugs that appear and disappear, or affect some but not others, or cause other temporary misbehaviours. Recently, I couldn’t login at all whilst Jason had no trouble. Now, as far I as can tell, login is 100% reliable ! Based on what I see, this bug is fixed, therefore the error must be at Jason’s end. Actually, I trust Jason – something is still wrong!
Unreliable behaviour is characteristic of an overloaded computer. The application, in this case WordPress with plugins, may not be the root cause at all. The issue is deeper inside the system. Behind the scenes, the system shares memory, IO, CPU time and other resources between many processes and users. Done with interrupts and various types of queue. The system protects itself from overload by applying quotas, so if an application does not clear a queue of user requests fast enough, the system doesn’t fail: instead the application crashes, or drops user requests in mid-flight. It’s akin to popping a circuit breaker that resets automatically until the next overload. The bugs are the consequence of bottlenecking rather than bad logic. There is a lot of queuing going on: WordPress, the database, and many plug-ins are all multii-threading, and if a thread breaks the user has a problem.
Whether or not the application misbehaves doesn’t depend on one user, it depends on combinations of activity. System fail possibilities due to timeouts and failed transactions include:
- Poorly written plug-in(s)
- Misconfigured WordPress
- Poor choice of database manager
- Misconfigured Database Manager causing time-outs
- Bad data structure
- Missing or inappropriate indexes
- Database and/or Application exceeding one or more Operating System quotas
- Host has insufficient memory, or disc system too full
- If Host is a Virtual Server, then other customers or maintenance may be overloading it,
- Network connection too small or too slow, or traffic exceeds quota setting
Bugs of this type can be extremely difficult to fix: the developer may not be able to reproduce them, and, in the absence of smoke, is forced to wade through the logic and documentation looking for potential causes. Having found a likely candidate, a change is made, which might appear to have worked, but the test result was misleading. Overload problems have other nasty characteristics. For example, if the network connection is bottlenecking, an expensive and possibly bad answer is to pay big money for more bandwidth. A cheaper, easier and faster answer might be to reduce network traffic by cacheing. Skilled work – misconfigured cacheing is hard to debug too. Though hard to find, very often these problems are easy to fix once the actual cause is identified.
The ME Forum isn’t massive by web standards, but I think it’s big enough to require system tuning. If I’m right, then it’s a developer nightmare! Application programmers are trained not to worry about efficiency because application code is rarely performance critical. If an application doesn’t perform, much more likely the system needs tuning than the application. However, WordPress straddles application and system considerations, and its probably running on a hosting service that can only be tuned by someone else. Painful!
The database is a plugin, allowing the developer to use anything between slow and simple up to super-fast and complicated. This is good because it allows small sites to be hosted cheap without fuss, but monster sites can be accommodated with a high-end database and server-farm if needed. Low-end databases are easy provided they do the job, high-end are £hard.
WordPress by default doesn’t cache; instead the developer has to choose between many plugins, and some of the options may be mutually exclusive. Again Low-end sites are easy, high-end are tricky and expensive.
Naturally users are annoyed by visible bugs, but these I think are all minor compared with what’s going on backstage. Everything looks good on Friday night, she breaks over the weekend so Monday starts with a crisis, and the next phase of fixes is delayed again.
If system tuning is the problem I have considerable sympathy with the developer.
Dave