HTTPS Is Working, HTTP Not Working
On my 6'th install I got everything working (I think) via https, but http access gets me "The connection was refused when attempting to contact zimbra.sample.com".
I can do administrative stuff via https://zimbra.sample.com/zimbraAdmin, I can access email via https://zimbra.sample.com/zimbra/mail, but I cannot access http://zimbra.sample.com/
The install was mixed https and http. It was a clean Fedora Core 3, minimal install, no firewall. Any ideas? Let me know what logs or etc. to post....
why is it so slow then? and why the huge cpu spikes?
That's weird. The docs support you (Quick Start):
"Mixed mode uses HTTPS for logging in and HTTP for normal session
traffic. All modes use SSL encryption for back-end administrative traffic."
However, I notice HUGE cpu leaps on my desktop pc everytime I send/receive info from the zimbra server. Also, it is pretty slow despite being on a dual cpu server with loads of ram and only 3 people using zimbra--and no other apps hosted on it. I was just assuming it was slow due to the encryption.
Any other explanation?
speed issues seem client side, not server side
Thanks for your reply, Raj. Here's a breakdown of what I have observed:
client pc: P-IV 3.2Ghz, 2GB ram, when I click on inbox in Firefox or IE my cpu rises from 0-3% utilization up to 85-90% utilization. Ram stays around 40% due to windows and programs I have open. This also happens when I click on any other folder, when I open a message, or pretty much anything that interacts with the server. This PC is showing a huge load due to Zimbra, all cpu.
server: 2 P-III 1.1Ghz, 512Mb ram, Fedora Core 3, minimal install, desktop, no firewall, running only Zimbra as a service. I'm using the default multi-cpu kernel. I have even turned off extra services like gpm and apmd to streamline it a bit. First of all, I am using swap--about 100Mb of swap. VMstat shows no active si or so however. An average load would look like this: 0.97, 0.57, 0.57. CPU is being used at anywhere from 0-40% (Idles at anywhere from 100-58). The server is not showing any kind of load, imho.
I am not sure the server-side watch scripts are the source of the speed issues.... It seems more likely due to the client javascript or some kind of client-side something or other.