Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt November 11, 2024
Mark Posted June 9, 2014 Posted June 9, 2014 Sorry but not fully true Brandon :smile: And i fully support all the other big board owners that wanted to state this absolute truth to you. There are fundemental errors that causes the issues. Biggest issue for me is the requirement for high MySQL wait time. Your support engineers constantly suggest default value which is 28800 . It is an unacceptable level of setting for any big board. This is something hopefully will be nailed with IPB 4. Could you elaborate on what the issue you're experiencing is and how you think we could improve? I can't think of any particular reason why IP.Board would require any particular wait_timeout. Naturally, our support agents will recommend the default values, but yes, you're absolutely right that, if you know what you're doing, reducing that shouldn't be an issue.
StealthBravo Posted June 9, 2014 Posted June 9, 2014 http://minecraftforum.net is migrating from IPB to Cobalt (custom in-house software solution made by the company that runs the site), I think that should be a big statement that IPB is sub-par when it comes to handling humongous communities. With 2.6 million members and 25 million posts, the members list, the moderating team, the WYSIWYG editor, and lots of stuff in the background are/is completely broken for no apparent reason. The site has a great loading speed, but there have been so many issues with it that it's just gotten out of control. Hopefully larger communities will be supported with 4.0.
GreenLinks Posted June 9, 2014 Posted June 9, 2014 Could you elaborate on what the issue you're experiencing is and how you think we could improve? I can't think of any particular reason why IP.Board would require any particular wait_timeout. Naturally, our support agents will recommend the default values, but yes, you're absolutely right that, if you know what you're doing, reducing that shouldn't be an issue. Mark , i have daily around 10+ MB connection timeout queries logged in SQL error logs. We learn to live with this , if we reduce values to acceptable levels where we run vBulletin without any issue, the connection timeout errors are reaching to 100MB+ logs and basically IPB becomes unresponsive for a time. The main reason is the number of queries every page requires by IPB. Again hopefully all these issues will be resolved with IPB 4. However as of now , IPB has issues when you average 10+ k online users. We hope the suggestion of moving active / inactive users to separate tables and major improvements to topic archiving system. Current format is not usable for us. P.S : I never understand users whom constantly suggest pruning users. A system like IPB should run without the need of pruning any users.
kihon Posted June 9, 2014 Posted June 9, 2014 http://minecraftforum.net is migrating from IPB to Cobalt (custom in-house software solution made by the company that runs the site), I think that should be a big statement that IPB is sub-par when it comes to handling humongous communities. With 2.6 million members and 25 million posts, the members list, the moderating team, the WYSIWYG editor, and lots of stuff in the background are/is completely broken for no apparent reason. The site has a great loading speed, but there have been so many issues with it that it's just gotten out of control. Hopefully larger communities will be supported with 4.0. Is this the main reason why, on Mincraftforum.net, that members cannot be clicked on?
bfarber Posted June 9, 2014 Posted June 9, 2014 I'll overlook the fact that you quoted a post I made 2.5 years ago lol - things do change as time goes on and software progresses and technology changes and so on. As Mark mentioned, a wait_timeout value of 28800 should not be necessary. A query in our software (or any really) should not take 28800 seconds to execute and return. I would generally aim for 60 seconds and don't typically see any issues with that, but YMMV. Anyways, you are seeing connection timeouts in your logs you say? What is the general symptom that you are seeing? Queries that are sent to the server, but the connection is closed before the response is received back by the software?
StealthBravo Posted June 9, 2014 Posted June 9, 2014 Is this the main reason why, on Mincraftforum.net, that members cannot be clicked on? Huh? Member profiles can be viewed and clicked on, it's just that the members table is so massive that the system literally cannot process the request, and you'll just time out or get a 404 error. We're also unable to utilize the Who's Online list, which is minor but still noticeable and nice to have.
Hitori Bocchi Posted June 9, 2014 Posted June 9, 2014 Huh? Member profiles can be viewed and clicked on, it's just that the members table is so massive that the system literally cannot process the request, and you'll just time out or get a 404 error.I think he is referring to the index page.We're also unable to utilize the Who's Online list, which is minor but still noticeable and nice to have.At some point is gets a visual nuisance. 200-300 users the most, but if you have thousands of user online, from a user perspective, you'll need to ctrl + f in order to find someone in there anyway.
GreenLinks Posted June 9, 2014 Posted June 9, 2014 I'll overlook the fact that you quoted a post I made 2.5 years ago lol - things do change as time goes on and software progresses and technology changes and so on. As Mark mentioned, a wait_timeout value of 28800 should not be necessary. A query in our software (or any really) should not take 28800 seconds to execute and return. I would generally aim for 60 seconds and don't typically see any issues with that, but YMMV. Anyways, you are seeing connection timeouts in your logs you say? What is the general symptom that you are seeing? Queries that are sent to the server, but the connection is closed before the response is received back by the software? The topic was bumped before me Brandon. I read it and responded , we went over the issue on an old support ticket. The connection between DB , Web server is extremely fast. They are connected through a direct 10GB line and the connection is through MySQL socket for performance improvements. However if you prefer , i can request our Sysadmin to supply detailed information via a support ticket so we can both study the possible causes.
kihon Posted June 10, 2014 Posted June 10, 2014 Huh? Member profiles can be viewed and clicked on, it's just that the members table is so massive that the system literally cannot process the request, and you'll just time out or get a 404 error. We're also unable to utilize the Who's Online list, which is minor but still noticeable and nice to have. Oh it may have been that I wasn't logged in.
kihon Posted June 10, 2014 Posted June 10, 2014 The topic was bumped before me Brandon. I read it and responded , we went over the issue on an old support ticket. The connection between DB , Web server is extremely fast. They are connected through a direct 10GB line and the connection is through MySQL socket for performance improvements. However if you prefer , i can request our Sysadmin to supply detailed information via a support ticket so we can both study the possible causes. yeah, I necro-bumped it because I read through this topic and really didn't find a definitive answer as to the number of members in the table that would cause an issue. We're at 100k, on a dedicated server running MySQL on SSDs and I was just hoping we wouldn't see the issue, that's all. :)
Crothers Posted June 10, 2014 Posted June 10, 2014 As to the members table, is this still a problem? Has anyone experimented with partitioning across the 37 main partition points on the user table? Users a-z 0-9 and all others. 37 tables. Could help.
StealthBravo Posted June 10, 2014 Posted June 10, 2014 I think he is referring to the index page. At some point is gets a visual nuisance. 200-300 users the most, but if you have thousands of user online, from a user perspective, you'll need to ctrl + f in order to find someone in there anyway. Yeah, I would still love to see the who's online list from when we had 110,000+ users online at once :P Oh it may have been that I wasn't logged in. Yeah, guests can't view member profiles.
bfarber Posted June 10, 2014 Posted June 10, 2014 The topic was bumped before me Brandon. I read it and responded , we went over the issue on an old support ticket. The connection between DB , Web server is extremely fast. They are connected through a direct 10GB line and the connection is through MySQL socket for performance improvements. However if you prefer , i can request our Sysadmin to supply detailed information via a support ticket so we can both study the possible causes. What is the existing ticket ID? I assume there might be some information in it to help me understand better.
Rheddy Posted June 10, 2014 Posted June 10, 2014 I thought someone created a hook that allowed you to enable guests to view user profiles? Personally, I keep a lot of features disabled for guests because that just gives potential spammers and forum trolls the ability to cause harm to your community. I've never liked the ability to allow guests to search the forums or to view the user profiles, which is why I keep those features disabled for those who aren't registered members.
Makoto Posted June 10, 2014 Posted June 10, 2014 I thought someone created a hook that allowed you to enable guests to view user profiles? It's a member group setting, you don't need a hook for it.
Rheddy Posted June 10, 2014 Posted June 10, 2014 People still develop hooks for them. I see this all the time in the marketplace, which boggles my mind as to why to create a hook when the feature is already built into IPSCS.
Draffi Posted June 11, 2014 Posted June 11, 2014 IPB has a lot of settings, maybe this is the reason that people create hooks for things what is not necessary... This causes in a missing (wiki-style) manual... For example, SMF has a wonderfull manual: http://wiki.simplemachines.org/smf/Main_Page
Recommended Posts
Archived
This topic is now archived and is closed to further replies.