View Issue Details

IDProjectCategoryView StatusLast Update
0017241mantisbtperformancepublic2014-05-04 15:57
ReporterMicky Assigned Tograngeway  
PriorityurgentSeveritymajorReproducibilityhave not tried
Status closedResolutionno change required 
PlatformWindowsOS2003OS Version2003 standard ed
Product Version1.2.17 
Summary0017241: Mantis 1.2.17 is very slow by update, insert new bug and delete
Description

We have started from the version 1.2.9 and after some small test in our test environment we have moved the versione 1.2.17 to production.
This result in a very slow environment (we have about 1800 issues registered).

The update, insert and delete of an issues result in a very long process and some time in a server error 500.

We have now restored the versione 1.2.9 and we will replicate the production environment with the 1.2.17 in order to do some extensive tests.

Additional Information

We are operating with:

  • MySQL 5.5
  • IIS server
  • PHP 5.2
TagsNo tags attached.

Activities

grangeway

grangeway

2014-04-23 13:24

reporter   ~0040139

Hi Micky,

I understand you are running MySQL on windows with IIS and php 5.2. And that you currently have 1.2.9 running on a production environment and when upgrading to 1.2.17 experience a slow down.

First off, I'd be interested to see the output of the database statistics script - which shows number of rows in various tables.

This can be found at /admin/db_stats.php on your installation

Secondly, what value do you have set for

$g_email_send_using_cronjob

in your config.

Could you try setting this to:

$g_email_send_using_cronjob = ON;

[Note: this will queue any emails up and not send them until you add a scheduled task]

Thirdly,

If you go to /admin/email_queue.php, does this show the message "Email Queue Empty" or are there entries in the list ?

And finally...

Do you make use of LDAP authentication with Mantis?

Paul

Micky

Micky

2014-04-23 14:13

reporter   ~0040143

Hi Paul,

here the statistics of the DB:

mantis_bug_file_table = 354 records
mantis_bug_history_table = 16919 records
mantis_bug_monitor_table = 3 records
mantis_bug_relationship_table = 891 records
mantis_bug_revision_table = 929 records
mantis_bug_table = 1656 records
mantis_bug_tag_table = 15 records
mantis_bug_text_table = 1656 records
mantis_bugnote_table = 1196 records
mantis_bugnote_text_table = 1196 records
mantis_category_table = 31 records
mantis_news_table = 0 records
mantis_plugin_table = 1 records
mantis_project_file_table = 0 records
mantis_project_table = 12 records
mantis_project_user_list_table = 53 records
mantis_project_version_table = 0 records
mantis_tag_table = 2 records
mantis_user_table = 7 records
mantis_user_profile_table = 2 records
mantis_user_pref_table = 5 records
mantis_user_print_pref_table = 0 records
mantis_custom_field_project_table = 127 records
mantis_custom_field_table = 23 records
mantis_custom_field_string_table = 19370 records
mantis_filters_table = 42 records
mantis_sponsorship_table = 0 records
mantis_tokens_table = 7 records
mantis_project_hierarchy_table = 2 records
mantis_config_table = 10 records
mantis_email_table = 3865 records

About configuartion:
$g_email_send_using_cronjob was OFF I put to ON

e-mail queue if very big...

I don't use LDAP for login

grangeway

grangeway

2014-04-23 14:40

reporter   ~0040145

Right, OK

mantis_email_table = 3865 records should really be an empty table.

if email_send_using_cronjob is OFF -> emails get sent at end of a php web page request. So the slowness you are seeing php trying to send 3000 emails.

If it is ON, then you need to run the separate sendemails.php cronjob.

I suggest that you clear down the contents of the mantis_email_table and then we look at your mail settings:

See:

$g_phpMailer_method = PHPMAILER_METHOD_MAIL;
$g_smtp_host = 'localhost';
$g_smtp_username = '';
$g_smtp_password = '';

Given you are on IIS+Windows, you probably want to set PHPMAILER_METHODSMTP as the mailer method, and find out some sensible smtp* settings for email notifications.

I suggest you clear out the email queue first to avoid sending 3800 mails to people. This can be done by doing a DB query, or by using the /admin/email_queue.php 'send or delete' option whilst the server is still broken.

if you think it's important that people receive the 4000 queued emails, obviously fix the email settings first, but i'm guessing...

Micky

Micky

2014-04-24 03:28

reporter   ~0040155

Hi Paul,
I understan th issue.
I have now changed the parameters, deleted the mantis_email_table (in both 1.2.9 and 1.2.17) and it seems to work fine.

I will continue to test in the 1.2.17 a couple od days before to migrate in production.
Many thanks for the support.

Micky

grangeway

grangeway

2014-04-24 14:00

reporter   ~0040161

cool ! - and I hope by 'deleted the mantis_email_table' you mean the contents only :)

Micky

Micky

2014-04-25 01:38

reporter   ~0040169

Of course... :)