1
lolpant
Re: XOOPS 2.5.x / Multisite 1.40
  • 2011/11/29 10:58

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


Hi wishcraft,

thanks for coming back to me on this one.

Thanks for the update, what I did eventually was run the site on XOOPS 2.4.4 and applied a minor hack:

In modules/multisite/preloads/core.php I changed the block selection code on line 103 from:

$args[2] = array_merge($args[2], $xoopsblock->getAllByGroupModule($groups$mid$isStartXOOPS_BLOCK_VISIBLE));


to

$args[2] = $xoopsblock->getAllByGroupModule($groups$mid$isStartXOOPS_BLOCK_VISIBLE);


This seems to be working for now, as far as the blocks configuration is concerned.

Will post any side effects if I find any.



2
lolpant
Re: XOOPS 2.5.x / Multisite 1.40
  • 2011/11/28 8:16

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


Just keeping this topic alive; still struggling with this one.



3
lolpant
XOOPS 2.5.x / Multisite 1.40
  • 2011/11/23 7:54

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


Hi all,

I have managed to install multisite and have made the changes to all the required PHP files (URLs working correctly etc.).

I have also managed to change the site name and theme based on the provided subdomain.

My domain setup is as follows:

mainsite.domain.com
subsite.domain.com

However, I am struggling to get the blocks administration right on my subdomains.
Basically I would like a particular block to be enabled only on mainsite.domain.com and not subsite.domain.com.

I have made sure that only mainsite.domain.com is selected in the multisite block admin area (instead of 'All Domains'), but the block continues to show on both subdomains.

It seems I can only enable it for all domains or only disable for all domains.

Thanks in advance.



4
lolpant
Comment Notifications
  • 2010/3/12 8:34

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


Hi guys,

I am having an issue with a module's comment notification. Basically all seems well, most of the fields in comment_notify.tpl are being filled (uname, url etc.), except for {X_ITEM_NAME}, which is resulting in "Item Name Not Available" printing instead of the article title.

Just wanted to know where the call to comment_notify.tpl is typically fired from, so that I can validate the field for the item name.

Module SmartSection2.14


Thanks.



5
lolpant
Re: Performance SmartSection 2.14
  • 2010/2/8 14:52

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


I have removed all calls to getObjects and toArray because yes, these would be expensive methods to execute.

What worries me is the time taken to execute $obj->get() increases as the number of rows in the database increases. In addition, the amount of memory required by PHP to execute the page also grows.

The code I have shown above is all that I am executing and the Total time required by XOOPS to load the page is 6 seconds (on average), whereas a fresh install of the module with very few rows ( < 100) probably takes 1seconds to render.





6
lolpant
Re: Performance SmartSection 2.14
  • 2010/2/8 13:34

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


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:

include ('header.php');
include_once(
XOOPS_ROOT_PATH "/header.php");   
$article_item_handler =& xoops_getModuleHandler('item');
$itemObj $article_item_handler->get(500);
echo 
$itemObj->getVar('title'); echo "nDone";
include_once 
XOOPS_ROOT_PATH '/footer.php';


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

function &get($id null$fields null)     
{   
$GLOBALS['xoopsLogger']->startTime('Code to test');         
$object null;         
if (empty(
$id)) {             
$object $this->create();             
return 
$object;         
}                  
if (
is_array($fields) && count($fields) > 0
{            
$select implode(","$fields);             
if (!
in_array($this->keyName$fields))
{                 
$select .= ", " $this->keyName;            
 }         
} else 
{             
$select "*";         
}         
$sql "SELECT {$select} FROM {$this->table} WHERE {$this->keyName} = " $this->db->quote($id);
if (!
$result $this->db->query($sql)) 
{             return 
$object;         }                  

if (!
$this->db->getRowsNum($result)) {            
 return 
$object;         
}                  


$object =& $this->create(false); 
        
$object->assignVars($this->db->fetchArray($result));
         
$GLOBALS['xoopsLogger']->stopTime('Code to test');         

return 
$object;     
}


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

But when I place the timer at:
$GLOBALS['xoopsLogger']->startTime('Code to test'); 

$itemObj $article_item_handler->get(500); 

$GLOBALS['xoopsLogger']->stopTime('Code to test');


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?




7
lolpant
Re: Performance SmartSection 2.14
  • 2010/1/22 9:17

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


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:

[21-Jan-2010 16:24:28PHP Fatal error:  Allowed memory size of 104857600 bytes exhausted (tried to allocate 140 bytesin /Applications/MAMP/htdocs/site/kernel/object.php on line 186


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:

/**      * assign values to multiple variables in a batch      *       * @access private      
* @param array $var_array associative array of values to assign      */     
function assignVars($var_arr)     {         
      foreach (
$var_arr as $key => $value) {                
          
$this->assignVar($key$value);         
      }     
}



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

Select from smartobject_items where itemid 1


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

$itemObj $smartsection_item_handler->get($itemid);


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.



8
lolpant
Re: Performance SmartSection 2.14
  • 2010/1/14 15:00

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


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:

$itemObj $smartsection_item_handler->get($itemid);


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








9
lolpant
Re: Performance SmartSection 2.14
  • 2010/1/13 11:40

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


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.




10
lolpant
Re: Performance SmartSection 2.14
  • 2010/1/13 9:16

  • lolpant

  • Just popping in

  • Posts: 41

  • Since: 2007/3/19


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!




TopTop
(1) 2 3 4 »



Login

Who's Online

119 user(s) are online (98 user(s) are browsing Support Forums)


Members: 0


Guests: 119


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits