Topic: Performance issues

Hi,

When printing some reports or even when you access some page that taking a lot of time to retrieve the data from database we see the progress image gone and new yellow image with exclamation mark begin show, this due to the large data that i have, what is the correct solution, to make this not happens ?

Regards

Re: Performance issues

Make sure you have removed redundant indexes and have some needed indexes in place. Also, some reports are cycled through in php on a per sql query basis instead of being acquired in a single sql query possibly as atomic requests use less memory.

Which reports slow you down? Has your MySQL been "tuned and defragmented" ?

Re: Performance issues

Many thanks apmuthu all is good now smile
may i ask how i can register my name as frontaccounting developer contributor

4 (edited by xodaix 08/14/2016 10:18:00 pm)

Re: Performance issues

between the issue that i was have is that the print sales invoice report is not open because of the huge number of invoices that we have, we change the from invoice and to invoice parameter to be filtered like list search.

5 (edited by apmuthu 08/15/2016 05:55:23 pm)

Re: Performance issues

It is imperative for the stock_id field to be indexed in the debtor_trans_details table for all FA databases used with the equivalent of:

ALTER TABLE `0_debtor_trans_details` ADD INDEX `stock_trans` (`stock_id`);

The function get_customer_trans_details() in the file sales/icludes/db/cust_trans_details_db.inc is used in reporting/rep107.php (and in 110, 113 reports as well) to acquire the transaction list filtered as appropriate. The non filtered SQL in it is:

SELECT trans.*,
       trans.unit_price + trans.unit_tax AS FullUnitPrice,
       trans.description AS StockDescription,
       stock.units,
       stock.mb_flag
FROM 0_debtor_trans_details trans
        INNER JOIN 0_stock_master stock USING (stock_id)
ORDER BY id;

As the stock_master.stock_id and debtor_trans_details.id fields are primary keys, they stand already indexed. Hence the foreign key debtor_trans_details.stock_id is the one that is left to be indexed as it is the INNER JOIN field.

The said function can be modified to be:

function get_customer_trans_details($debtor_trans_type, $debtor_trans_no)
{
    if (!is_array($debtor_trans_no))
        $debtor_trans_no = array( 0=>$debtor_trans_no );
    $sql = "SELECT trans.*,
        trans.unit_price + trans.unit_tax AS FullUnitPrice,
        trans.description As StockDescription,
        stock.units, stock.mb_flag
        FROM ".TB_PREF."debtor_trans_details trans
             INNER JOIN ".TB_PREF."stock_master stock USING (stock_id)
         WHERE (";

    $tr=array();
    foreach ($debtor_trans_no as $trans_no)
        $tr[] = 'debtor_trans_no='.db_escape($trans_no);
    $sql .= implode(' OR ', $tr);

    $sql.=    ") AND debtor_trans_type=".db_escape($debtor_trans_type)."
        ORDER BY id";
    return db_query($sql, "The debtor transaction detail could not be queried");
}

@joe: want to include it in the core? Committed in my FAMods.

I can confirm that even after this, when a range of invoices is attempted to be printed, the webserver hangs. Single invoice printing works. Multi Invoice (range) printing fails at second invoice call of function get_sales_parent_lines() in file sales/includes/sales_db.inc.
In the first invoice call in the Training Co (Demo Co) it succeeds:

SELECT parent.*
FROM 1_debtor_trans_details parent
    LEFT JOIN 0_debtor_trans_details trans 
        ON trans.src_id=parent.id
WHERE trans.debtor_trans_type='10' 
  AND trans.debtor_trans_no='17' 
GROUP BY parent.debtor_trans_no 
ORDER BY parent.debtor_trans_no;

SQL SELECT debug Trail attached.

Web Server hangs when the statement $rep->NewPage() tries to get executed for the second page in rep107.php - tested in XAMPP v1.7.3 on WinXP SP3 / FireFox v37.0.

Post's attachments

sql_audit_trail_1.zip 1.7 kb, 2 downloads since 2016-08-15 

You don't have the permssions to download the attachments of this post.

6 (edited by apmuthu 08/16/2016 03:27:53 am)

Re: Performance issues

All usual config settings on timeouts of PHP/Apache, were exhausted and finally the range of invoices printing issue was solved by reducing the width of the logo that initially spanned 660 pixels!

Diagnosing Memory Leaks - Allowed memory size of # bytes exhausted

When a large width logo is used, the FA's PDF object cannot spawn a NewPage and the webserver dies ceasing browser output that makes the system appear to hang.

The attachment shows the diagnostic for a small logo where the output is as desired and has been wikied.

Other References:
Memory Leaks With Objects in PHP 5
How to find which PHP script is leaking memory?

Post's attachments

FA_Range_Report_Diag.png 146.4 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.

Re: Performance issues

On further investigation, it appears that the logo width, if too high only results in truncation of image when displayed in the report header.

Some sort of cache may be playing havoc.

The solution is to
1. upload some other Company logo (Setup -> Company Setup) and update the company and then
2. revert back to the original logo and update the company and then
3. print range of invoices

Attached is a set of logos of varying widths and the way they get displayed in the Invoice header.

Post's attachments

FA_Inv_Range_PDF_logo_size.zip 231.3 kb, 7 downloads since 2016-08-16 

You don't have the permssions to download the attachments of this post.

Re: Performance issues

Hello,

I am not sure how to fix this. We use the tcpdf class member function Image(($img, $x, $y, $w, $h);

On line 75 in header2.inc we use the function AddImage($logo, $ccol, $this->row, 0, 40); This function in turn calls the tcpdf Image member function.

The parameter 40 is the height of the display. If the width is 0, then the width is calculated relative from the original width based on the height / image height.

During the years I have heard nothing about problems with the logo printing. Try to change the logo or laborate with the function parameters. Save the original line. Maybe you find a suitable solution.

/Joe
PS. I have involved Janusz in this problem. Maybe he can fix something.

Re: Performance issues

It is probably the scaling (rounding off) of the height with respect to the actual width (if smaller) or that of the width if the height is smaller, that may be the cause of the error. Any way to avoid scaling altogether as distortion occurs sometimes?

Re: Performance issues

FA get slow... i have using FA from latest 3 years ...and i seen its take much time to load many pages .... specially that function db_pager .....

its requested to ADMIN to see FA indexing ...ajax ...load ..etc proper ...i have more then 3gb data ...its take 7-8min time to load for some pages ... i have increase many setting in php.inc etc ...

Re: Performance issues

3gp volume of data is too heavy for your server. You better increase your RAM speed and cache size to get the your FA work faster like before.  It's not in code issue,  I feel you have to increase your system speed.

Subscription service based on FA
HRM CRM POS batch Themes

12 (edited by apmuthu 09/01/2016 01:21:55 pm)

Re: Performance issues

Try the MySQLtuner to adjust the server parameters and rebuild the indices.

You might want to optimise your FA db using my FAMods with upgradation caveats.

Closing and deleting previous years after suitable backups will improve usage latencies.

The includes/db_pager.inc already has the efficient LIMIT clause in line 326:

        $sql .= " LIMIT $offset, $page_len";
Post's attachments

MySQL Table Defragmentation.pdf 98.7 kb, 11 downloads since 2016-09-01 

You don't have the permssions to download the attachments of this post.