No need to be rude
Summercat said:I just wait until late in the day. Then it goes away.
kuronekotenshi said:Summercat said:I just wait until late in the day. Then it goes away.
That all depends on where you are.Â Â By 5 am in the morning easter time it started to clear up decently but the main page STILL took ages to load.Â Â My page didn't take long, and I could get ot my messages quickly, but on the front page it was sluggish as can be. :
I kept mentally giving you guys two months to fix things. You know, as a benefit of a doubt sort of thing.uncia2000 said:Does need to be fixed and will be fixed.
A half-decent response time is one of the fundamental requirements for FA.
nrr said:I kept mentally giving you guys two months to fix things. You know, as a benefit of a doubt sort of thing.
... but that always kind of falls short and leaves me disappointed and frustrated. I would kind of like to see FA suck less, but there isn't a really apparent desire to fix anything. I've seen nothing but side-stepping since December. What gives?
nrr said:Bearing a CS degree or not, the programmers need to understand that FA's codebase needs a lot of TLC and refactoring done in order to become at least the slightest bit sane, and unless your programmers know how to shift between design paradigms in various, potentially unrelated chunks of code (while also documenting what is going on -- use Subversion and something like RT or Bugzilla!), how is FA's technical operation going to become even marginally better?
Also, you need to start looking at people who've done supercomputing work with regard to Web applications and file/database servers. If FA does end up growing any more, having only one machine running things won't suffice, and you'll have to start branching out. If I didn't think it'd look tacky to have this whole paragraph italicized, I'd do it. I absolutely cannot emphasize this point enough.
That said, a lot of the slowdowns on FA are not really a result of the codebase itself (though, I guess it could be said that it's an indirect result...); rather, they're a characteristic in increasing load on MySQL and Apache/PHP both. Both pieces of software are heavily CPU-bound, and MySQL adds in the complexity of actually being I/O-bound, with most of its operations thrashing the CPU being related to fetching things from and storing things to disk, so there's competition going on as to who gets more attention on the CPU, and the kernel's scheduler is doing the best job it possibly can. This can be alleviated temporarily by shoving MySQL off to another machine and focusing on good ways to increase I/O throughput for data being fetched from the database.
Ask your programmers how to implement this too BTW.
It's what happens everywhere with larger Java Web applications, and it's what happened with LiveJournal as they started growing too large.furryskibum said:Sounds like a practical path to a solution, though!