Question What are optimal email settings for vbulletin and dedicated server?

[Sicilian]

Guys, need some advice please.

We're running a dedicated server.

Just sent a mass email using vbmail, got severe server slowdown.

Our vbulletin email settings as follows:

Use Mailqueue System = Yes
Use Cron Based Sending = no
Number of Emails to Send Per Batch = 200
E-Mail Send Delay = 2 seconds

What would you guys recommend?

Please change title to 'What are optimal email settings for vbulletin and dedicated server?'

To make things clear, the slow down occurred on the initial send, while vbmail was processing the list.

The server is happily sending queued email now and does not have a limit set on emails per hour.

Would just like to stop the Forum virtually locking up when clicking on send mail.

I just added this to htaccess

php_value max_input_vars 10000

As instructed when creating mailing list, what exactly is the purpose of this?

Any help with this please?

 

[Fillip H.]

To make things clear, the slow down occurred on the initial send, while vbmail was processing the list.

That's not the sending, that's inserting it into the mailqueue table.

You may want to check your mailqueue table for overhead, or have your system admin optimise MySQL in general, as that's most likely the reason.

I just added this to htaccess

php_value max_input_vars 10000

As instructed when creating mailing list, what exactly is the purpose of this?

If you have a large number of usergroups, ill-conceived security features added to PHP 5.3 will prevent you from saving all the permissions.

This works around that by upping the limit of how many form variables you can submit.

The background behind this is that The PHP Group believe only malicious scripts like PHP Shell scripts require more than 1000 form variables, which is an entirely false assumption on their part.

 

[Sicilian]

Still not answered what I originally asked.

What email settings would you recommend in Vbulletin email settings?

I'd like to try that first, we have not other issues with MySQL. Are you able to optimise in anyway? Obviously we'd pay for your time.

 

[Fillip H.]

From what you've told me, your issue is that when vBMail tells vBulletin to queue its emails, your database server can't handle the number of queries this operation generates. There's no way to customise how many emails vBMail queues per page at this time.

In other words: If your forum loads fine after vBMail has queued its email (processed the list), then the step you're having issues with is in no way, shape or form related to the settings you asked about in the OP. Those settings control the sending of email, not the queuing of emails by vBMail.

The only "optimisation" that can be done with those settings is reducing the number of emails sent per batch, but since that does not appear to be where your issue is then it's 100% irrelevant.

 

[Sicilian]

Well would really like to get to the bottom of this. We're on a dedicated server with 4GB RAM, CPU spec below, surely the board should not be slowing to a halt. Would really like some help to get to the bottom of this please.

root@server [~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
stepping : 11
cpu MHz : 2133.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4266.81
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
stepping : 11
cpu MHz : 1600.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4266.79
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
stepping : 11
cpu MHz : 1600.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4266.90
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU X3210 @ 2.13GHz
stepping : 11
cpu MHz : 2133.000
cache size : 4096 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4266.75
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

root@server [~]#

 

[Fillip H.]

Do you have phpMyAdmin? If so, I would suggest watching the "Processes" tab while vBMail is queuing its emails.

If you're seeing a high volume of locks or slow queries, that would be the explanation.

 

[Sicilian]

Do you have phpMyAdmin? If so, I would suggest watching the "Processes" tab while vBMail is queuing its emails.

If you're seeing a high volume of locks or slow queries, that would be the explanation.

Ok thanks, I'll do that next time I send an email out.