Lag opening our forums

[Makoto]

Well, that's fine. I'm just saying, don't expect to get instant page load times when you're hosting your website on another continent :tongue:

It shouldn't be 5 seconds worth, but some latency will be unavoidable.

[Grumpy]

don't expect to get instant page load times when you're hosting your website on another continent :tongue:

Most SA optimized sellers in florida will only make a difference of 30~100ping. And besides... OP's using cloudflare now.

[Gabriel Torres]

Hi,

I'd like to add that our main website, http://www.clubedohardware.com.br (hosted on another dedicated server, but in the same datacenter/network), opens almost instantly to me. Only with our forums (http://forum.clubedohardware.com.br) that we are seeing this lag. Not only me, our users are also complaining. So, the problem is definitely with our forums (if it were a continental latency, we would see the same lag issue with both websites, which is not happening). Also, our old vBulletin is installed on the same server as our forums, and we see no lag opening it. So, I will have to dig deeper on this and keep you guys posted on what I find out. It may have something to do with specific hooks/code we added.

Gabriel.

[Gabriel Torres]

I made a major discovery. The forums are slow and this 5-second lag only appears to administrators and moderators. If we are not logged in or we are using a regular member account, we don't see this lag. This explains why you guys are able to open and navigate so fast on our forums.

Therefore, it is time to narrow this down to some function that is enabled only for the staff, such as warning notifications.

[Aussie Cable]

Have you changed your sessions table to MEMORY?

I dont think that it would help, because as you say, it only happens to admins/mods however, it is worth a try.

[Gabriel Torres]

Changed back to MyISAM. Performance is the same (lag + slowness for admins/mods). If it had something regarding sessions, it would be slow for regular users as well IMHO.

At this moment, I am looking for a way to disable the admin/mod warning notifications at the top of the page to see if that is the culprit.

[Aussie Cable]

Yeah, like I mentioned, I did not think it would make any difference. I do recommend switching sessions back to MEMORY however.

Do you have any logging addons/apps specifically for admins/mods?

EDIT: I cant see that the notifications would cause such an issue, you may need to submit a support ticket.

[Gabriel Torres]

Ticket opened. Let's wait and see...

[Makoto]

Browsing as an administrator or moderator has always been slower for me as well. I noticed this a while back.

I almost posted about it before, to see if any optimizations could be made to mitigate the performance penalty, but it's usually only a ~300ms delay at most for me, not 5 seconds.

I'm guessing it may have something to do with additional queries checking for unapproved posts or things of the sort. Maybe bad performance with some large JOIN queries that may be specific to staff members. However, the reported page execution time is no different as an administrator compared to a regular member. Which makes it a little interesting.

I thought maybe it was just DOM related somehow, but it's always the request that seems slower, not DOM, even if the reported page execution time is no different.

Headers are compressed on my server with SPDY, so even if staff did have bloated cookie data for whatever reason (which I don't think they do), the difference should be completely negligible. That was my second guess, though.

It's also completely possible that a third party hook or application is to blame. I have a number of those on my forum. I've been meaning to investigate SQL query performance on my production board, but I've been too busy to get around to it.

[Grumpy]

If it's serious amount of lag we're talking about, try taking a look at your slow queries log.

[Gabriel Torres]

Hi guys.

I could track this down to this application we installed:

'?do=embed' frameborder='0' data-embedContent>>

More specifically, two hooks that show at the top of the page duplicate registration attempts (and which are enabled only for admins and moderators) were the culprit. Disabling them solved the issue:

Duplicates Fraud Access Alert v3.0.4

Duplicates Fraud Registration Alert v3.0.4

Now the forums are as fast as possible to all users.

Thanks a lot, the tips you guys gave (such as moving to nginx) helped anyway.

[Makoto]

I had a feeling it might be related to that app. Thanks for posting confirmation.

By the way, I would strongly recommend you clear out your machine list with that app every now and then. I clear mine out whenever I reach around 50,000-75,000 machines maximum.

[stoo2000]

Hi guys.

I could track this down to this application we installed:

'?do=embed' frameborder='0' data-embedContent>>

More specifically, two hooks that show at the top of the page duplicate registration attempts (and which are enabled only for admins and moderators) were the culprit. Disabling them solved the issue:

Duplicates Fraud Access Alert v3.0.4

Duplicates Fraud Registration Alert v3.0.4

Now the forums are as fast as possible to all users.

Thanks a lot, the tips you guys gave (such as moving to nginx) helped anyway.

It may be worth making a suggestion to the developer to update those hooks to use a cache, so that it isn't calculating on every page load.

[Makoto]

Adding an index to the access_attempts row can help with performance here.

CREATE INDEX access_attempts ON members (access_attempts) USING BTREE;

No index (Duplicates Fraud Access Alert)

MariaDB [forum]> select * from members where access_attempts<>0;
Empty set (0.09 sec)

Indexed (Duplicates Fraud Access Alert)

MariaDB [forum]> select * from members where access_attempts<>0;
Empty set (0.00 sec)

Not much you can do with registration_attempts, since it's TEXT. If you could use a IS NOT NULL query instead of <>"", it would probably be a bit better performance wise, but that doesn't work and still isn't entirely optimal.

Still, adding an index to the access_attempts row should let you keep the first hook enabled without much performance penalty.

(Also, this seems to clearly show the page execution time is not entirely accurate? It doesn't include the time it takes to execute queries by this hook at all in its statistics.)

[Gabriel Torres]

Hi Kirito, I guess you should post this on the official thread for this application: http://community.invisionpower.com/topic/373614-download-duplicate-members-logger/