RM 1.1 Delay when Adding New Resource

[Tiki Tiki]

Is it normal to encounter a fairly long delay when adding a new resource?

I'm getting 5- to 7-second long pauses when adding a new resource (Little Engine: "I think I can, I think I can, I think I can!" )... but I can edit existing resources without any noticeable delays.

These resources do not include any files, by the way, they're strictly articles. They do have a lot of BB codes for styling, links, etc. No idea whether any of that makes a difference.

 

[Mike]

Are you using an external mail server? I would guess that it's related to emails being sent (to people that are watching the category). There can be a delay with the default PHP mail system, but if you're using an external SMTP server, there may be more significant delays.

 

[Tiki Tiki]

No external mail server, just the default PHP mail.

Hmmm. It's only been a couple of weeks since switching from IPB, so I don't know how many people could already be watching what is essentially a brand new resource category. I do, though, have the Resource Manager set to create new forum threads. I know a lot of people were already watching the forum category under IPB, but is that something that would have carried over with the import?

I may have underestimated the delay when submitting a new resource, by the way. I had a couple last night that seemed to take closer to ten seconds. Again, no delays with anything else, just when submitting a new resource.

 

[Mike]

I know a lot of people were already watching the forum category under IPB, but is that something that would have carried over with the import?

I don't have the code in front of me this moment so I'm not sure. It would be relevant though as that could be the cause. An easy test would be to temporarily disable creating a thread when submitting a resource and create a new one to see if the delay is any different. There isn't really much "unique" about the resource creation process when compared with creating a thread directly. They do similar things and I assume the thread creation process is reasonably fast. (Though I should note that when content is created, there can be a lot of work done, so it's certainly expected for "writes" to be slower than "reads".)

 

[Tiki Tiki]

An easy test would be to temporarily disable creating a thread when submitting a resource and create a new one to see if the delay is any different.

Good idea. I'll have to try that when I'm back home later on tonight. I suppose I also need to compare regular thread creation in a popular category vs an unpopular one. And/or, more to the point as far as the Resource Manager is concerned, perhaps I should change the automatic thread creation to an unpopular forum category.

Question: If I don't create a resource thread at the get go, can I add one later on? Via SQL (SET discussion_thread_id = 'XXXX'), or is there something more convenient?

 

[Tiki Tiki]

Hmmm, well, changing the automatic resource thread to an unpopular (hidden even) forum category resulted in about a 10 second delay when submitting a new article/resource... and turning thread creation off altogether resulted in close to 15 seconds when submitting another new article/resource after that.

@Mike, any other ideas as to what might be happening here?

 

[Mike]

Unfortunately, I'm not really sure. Are people watching the category?

There isn't actually that much going on, so I'm not sure what really differs between submitting a resource and a thread. (I assume the latter is fast.) It does seem like there's a significant variation in times though. Any idea if there are load/contention issues?

 

[Tiki Tiki]

Any idea if there are load/contention issues?

Can you expand on this? I'm not sure what it means.

It's just weird that submitting an edit to an existing resource article takes half a second, no noticeable lag at all, but submitting a new resource article routinely takes 10 seconds.

 

[Mike]

I meant is the server load high or are there limited resources (such as disk I/O) that are overloaded? These will normally manifest itself on multiple pages, but inserting content (a thread or a resource) are generally going to be more intensive than just browsing.

I would recommend disabling all other add-ons in the ACP if you haven't tried that already. It's important to try to isolate the code for testing as much as possible.