Dear Supporter, I migrated my Email server from SquirrelMail to RoundCube.
From the last (with SquirrelMail) the Email Server worked fine. Now, my RoundCube interface works fine also, except, the loading speed of Web page quite slow. It slows down speed of all components like Login Page, Mailing Page, Compose Page, Settings Page... Could you please let me know what is the Recommendation Hardware to using Round Cube (Chip, RAM, Bus speed, HardDisk...). This might be my old Server with weak processing capability, and I plan to upgrade it. May thanks in advance for you support. BRs/ HoanNT.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
hoannt@mail.ciid.cz.cc put forth on 9/27/2010 4:28 AM:
I migrated my Email server from SquirrelMail to RoundCube.
From the last (with SquirrelMail) the Email Server worked fine.
Now, my RoundCube interface works fine also, except, the loading speed of Web page quite slow. It slows down speed of all components like Login Page, Mailing Page, Compose Page, Settings Page...
Could you please let me know what is the Recommendation Hardware to using Round Cube (Chip, RAM, Bus speed, HardDisk...). This might be my old Server with weak processing capability, and I plan to upgrade it.
I'm running RC 0.3 on a 10 year old 500 MHz Celeron with only 384MB RAM, using lighty and fastcgi, and it's very snappy. This machine is also the MX for my domain and my Dovecot server. I doubt your problem is hardware related, unless your host is like a 133 Pentium with 32MB RAM or similar. What *nix version, PHP version, and httpd server are you using?
Maybe as importantly, have you tested more than one client PC and more than one browser on each client PC against this RC server?
Lets see...
RC login screen is > 183 kB SquirrelMail 9,30 kB
After you login... RC 136 kB Squirrel 25kB
etc etc...
Then there is a question about your internet connection, server connection, etc etc...
On 9/27/2010 12:03 PM, Stan Hoeppner wrote:
hoannt@mail.ciid.cz.cc put forth on 9/27/2010 4:28 AM:
I migrated my Email server from SquirrelMail to RoundCube.
From the last (with SquirrelMail) the Email Server worked fine.
Now, my RoundCube interface works fine also, except, the loading speed of Web page quite slow. It slows down speed of all components like Login Page, Mailing Page, Compose Page, Settings Page...
Could you please let me know what is the Recommendation Hardware to using Round Cube (Chip, RAM, Bus speed, HardDisk...). This might be my old Server with weak processing capability, and I plan to upgrade it.
I'm running RC 0.3 on a 10 year old 500 MHz Celeron with only 384MB RAM, using lighty and fastcgi, and it's very snappy. This machine is also the MX for my domain and my Dovecot server. I doubt your problem is hardware related, unless your host is like a 133 Pentium with 32MB RAM or similar. What *nix version, PHP version, and httpd server are you using?
Maybe as importantly, have you tested more than one client PC and more than one browser on each client PC against this RC server?
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Mon, 27 Sep 2010 12:47:03 +0200, Marinko Tarlac mangia81@gmail.com wrote:
Lets see...
RC login screen is > 183 kB SquirrelMail 9,30 kB
After you login... RC 136 kB Squirrel 25kB
etc etc...
Then there is a question about your internet connection, server connection, etc etc...
That's irrelevant. Anybody can write a 2kB login page that would take forever to load. Roundcube loadz a lot of javascript, css and images that takes a bit of space, but almost no CPU since they are static files.
If you have a differences between loading times, maybe you should start looking at the differences between the setups. Web server is likely to be the same (I guess Apache/php5 ?). What about the database ?
Julien
!DSPAM:4ca0805f223372001210516!
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Mon, 27 Sep 2010 12:47:03 +0200, Marinko Tarlac mangia81@gmail.com wrote:
Lets see...
RC login screen is > 183 kB SquirrelMail 9,30 kB
After you login... RC 136 kB Squirrel 25kB
etc etc...
Then there is a question about your internet connection, server connection, etc etc...
That's irrelevant. Anybody can write a 2kB login page that would take forever to load. Roundcube loadz a lot of javascript, css and images that takes a bit of space, but almost no CPU since they are static files.
If you have a differences between loading times, maybe you should start looking at the differences between the setups. Web server is likely to be the same (I guess Apache/php5 ?). What about the database ?
Julien
!DSPAM:4ca0805f223372001210516!
List info: http://lists.roundcube.net/users/ BT/ee2c3396
I use Postfix + Dovecot + MySql + Sieve + ManageSieve + RoundCube. I tried to connect to my server from both LAN connection and from Internet Connection. Both are slow when using RoundCube. The speed is acceptable with SquirrelMail. (now both RC and SM are working together)
In my opinion, it seems that my server need to be upgrade.
BRs/Hoan
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Mon, 27 Sep 2010 12:47:03 +0200, Marinko Tarlac mangia81@gmail.com wrote:
Lets see...
RC login screen is > 183 kB SquirrelMail 9,30 kB
After you login... RC 136 kB Squirrel 25kB
etc etc...
Then there is a question about your internet connection, server connection, etc etc...
That's irrelevant. Anybody can write a 2kB login page that would take forever to load. Roundcube loadz a lot of javascript, css and images that takes a bit of space, but almost no CPU since they are static files.
If you have a differences between loading times, maybe you should start looking at the differences between the setups. Web server is likely to be the same (I guess Apache/php5 ?). What about the database ?
Julien
!DSPAM:4ca0805f223372001210516!
List info: http://lists.roundcube.net/users/ BT/ee2c3396
I use Postfix + Dovecot + MySql + Sieve + ManageSieve + RoundCube. I tried to connect to my server from both LAN connection and from Internet Connection. Both are slow when using RoundCube. The speed is acceptable with SquirrelMail. (now both RC and SM are working together)
In my opinion, it seems that my server need to be upgrade.
BRs/Hoan
List info: http://lists.roundcube.net/users/ BT/ee2c3396
Another information is my server:
- Chip AMD Opteron Processor 246/ 2GHz (x2)
- RAM 1GB Bus 400MHz (512MB x 2)
- HDD 160GB
- Gigabits Network Connection
BRs/Hoan
List info: http://lists.roundcube.net/users/ BT/9b404e9e
hoannt@mail.ciid.cz.cc put forth on 9/28/2010 8:46 PM:
I use Postfix + Dovecot + MySql + Sieve + ManageSieve + RoundCube. I tried to connect to my server from both LAN connection and from Internet Connection. Both are slow when using RoundCube. The speed is acceptable with SquirrelMail. (now both RC and SM are working together)
In my opinion, it seems that my server need to be upgrade.
Another information is my server:
- Chip AMD Opteron Processor 246/ 2GHz (x2)
- RAM 1GB Bus 400MHz (512MB x 2)
- HDD 160GB
- Gigabits Network Connection
What is your concurrent user load when you are performing your testing? If there are no other, or few, users connected, then the problem is most definitely _not_ your hardware, but something in your server software stack, or, your client. You never did respond with the client information I requested. You also never responded with what web server you're using.
If you're already convinced the problem is slow hardware, then buy a new server and then tell us if that fixed your problem. It seems you are not open to any suggestions being posted here but are merely looking for someone to agree with your predisposition that it's a hardware problem.
If you're simply looking for a hardware recommendation, I'd be glad to provide one. Look at my email address. ;) Do you purchase pre-built servers, or do you built your own? I assume the former, as if you were in the latter category, you probably wouldn't be asking for opinions.
Hi,
I run a cluster of Roundcube servers (3 ESX VM's on 3 ESX hosts, each roundcube VM is allocated 2GB of RAM with 5Ghz over 4 VCPU's) with a shared mySQL database (pair of Dell PowerEdge M610's with 16GB RAM) that has active/active replication on.
Currently, this setup is serving about 45,000 users (not all at once, at any one time there is about 120 HTTPS sessions per box) and it seems reasonably quick. We did have issues where the roundcube VM's were allocated 1GB of RAM, but adding the extra 1GB of RAM made a huge difference.
The mail servers that Roundcube connect to are all either Dovecot or Courier.
I would suggest based off your specs maybe some additional RAM would help (that reduced our load average per box from about 8-9 down to 0.5-1.
Thanks
On 29/09/2010 11:55 AM, Stan Hoeppner wrote:
hoannt@mail.ciid.cz.cc put forth on 9/28/2010 8:46 PM:
I use Postfix + Dovecot + MySql + Sieve + ManageSieve + RoundCube. I tried to connect to my server from both LAN connection and from Internet Connection. Both are slow when using RoundCube. The speed is acceptable with SquirrelMail. (now both RC and SM are working together)
In my opinion, it seems that my server need to be upgrade.
Another information is my server:
- Chip AMD Opteron Processor 246/ 2GHz (x2)
- RAM 1GB Bus 400MHz (512MB x 2)
- HDD 160GB
- Gigabits Network Connection
What is your concurrent user load when you are performing your testing? If there are no other, or few, users connected, then the problem is most definitely _not_ your hardware, but something in your server software stack, or, your client. You never did respond with the client information I requested. You also never responded with what web server you're using.
If you're already convinced the problem is slow hardware, then buy a new server and then tell us if that fixed your problem. It seems you are not open to any suggestions being posted here but are merely looking for someone to agree with your predisposition that it's a hardware problem.
If you're simply looking for a hardware recommendation, I'd be glad to provide one. Look at my email address. ;) Do you purchase pre-built servers, or do you built your own? I assume the former, as if you were in the latter category, you probably wouldn't be asking for opinions.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Wed, 29 Sep 2010 08:46:34 +0700 (ICT), hoannt@mail.ciid.cz.cc wrote:
Another information is my server:
- Chip AMD Opteron Processor 246/ 2GHz (x2)
- RAM 1GB Bus 400MHz (512MB x 2)
- HDD 160GB
- Gigabits Network Connection
What is your /client/ machine? Hardware, OS, browser, ...
Maybe it is a server issue, but not one of CPU load. What is the load like while you are interacting with the server and experiencing sluggishness? You can do basic analysis here, like running "vmstat 1" or "top" in a terminal window, while interacting with the server?
Are there logs being generated? Maybe you have some debugging turned on, or maybe something is spewing lots of error messages to a log.
Who knows?
List info: http://lists.roundcube.net/users/ BT/9b404e9e
Thank you all!
@Stan: May be you're right above my purpose when I raised the question here. I searched on Internet but didn't find an expected answer so I want to confirm it. Why I thought that cause my SquirrelMail ran faster, but RoundCube was slow. Every other things were the same (Postfix, Dovecot, Mysql, Apache) so I thought it might due to the more processing and resources for RoundCube. The Email server's still in the development phase, so the load is too few. Maybe I should consider to check in those software module, if anything made it slow.
@p8x: Thank you for you realistic information. For your information, when I checked the SystemInfo, the Total Memory was nearly 1GB, but the Free Memory was only 50MB. When I tried to stop httpd, mysqld, dovecot, postfix; the Free Memory expanded to 140MB. I also check the CPU load for those service, and I found they not take too much CPU resource.
Do you think any problem in my OS (Centos5)? I run only Centos5, SSH service and those email services. 50MB free memory maybe too small while the server's in work.
BRs/ HoanNT
List info: http://lists.roundcube.net/users/ BT/9b404e9e
On Thu, 30 Sep 2010 08:54:46 +0700, hoannt@mail.ciid.cz.cc wrote:
@p8x: Thank you for you realistic information. For your information, when I checked the SystemInfo, the Total Memory was nearly 1GB, but the Free Memory was only 50MB.
What exactly are you looking at?
Use the "free" command, and look at the "free" column of the " +/- buffers/cache:" line.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
Here's my out put when running TOP or FREE:
top - 11:16:52 up 2 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 904020k total, 754172k used, 149848k free, 105632k buffers Swap: 2097144k total, 72k used, 2097072k free, 390776k cached
[root@localhost ~]# free total used free shared buffers cached Mem: 904020 753852 150168 0 105784 390820 -/+ buffers/cache: 257248 646772 Swap: 2097144 72 2097072
BRs/Hoan
On Thu, 30 Sep 2010 08:54:46 +0700, hoannt@mail.ciid.cz.cc wrote:
@p8x: Thank you for you realistic information. For your information, when I checked the SystemInfo, the Total Memory was nearly 1GB, but the Free Memory was only 50MB.
What exactly are you looking at?
Use the "free" command, and look at the "free" column of the " +/- buffers/cache:" line.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
hoannt@mail.ciid.cz.cc put forth on 9/29/2010 11:22 PM:
Here's my out put when running TOP or FREE:
top - 11:16:52 up 2 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 904020k total, 754172k used, 149848k free, 105632k buffers Swap: 2097144k total, 72k used, 2097072k free, 390776k cached
[root@localhost ~]# free total used free shared buffers cached Mem: 904020 753852 150168 0 105784 390820 -/+ buffers/cache: 257248 646772 Swap: 2097144 72 2097072
The Linux kernel heavily caches disk blocks. The bulk of your memory usage is in buffers/cache as with most Linux systems. Execute the following commands and look at the top row of the 'free' column.
$ echo 3 > /proc/sys/vm/drop_caches $ free -m
Your system is not low on memory at this point. The kernel will drop memory from the cache and free it for processes when the need arises. If you add 100 concurrent users to RC, far more of your memory will be consumed by processes and less by cache.
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
hoannt@mail.ciid.cz.cc put forth on 9/29/2010 11:22 PM:
Here's my out put when running TOP or FREE:
top - 11:16:52 up 2 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 904020k total, 754172k used, 149848k free, 105632k buffers Swap: 2097144k total, 72k used, 2097072k free, 390776k cached
[root@localhost ~]# free total used free shared buffers cached Mem: 904020 753852 150168 0 105784 390820 -/+ buffers/cache: 257248 646772 Swap: 2097144 72 2097072
The Linux kernel heavily caches disk blocks. The bulk of your memory usage is in buffers/cache as with most Linux systems. Execute the following commands and look at the top row of the 'free' column.
$ echo 3 > /proc/sys/vm/drop_caches $ free -m
Your system is not low on memory at this point. The kernel will drop memory from the cache and free it for processes when the need arises. If you add 100 concurrent users to RC, far more of your memory will be consumed by processes and less by cache.
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
-- Stan
List info: http://lists.roundcube.net/users/ BT/ee2c3396
Thank you! I'm analyzing my software stack at this moment. I will update you the last result later. BRs/ Hoan.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
I think my problem it something like this: http://www.roundcubeforum.net/5-release-support/14-release-discussion/3061-r...
I try to reconfigure the main.inc.php (IMAP part), forcus on imap_auth_type, imap_root, imap_delimiter. So the speed is OK now.
Thank you all for your support! BRs/ Hoan. _______________________________________________ List info: http://lists.roundcube.net/users/ BT/9b404e9e
hoannt@mail.ciid.cz.cc put forth on 9/30/2010 1:29 AM:
hoannt@mail.ciid.cz.cc put forth on 9/29/2010 11:22 PM:
Here's my out put when running TOP or FREE:
top - 11:16:52 up 2 days, 53 min, 2 users, load average: 0.00, 0.00, 0.00 Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0%us, 0.3%sy, 0.0%ni, 97.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 904020k total, 754172k used, 149848k free, 105632k buffers Swap: 2097144k total, 72k used, 2097072k free, 390776k cached
[root@localhost ~]# free total used free shared buffers cached Mem: 904020 753852 150168 0 105784 390820 -/+ buffers/cache: 257248 646772 Swap: 2097144 72 2097072
The Linux kernel heavily caches disk blocks. The bulk of your memory usage is in buffers/cache as with most Linux systems. Execute the following commands and look at the top row of the 'free' column.
$ echo 3 > /proc/sys/vm/drop_caches $ free -m
Your system is not low on memory at this point. The kernel will drop memory from the cache and free it for processes when the need arises. If you add 100 concurrent users to RC, far more of your memory will be consumed by processes and less by cache.
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
Thank you! I'm analyzing my software stack at this moment. I will update you the last result later. BRs/ Hoan.
It may speed this process up tremendously if you'd create a test account and post the credentials on the RC list, along with the URL of the server. With a few of us logging in and seeing first hand how it performs, we may be able to narrow down the problem pretty quickly, saving all of us a bit of time with all the back/forth emails.
hoannt@mail.ciid.cz.cc put forth on 9/30/2010 1:44 AM:
Again, your current slow RC response is due to something in the software stack on the server, or more likely, the client PC. What are the specs of the client PC hardware and software? This is relevant due to the java processing on the client. If your client PC/OS/Browser is slow, it won't matter how fast the server is responding.
I think my problem it something like this: http://www.roundcubeforum.net/5-release-support/14-release-discussion/3061-r...
I try to reconfigure the main.inc.php (IMAP part), forcus on imap_auth_type, imap_root, imap_delimiter. So the speed is OK now.
Thank you all for your support!
Ahh, that auth type detection would do it. And on a webmail server you're going to see the delay with every action (unless you have imapproxy, which will lessen the delay effects after the initial login).
If you're running all of the RC stack on one machine, and requiring HTTPS to connect to RC, there is no reason to use IMAPS or any password encryption between RC and your IMAP server, as they're running on the same box. Snooping the unencrypted credentials would require that a hacker had already rooted the host. At that point you've got much bigger problems than unencrypted passwords being transferred in shared memory. ;)
Glad you got it going. I'm still not completely clear as to what you actually changed to fix the problem. Did you set these to a manual value:
$rcmail_config['imap_auth_type'] = null; $rcmail_config['imap_root'] = null; $rcmail_config['imap_delimiter'] = null;
They all default to auto-detect, hence the "null". If these were part of the cause of your problem, did you manually modify them at some point in the past, causing the problem? I'm using Dovecot with RC and I never had to change these. Then again I configured TCP 143. Maybe the auth auto detection doesn't cause a delay in this setup, but does if you tell it to use IMAPS?
It may be beneficial to future Googlers if you were to write up a more detailed email explaining the cause of your problem, and exactly what you changed to fix it.
On Thu, 30 Sep 2010 13:44:02 +0700, hoannt@mail.ciid.cz.cc wrote:
I try to reconfigure the main.inc.php (IMAP part), forcus on imap_auth_type, imap_root, imap_delimiter. So the speed is OK now.
What good is that, if your IP and domain appear in anti-spam blocklists?
Problem solving is all about priorities! :)
List info: http://lists.roundcube.net/users/ BT/9b404e9e
Hi Stan,
Last time, I let those configuration as default:
$rcmail_config['imap_auth_type'] = null; $rcmail_config['imap_root'] = null; $rcmail_config['imap_delimiter'] = null;
Now, my one is:
$rcmail_config['imap_auth_type'] = "plain"; $rcmail_config['imap_root'] = null; $rcmail_config['imap_delimiter'] = "."; //a dot for delimiter
- $rcmail_config['imap_auth_type'] = "plain";
Actually, in MYSQL database, the Password is MD5-CRYPT. I just checked it again, the password was store like "$1$51dd62a1$RxZRpwoZ/q5EuEH/3epFp". But I don't know why I setup the PLAIN and it's still working. This is my experience when I configure for ManageSieve Plugin (of RoundCube). I also set Plain for ManageSieve and it works.
- $rcmail_config['imap_root'] = ""; //blank
I store all mails in the directory of each user, so this parameter is blank.
- $rcmail_config['imap_delimiter'] = ".";
I'm using Dovecot and the Default folder Delimiter is a dot "."
In my opinion, the first one, "imap_auth_type", is the most important parameter to speed up when you are login, and when you're click on other folders in the interface. I changed it once and the effect was very good. It was true in my case. For the second and the third, I see no effect but I still want to change it.
BRs/ Hoan.
List info: http://lists.roundcube.net/users/ BT/9b404e9e
Kaz Kylheku put forth on 9/30/2010 8:42 AM:
On Thu, 30 Sep 2010 13:44:02 +0700, hoannt@mail.ciid.cz.cc wrote:
I try to reconfigure the main.inc.php (IMAP part), forcus on imap_auth_type, imap_root, imap_delimiter. So the speed is OK now.
What good is that, if your IP and domain appear in anti-spam blocklists?
Problem solving is all about priorities! :)
If I was him I wouldn't worry much. The number of "real" MXen around the world using NOMOREFUNN or RATS-Dyna can probably be counted on one humans digits (fingers and toes). BRBL, on the other hand, gets mainstream use, mainly because it's active by default on Barracuda's appliances, and the installed base of such appliances is fairly substantial, in the US anyway.
But I would guess BRBL penetration is far less than 1% of MXen worldwide. If my own experience with the free access to BRBL is any indication--it times out far more often than it responds to queries--I'd guess few outside appliance owners are using it.
It rejected so little spam here compared to my local countermeasures and Spamhaus ZEN that I deconfigured it due to the timeout issue. If other OPs did the same for the same or other reasons, then penetration is limited to their appliances, with most of the installed base in small businesses and educational institutions in the U.S.. The OP is in Vietname, so again, he probably has little to worry about, being on these 3 dnsbls.
-
hoannt＠mail.ciid.cz.cc -
Julien Vehent -
Kaz Kylheku -
Marinko Tarlac -
p8x -
Stan Hoeppner