I wanted to start a discussion on the impact of being logged in as "admin" and engaging in activities such as editing panels, creating views, and generally modifying a production site. It is easy to forget the memory demands this places on an operational server. Worse, I find myself often logged in from multiple Chrome windows while also logging in from Firefox and IE, all as admin.
Can someone help enlighten the group on the RAM impact of being logged in as admin in multiple Chrome browser windows, plus Firefox at the same time, all the while making significant site design changes?
Sometimes I find myself confused as to the spike in RAM demand, then I remember that all these "agent Smith's" need their mem space.
Just a small point but one that I keep forgetting to consider when I am tuning things like httpd.conf in my Centos machine.
Comments
It would depend on the number
It would depend on the number of page requests going from your logged in adminsitrators. If all of these are just logged in an waiting for some user input before peroforming some administrative action they really do not contribute to server load until they send in the next GET or POST back to the server. Having several pages opened at the same time shouldn't cause a huge load unless you opened all of them in one go.
I also do not think that administrative users are going to take up massively different amounts of memory for their page requests as compared to a logged in regular user on the site. It is true that some of the administrative requests are server intensive and sometimes memory intensive as well but there shouldn't be huge differences on the memory side.
What kind of memory sizes are we talking about here on your server?
Check out our Free Drupal site review
I'm curious as to the amount
I'm curious as to the amount of RAM an apache server instance consumes when the logged in users are multiple admins rather than authenticated users.
I have noticed my lightly loaded test server enter into a swap state with 2GB of RAM with just me logged in and conducting various admin design activities such as editing a view, creating a panel, modifying a content type, running through various menu functions from a few chrome windows plus a few firefox windows. I have seen this happen with the httpd.conf file set to prefork MPM with:
StartServers 3
MinSpareServers 2
MaxSpareServers 3
ServerLimit 6
MaxClients 6
With no other purpose for the server than to run a LAMP/Drupal site, it seems that I can consume 2GB of RAM pretty easily.
By the way, I assume the above settings are very low for a 2GB LAMP server running Drupal? comments welcome.
../
../
This can happen if your 2GB
This can happen if your 2GB of RAM are taken up by something. Like, caches, or memory leaks, etc. You need view the server memory usage, even with htop - that should tell you, what processes are there and what eats your memory.
Remember HTTP is stateless.
Remember HTTP is stateless. You can have 1 admin window open or 1,000. The number of windows won't affect the memory usage, unless you got every window requesting their pages at the same time.
Changing panels and views does have performance impacts though. The memory usage doesn't come from just using their UI's, but also the caches that can be cleared during it. Some of those you won't rebuild on the UI page, but rather would be rebuilt on requests to the affected pages.
For production sites, the best practice (though not always the most practical) is to change things like panels, views and anything else intensive on a staging site then move them into the production site either using export/import or through features. This becomes even more important if you are running on a low memory server, because you can then disable the UI modules on the production site, saving even more ram (and cycles) on every page view, both for admin and not.
My general rule for client sites is to keep the UI's off and make changes that way, unless there is a compelling reason to keep the UIs on, like the client wants to change things on their own. Of course those are usually the more troublesome clients, because they think they are saving money making these changes on their own, then end up calling in a panic because they just broke their site.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Great tips
@alexrayu you are right about the memory allocation for caching. It it easy to forget that memcache and apc are consuming RAM. IN my case, 256 MB & 128 MB respectively.
@jamieHolly. Excellent points. The need to get the Admin UI off loaded to a staging server is becoming clear to me now. I have not been using the Features module but I need to start asap.
As for HTTP beign stateless, this is less and less clear with cookies, etc, but the real "stateless killer" is, as you rightly point out, the admin user changing panels, views etc during an "admin session".