Hello!
A quick bug report regarding the current version of Virtualmin, I found a bug that I can reproduce at will (happens 100% of the time).
Tested with the latest stable versions of Firefox (44.0.2) and Chrome (48.0.2564.109 m - but Chrome just started updating itself, huh.) Server details: Debian Linux 7.3, Webmin 1.782, Authentic 17.71, Virtualmin errr... wait, where is the version of Virtualmin shown ?!? Sorry, no idea of the exact version of virtualmin, 5.something.
I tried just in case, in a shell session, an apt-get update, apt-get upgrade, didn't help.
This is NOT a call for help, I can live without access to that page. But maybe you guys would appreciate to be informed of the existence of this issue. If so, just reach up to me.
Kind regards!
The display of package updates can take a long time. I would wait a little longer.
I went as far as eight actual minutes, with Chrome.
(and meanwhile, the server had plenty of spare CPU and RAM, no bottleneck of sorts to slow down the processing, while it's a pure server for website serving purposes, without additional bloatware or anything)
Howdy,
Thanks for the report!
Do you see that issue with the older Virtualmin Framed theme as well? Or does that only occur when using the newer Authentic theme?
-Eric
With the old Virtualmin Framed theme, my browser is slowed while the page is loaded (46500 packages to load: let's be patient), but the page DOES work.
The "top of page" contents of the page have been loaded after a two-second delay (usually it's immediately that page contents are loaded), and the rest is gradually adding itself at the bottom of the page.
I'm updating my post (with re-formatting in the end) with how things go...
*
1 minute: Firefox slow to use.
*
3 minutes. In terms of slowness: if I type too fast, my Firefox will briefly (three, four seconds) stop responding.
*
4 minutes: the page has been fully loaded entirely (770 MB of memory imprint for Firefox, it's not that big, it's been worse at times), and there are no slowdowns anymore.
So, yeah, that might be an issue between Firefox and the Authentic theme.
(edit: ooops. In terms of slowness, I forgot I was also loading the same page with Chrome, to make a comparison. That must have slowed down things a bit.)
Never encountered that problem. Mine works on an SSD drive with 100mbps speed nics. It loads fast with minimum of 1 min to max of 2 minutes. Must be also related to your server. I also upgraded 358 packages last week on my test server (I never applied changes on my main without checking first using a test server).
I was expecting things to load slow since I was using delta RPM but viola, it loads fast both on live and test.
I do have problem with whitescreen of death with CSF on the newer authentic themes since January 2016
Visit me at coderinthebox.com
I would wait more than 8 minutes. Go away for lunch, and see if it's still hanging when you return. Checking for available package updates relies on the network and on the response from distant servers, both of which can be unpredictable.
The other thing worth trying is to temporarily change the theme away from the new Authentic theme to one of the older themes, and see if that helps. The Authentic theme does things with the HTML Canvas element and seems to get very slow at times.
Well, Joe, my server's also with an SSD for the system, and it's like that, bad with Authentic, OK with the old theme.
Go figure, I guess.
I didn't test with the latest Authentic though, there's been an update since I posted my thread. I'll check tomorrow evening.
Looks like people are having issues with authentic theme, since I only encounter White screen on CSF, I just open it up on a new tab and authentic theme was not loaded. Set the things I need to modify and go on.
I adjusted the memory on my test server to 2GB and the white screen problem disappear, this is for the authentic theme before the current update and with the current update. (i just restored from snapshots to test the difference)
Visit me at coderinthebox.com
By the way, everybody who has a server with SSD -- did you verify it's really SSD?
If the server is physically in your custody, then you know. If it's in a "cloud" somewhere (whatever that means), you're taking somebody else's word for it.
I just base it from read and write speeds. If doing a block write takes more than 5x faster in comparison to a physical HDD, I rule out that the VPS is on SSD. It is hard to be 100% accurate if you are on a VPS since things are abstracted and you can't see the real hardware. It is also much complex and impossible to know on "cloud" VPS since you server can exist in more than 1 physical server.
Visit me at coderinthebox.com
You have to be careful with testing block write speeds. The first few blocks will go into cache. So if you just do a quick test with dd (e.g., dd if=/dev/zero of=somefile) it might mean nothing.
If you're using one of the standard benchmarks like dbench, fio, bonnie++, etc., that might mean something. But there again, hybrid systems, that contain some SSD cache but mostly non-SSD disk, might perform just as well as SSD alone, to an extent.
So rather than basing any conclusions on what your cloud provider claims, I would base them on observed I/O performance.