On March 28th, 2018 at approximately 1:30 pm CST the server housing the cPanel Feature Request site’s hypervisor unexpectedly failed.
This failure resulted in the loss of data back to September of 2017. Read more in our announcement.
 

Zend Opcache User Interface for WHM / cPanel - (with separate cache's for each cpanel account)

Greg shared this idea 2 years ago
Open Discussion

The additon of a Zend Opcache GUI into both WHM and indivudal cPanel accounts would be a great new feature for users.


The ability to set up separate caches for each account (Currently it seems like all accounts share the same cache which is not great if you want to keep your accounts and cache's isolated from eachother)


The GUI should allow both the WHM root user (or reseller) to change the master settings for the cache such as Max Memory, files, and the option to clear all or individual caches.


The cPanel account should also get an opcache GUI this would allow customers / account holders to manage their individual opcaches, for example flushing the cache, excluding files etc.


this would give all users (novice to pro's) an easy and excellent way to control their opcache without having to use CLI or any 3rd party scripts that you need to place in your public_html folder on a domain.


The GUI should have things like simpel to use "Flush Cache" buttons and an editor to change the opcache settings. (this is a must now that opcache settings can be defined per FPM pool etc.


It should also show cache statuses respectively in WHM and cPanel with easy editing for example


  • Total Mem
  • Used mem
  • free mem
  • wasted mem
  • cached files
  • cache hits
  • cache misses
  • cached keys
  • max cached keys
  • etc

Comments (5)

photo
2

After talking with the product owner for EasyApache it looks like this is going to be incredibly difficult and development-time intensive to accomplish, and would likely require either cagefs or chroot. I've opened this one up for discussion, though, because I'm very interested to see discussion and interest in here.

photo
1

To help paint the picture for others, my recommendation would be something like this github script


https://github.com/amnuts/opcache-gui


/687474703a2f2f616d6e7574732e636f6d2f696d616765732f6f7063616368652f73637265656e73686f742f6f766572766965772d76322e312e312e706e67


Except instead of being manually installed per domain, it could be controlled with a Master interface from WHM and give individual interfaces and controls to individual cpanel users. This would build into the private cache functionality so that cPanel user 1 cannot see cPanel user 2's cached files etc but would also give each user control of their own cache, things to include or exclude, flushing cache etc. and would also give the WHM user (root) full overall control, so they could flush all or one cache, view whats being cached etc even enable disable on a server wide basis


This would add a whole lot of security over the stand-alone scripts like the one above.


Anyway hopefully people will see the benefits here and start contributing

photo
2

To achieve seperate oopcode cache I dont think cagefs is required just multiple phpfpm instances instead of multiple pools ( one config file, and 1 systemd file per user). It requires more memory but works well. If you are prepared to pay, Litespeed can be confured to do this nativly.

photo
4

As an admin, I'd be happy if I could easily configure and manage the cache globally. Being able to have seperate caches per account would be awesome, but I can see how it would get complicated fast. So, as an initial milestone, a decent opcache admin interface for the admin user is what I'd go for.

photo
1

Just checking for an update.


Separate caches per user are essential for servers with multiple accounts. The problem I face is I cannot allow my users to create a new domain/sub-domain with php-fpm or change php version during the day time busy hours because doing so dumps the cache for everyone which then creates a huge amount of server load when the server is busy as the opcache regenerates (cache slam). Per user master processes would allow this not to happen, isolating each user's cache and only dump their specific portion when it needs to.


One thing that maybe could be done in the current implementation to at least help when people are changing their PHP versions for an existing domain/sub-domain... Before php-fpm was in it's current implementation, we had to manually implement it and there were separate userdata conf files per version of PHP. I used to load all the user's fpm userdata conf files into all versions of php, but of course only point to one php version for apache to use. What this allowed was I could swap a user's php version then rebuild/restart apache only and it would work fine without dumping any existing php opcaches since the user's php-fpm conf were already loaded in each version of php. So it alleviated some of the issue. With the current configuration it appears there's only one set of php-fpm.yaml / php-fpm.cache per a user's domains. Is it possible to set them to load into all versions of PHP installed and not do a rebuild of the PHP-FPM config every time a PHP version for a domain/sub-domain is changed? It doesn't solve all my issues but it would at least help in that one area. You could even pre-load the user's php-fpm conf files before they are set to use PHP-FPM, so same as PHP version changes, one could enable / disable PHP-FPM and it would only rebuild/restart apache and not touch the opcache.


Otherwise it's still best to move towards a separate set of php master processes/cache per user as an advanced option.