Hi guys,

I have been using SmartSection 2.14 for article management for a while now, but in the past few months I have noticed a gradual slow down in performance when accessing each of the articles or when listing them in the administration menu.

To begin with the module performed well, however as I started going over 1 000 rows in the database, I noticed a slow down when performing searches on the site or accessing the articles, some of the wait times according to the XOOPS timers were around 5 seconds. I am now approaching 10 000 rows so the slow down is now becoming significant, near 10 seconds on loading an article.

I have attempted to optimize some of the code in item.php as an example by reducing the number of category and item objects being created, and trying to only create an object for the item currently being viewed. This had worked very well at around 6 000 rows and for a time this had brought the load time down from 10 seconds to around 4 seconds.

However as the number of rows has approached 10 000, the slow down has begun growing again, albeit at a slower rate.

My question really is, what happens in the Module Init phase when a page loads in XOOPS? This is the phase that consumes the most time when loading an article. If there is a procedure in the code that is causing the long load times, I need to find it soon and make the necessary changes. I have made some of my own pages selecting the items from the database, and these are nowhere near as slow as /modules/smartsection/item.php and /modules/smartsection/admin/index.php

Much appreciated.

Try to clear caches and optimize database.

What search module are you using? Default is slow, I think. :)

I have disabled caches and I don't think it is really a database issue as I do far more complex requests (than "select item") on the same table in a shorter amount of time.

As for Search, I am using the default...any other suggestions?

The problem persists!

If you put debug on, you can see which queries are made for each page request and there is timing as well. This may indicate some areas to work on.

You can try MySearch https://xoops.org/modules/repository/singlefile.php?cid=58&lid=1815

I appreciate the replies guys, thanks.

I have been running debug and added a timer onto each of the queries, and I am not seeing anything out of the ordinary, which again tells me the issue is not DB / query related but possibly another procedure that is possibly just building unnecessary objects and consuming memory.

Still trying to track down all the processes that are happening during the Module Init phase.

Thanks, I'll give My Search a bash and see if it speeds up any of the site load times.

1 - My search is not faster then core search, depending on the settings it can be slower.
2 - Look at query times on smartsection, there is a create/drop temp table that can be time consuming.
3 - Smartsection often uses $object->toArray() just for getting the title of the article. This will make XOOPS render fields like content/summary that will not be displayed at all, the larger the articles the worst it gets.
4 - Place counters in your code so you can get executions time:

Thanks trabis, the code timer helped me isolate the problem. Sadly the problem is in the get method for retrieving the item object, at the top of item.php:



I have not found any way of dramatically improving the speed of this query though, I will keep experimenting.

Hi guys,

I am still trying to isolate why this particular get method requires so many resources to run.

Overtime, as the number of rows in the table has increased, I have had to increase the amount of memory for PHP to run the page. Of course, if PHP runs out of memory before executing the script, it will produce a blank white page.

For ages I thought it was an Apache / PHP config issue, but I noticed as the number of rows increased, so did the amount of memory required to return a single row.

I can understand how if you are selecting all rows for example, and then returning XoopsObjects for each of the rows, it would become a problem as the size of the table increases. However, as far as I understand it, the get method only returns a single row and then constructs a XoopsObject for that particular row, so the number of rows in the table should not have such a significant impact on the memory required to build a single XoopsObject.

This is the error produced by PHP in the PHP Log:



So the page fails to load even though I have allocated PHP 100MB of memory to execute scripts. I have now allocated 500MB but of course this is only a temporary fix to the problem. As you can see I am running the MAMP stack on my Apple. However, experience the same issues on my Linux deployment as well.

The code breaks in object.php at this point:




Of course I could just do a straight select and return an array:



which only needs 0.001 seconds to execute instead of 5 seconds when executing:



However, this would become messy over time and does not conform to XOOPS programming standards.

So, any suggestions on how I could optimize the get method so that the amount of memory required to perform the operation does not need to increase according to the number of rows in the table, for selecting on 1 row from the table.


Much appreciated.

I created a test page to load a single article object to try and find out where the performance issues were being introduced.

On average a page takes approximately 6 seconds to load with 10 000 rows in the articles table.

Here is my page code:



I now placed a timer inside kernel/object.php:



The result for "Code to test" was 0.001 seconds, which is fine.

But when I place the timer at:


The result for Code to Test was now close up on the total time taken for the page to load (5 / 6 seconds).

So what could be the bottleneck? Is PHP taking that long to resolve which get method to use?

Thoughts?