• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
    To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Resolved The new function Dedicated FPM application served by Apache

We've turned this on for higher tier customers and definitely significant boost in speed as they're not waiting for free workers but its also jacked up short term average CPU utilisation by 20-30% because more peak CPU is available to be used.
 
@ghazestor We did not experience any increased CPU total usage. Based on your settings the free workers are not the ones to blame. The speed increase comes from the dedicated master processes per website having their own OPcache. This can improve PHP performance dramatically by storing precompiled script bytecode in shared memory for the PHP handler. This removes the need for PHP to load and parse scripts on each request. This normally even brings CPU usage down. Of course you pay a price for that: the memory usage increases based on the settings for [opcache] in the php.ini. The shared FPM application handler on the other side never has really a chance to cache PHP scripts very long as the different websites kick each other out of the cache again and again - at least with the standard [opcache] settings in Plesk. Furthermore the PHP function opcache_get_status has to be disabled for obvious security reasons.
 
Back
Top