That's not a fix, that's a hack!!!!
Either the database server is not tuned (quite likely as no one seems to bother with tuning these days), or it simply doesn't have enough resources.
My money is on a lack of resources, either the server has been down-graded, or it is being shared by more sites, or by other sites that have greatly increased in load. What ever the cause, disabling functionality is not the solution, it might buy a few more weeks of OK performance, but what's needed is an actual fix. Be that tuning, or more resources. I doubt this site has grown in size or use dramatically enough to cause this, so something has changed, and needs to be un-changed!
B.
Totally agree with you GB on this one, first the hack will work for a while and will keep on caching and bring back the same issue if not more issues. I do not come as often anymore to notice how often the server busy is coming, but rich of previous experiences in running forum, the issues is for the most a lack of resources and YES database tuning is an important step. Running a website that runs on database such as VBulletin or the very most private MS Office SharePoint, many things needs to be taken in consideration and the very first one is the
Database tuning; scripts and sites like VBulletin doesn't just
store information in database they use the transactional functions of it, which means the back-end functions of VBulletin is powered by the database. Thus, frequent maintenance should be done and I don't know if I'm wrong but I don't see too often the site
being taken down for maintenance. One shouldn't attempt to optimize a database when 50 thousand users are looking at their mails
, furthermore some automated cache management, frequent tables rebuilt in short a bi-weekly server optimization is strongly suggested.
Since I don't have much information on the back-end or equipments used for the hosting of GH; the only things I can provide is plausible causes of this server busy message. (Take them in consideration or not, that's the last of my worries but let's say it... been running server for more than a decade).
- VBulletin itself as a script is not very heavy, the web server should be able to take the load, and if the database is not in cause, therefore the web server is seriously overloaded and this beautiful message from VBulletin is activated by a script petitioning Apache/IIS and other web servers.
- If GH is on a cloud hosting, using virtual technology, as good as virtualization is; I really don't recommend it to run a board with more than 50k users, admin are just asking for problems. Of course this also bring me to think about the virtualization infrastructure being used if any, which I won't go there it's way too complicated. I have met some IT technicians who were running their databases on a virtual server... yes it it possible but oh my god... you better have a very good backup strategy and give a lot of resources to the databases because if there's one unpredictable server in a server farm, it will sure be the database one; MySQL, Oracle, MSSQL, IBM DB2 doesn't matter which ones.
- Databases lack of optimization and/or tuning... if MySQL is used (now any form of MySQL); frequent tables optimization should be done, in fact a very popular website should have a downtime of about two hours every two days for maintenance; rebuilt tables, empty cache, rebuilt all those VBulletin instances (i know there's at least 15 of them). Those can be set as task from VBulletin admin panel and also from Windows or Linux; every good system admin knows how to set automated tasks. And tasks can also be planned from MySQL itself.
- As the site become huge how about an additional load balancing server (and I don't mean virtual load balancing) frankly as much as I know that virtualization is a money saver I hate that crap like my aunt Gertrude (Gertrude is an ugly name :rofl. Is GH under a cluster farm? Doesn't have to be huge, cluster of two or three is quite enough.
- Last possibility is DOS attack, but now I'd say that if GH is hosted that should certainly be looked after within a shared environment. I had the pleasure of fighting a DOS attack from China, Czech and Russia last year and that wasn't funny... God thank you for Cisco Systems
Just like GB said it so well, stop looking into the script for a fix,
fix the resources... I am so certain that the issue doesn't lie on script or people's Internet connections that I'd throw Blondy Locks in the fire
Okay enough techie crap enjoy your slow day hahahaha! :cheers: