Disabling hooks creates high server loard ?

[SecondSight]

Hello ! :)

I've decided to disable some hooks* to see if things are doing better. It looks like it created a very high server load... I had many members online (about 1100) perhaps is this the reason ? At the beginning, the load was about 15 and it rose up to 120.

When this happened I was watching the sql process list :

And a top :


and I had many errors like this one :

Fatal error: Call to a member function hookUserDropDownLink() on a non-object in /home/forumse/public_html/admin/applications_addon/other/subscriptions/sources/classes/hooks/gateway.php on line 77

What do you think of this ? Is it normal ?

Thank you ! :)

* I disabled these hooks :
Unread Notifications
Shows unread notifications on the board index
Ad Code Sidebar
Displays ad code on the board index sidebar
Who's Chatting
Shows who is in chat if installed and enabled

[mat206]

Hello ! :)

I've decided to disable some hooks* to see if things are doing better. It looks like it created a very high server load... I had many members online (about 1100) perhaps is this the reason ? At the beginning, the load was about 15 and it rose up to 120.

When this happened I was watching the sql process list :

And a top :

and I had many errors like this one :

What do you think of this ? Is it normal ?

Thank you ! :)

* I disabled these hooks :

Unread Notifications

Shows unread notifications on the board index

Ad Code Sidebar

Displays ad code on the board index sidebar

Who's Chatting

Shows who is in chat if installed and enabled

We have similar traffic levels and if we even try doing ANYTHING with the hooks (even moving them around) the whole site implodes and we get a database driver error. It apparently has something to do with the way skins are recached. I hope they fix this in 3.2

- Michael

[SecondSight]

I've always thought that there was a cache problem too, but I can't demonstrate this. For me, disabling all hooks and rebuilding cache made things working better. :)

[teraßyte]

Disabling an hook flags all the skin for a recache to remove/add the hook points of the hook you disabled/enabled.

But I noticed too myself a while ago that there seems to be something wrong with the process and we have an open bug report about it so that we can investigate.

[mat206]

Then it seems that with high traffic sites we are getting multiple users triggering that process, thus killing the server ? Shouldn't it be possible to have the code that recaches the skin to work only on the hooks management ACP page rather than generically through the site?

The other thing that might be easy to implement is to create a lock file somewhere on disk that when present, does not allow a user to recache. After the recache is complete the lock file is deleted. Then you at least can keep the recaching process down to one user only.

[teraßyte]

No the recache is done only once regardless and more members won't trigger more recache processes, the issue is that it recaches all skins in 1 cycle instead of doing 1 skin each cycle.


Still keep in mind that this is what I *think* it's happening, we haven't investigated the issue yet so I can't say anything for sure right now.

[mat206]

[quote name='tera

[teraßyte]

Even if temporary, recaching the skins requires a great amount of resources so having a lot of users online instead of only 1 can change a lot the situation.

[SecondSight]

In this case, it seems according to what you say, that the problem comes from recaching the skins. As for me, I only have three skins : the default IPB skin, which is used by nearly all members, the mobile skin, and a test skin which isn't used by members.

How can I know if the problem doesn't come from the whole cache system or a part of it ?
In my mysql-slow.log, I often have queries like this one (I also have queries about sessions and core_item_marker_storage) :

INSERT INTO ibf_content_cache_posts (`cache_content_id`,`cache_content`,`cache_updated`) VALUES(5204578,'<span style=