Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
- Grant
On 20/07/2013 20:14, Grant wrote:
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
Elio
On 7/21/2013 2:15 PM, Elio Tondo wrote:
On 20/07/2013 20:14, Grant wrote:
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
You need to provide more detail, specifically the history of using RC on this Celeron 700 machine. I.e. did RC run fine in the past but now you have the 30s latency opening new mail? Or did you just recently (re)deploy this machine and the 30s latency has existed from the start? Do any other machines accessing this RC server also experience latency opening new messages?
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
I will check into this the next time someone is using the system.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
Can you recommend one? Does opera fall into this category? I hope we aren't talking about lynx. :)
- Grant
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
You need to provide more detail, specifically the history of using RC on this Celeron 700 machine. I.e. did RC run fine in the past but now you have the 30s latency opening new mail? Or did you just recently (re)deploy this machine and the 30s latency has existed from the start? Do any other machines accessing this RC server also experience latency opening new messages?
From what I can gather from the users, the system in question has
always been this slow on RC. The RC server is accessed by 3 other machines and they experience just a second or two of latency.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
I will do this as soon as there is a user on the machine.
- Grant
On 23/07/2013 11:21, Grant wrote:
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
Can you recommend one? Does opera fall into this category? I hope we aren't talking about lynx. :)
No, it's a text-only browser.
See here:
http://www.techsupportalert.com/best-free-web-browser-lightweight.htm
Midori seems to have the best reputation. I tried also Galeon (6 years old, but still working) with good results.
Elio
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
Can you recommend one? Does opera fall into this category? I hope we aren't talking about lynx. :)
No, it's a text-only browser.
See here:
http://www.techsupportalert.com/best-free-web-browser-lightweight.htm
Midori seems to have the best reputation. I tried also Galeon (6 years old, but still working) with good results.
Thanks, I'll test midori, epiphany, and dillo. Does anyone know if the browser cache can be disabled on any of those?
- Grant
On 23/07/2013 12:16, Grant wrote:
Thanks, I'll test midori, epiphany, and dillo. Does anyone know if the browser cache can be disabled on any of those?
Try in the preferences, but I don't see any such option in Midori, while Epiphany allows to specify the space for temp files under Privacy.
I just tried Midori, and it looks very fast, and works with RC.
Dillo is not useful, it has no Javascript.
Elio
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
Here's what I get while someone is seated at the system and using Roundcube in Chrome:
# free total used free shared buffers cached Mem: 513072 447812 65260 0 16896 209672 -/+ buffers/cache: 221244 291828 Swap: 2097148 0 2097148
- Grant
Grant skrev den 2013-07-23 11:31:
From what I can gather from the users, the system in question has always been this slow on RC. The RC server is accessed by 3 other machines and they experience just a second or two of latency.
try let users use squirrelmail with have no ajax, is it fast like hell ?
if so its not your imap store, just to rule out roundcube problems :)
Grant skrev den 2013-07-23 11:21:
Can you recommend one? Does opera fall into this category? I hope we aren't talking about lynx. :)
build kernel with FrameBuffer, then try links -g http://www.roundcube.net/ :)
then turn over to runlevel 3 instead of 5 :=)
it uses less ram, and you still have graphic and mouse supported
On 7/23/2013 11:17 AM, Grant wrote:
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
Here's what I get while someone is seated at the system and using Roundcube in Chrome:
# free
Using the "-m" switch displays output in megabytes--easier to read.
total used free shared buffers cachedMem: 513072 447812 65260 0 16896 209672 -/+ buffers/cache: 221244 291828 Swap: 2097148 0 2097148
This clearly shows the host isn't using swap, has 64MB free, and is using ~200MB for buffer cache. So it seems to have plenty of memory.
JVMs and JAVA are notoriously inefficient, but that should cause a 30s delay just opening a new email. Using HTTPS and JAVA together may be enough to bring a Celery 700 to its knees. Try using straight HTTP instead to eliminate the encryption. This will make a big difference with binary attachments such as photos and the like. With small text only emails it shouldn't cause a big delay.
There are many other things you can optimize before replacing Firefox with another browser.
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
Here's what I get while someone is seated at the system and using Roundcube in Chrome:
# free
Using the "-m" switch displays output in megabytes--easier to read.
total used free shared buffers cachedMem: 513072 447812 65260 0 16896 209672 -/+ buffers/cache: 221244 291828 Swap: 2097148 0 2097148
This clearly shows the host isn't using swap, has 64MB free, and is using ~200MB for buffer cache. So it seems to have plenty of memory.
JVMs and JAVA are notoriously inefficient, but that should cause a 30s delay just opening a new email. Using HTTPS and JAVA together may be enough to bring a Celery 700 to its knees. Try using straight HTTP instead to eliminate the encryption. This will make a big difference with binary attachments such as photos and the like. With small text only emails it shouldn't cause a big delay.
I'd rather stick with HTTPS if possible. Are there any other good options for speeding things up besides switching browsers and disabling HTTPS?
- Grant
On 8/2/2013 1:04 AM, Grant wrote:
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Your problem is likely the amount of RAM; when you start X and Chrome, your client almost surely starts swapping, because there isn't enough RAM for the running processes. Roundcubemail uses AJAX which requires a fast javascript interpreter, and this makes things worse if your processes (including Chrome) are swapping.
On such low-end systems you should use a very lightweight browser instead of Chrome, even if this can give some limitations.
This is simple to check. With all apps running simply run "free -m" and post the output here.
Here's what I get while someone is seated at the system and using Roundcube in Chrome:
# free
Using the "-m" switch displays output in megabytes--easier to read.
total used free shared buffers cachedMem: 513072 447812 65260 0 16896 209672 -/+ buffers/cache: 221244 291828 Swap: 2097148 0 2097148
This clearly shows the host isn't using swap, has 64MB free, and is using ~200MB for buffer cache. So it seems to have plenty of memory.
JVMs and JAVA are notoriously inefficient, but that should cause a 30s delay just opening a new email. Using HTTPS and JAVA together may be enough to bring a Celery 700 to its knees. Try using straight HTTP instead to eliminate the encryption. This will make a big difference with binary attachments such as photos and the like. With small text only emails it shouldn't cause a big delay.
I'd rather stick with HTTPS if possible.
Of course. I'm simply recommending that you test with HTTP to see if HTTPS is part of your delay issue.
Are there any other good options for speeding things up besides switching browsers and disabling HTTPS?
There may be but we don't have a crystal ball. You're going to have to do some testing and process of elimination to figure out the cause of the problem. Only then can you identify a solution.
On Sat, Jul 20, 2013 at 1:14 PM, Grant emailgrant@gmail.com wrote:
Can anything be done to speed up Roundcube on a Celeron 700 with 512MB RAM (maxed out) running Gentoo Linux? We're using the Chrome browser and the CPU is 95% idle when no one is logged into X. I'm getting reports of 30+ seconds to open an email.
Assuming this machine is the web browser, and not the server itself... and that you have control over the roundcube server itself, and that clients on other computers in your same local network do not experience the slowdown, and that it has always been slow and this isn't a new development, some things I would try:
- eliminate any proxy to see if it makes a difference
- try without SSL, if you normally use SSL, to see if it makes a difference
- try from a new user account or new browser profile on the celeron
- If SSL is slow and non-SSL is not, try using smaller key sizes or
different ciphers ("openssl speed" on the slow box will run an SSL benchmark)
- try other browsers on the same computer
- try other roundcube themes
- use Chrome's developer tools to see if you can isolate the
slow-loading objects on the page
- do other AJAX-heavey webmail like Google or Yahoo cause slowness
issues on that box?
- check the mail server logs to be sure there's not an actual slowdown
accessing this user's mail for some reason
- try to install a different webmail product on the web server to see
if it is any faster. Some providers offer multiple interfaces.
Good luck :)
-
Benny Pedersen -
Elio Tondo -
Grant -
Paul Hartman -
Stan Hoeppner