Facebook
Twitter-
We value your experience with Plesk during 2024
Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
Please take this short survey:
https://pt-research.typeform.com/to/AmZvSXkx -
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.
-
We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.
Vote Please share your opinion about Plesk PHP packages
- Thread starter IgorG
- Start date
Elompenta
Regular Pleskian
I love it!
But please fix his issue: http://talk.plesk.com/threads/12-5-x-zendguard-and-ioncube-fails.335752/
But please fix his issue: http://talk.plesk.com/threads/12-5-x-zendguard-and-ioncube-fails.335752/
Thanks for your additional info on subject.
I know that use of cache should be supported in vBulletin (or whatever software there is, to be used). I may suggest adding support for Redis cache to DBTech, they may consider it and add it for they program DBOptimise.
@Alan_SP,
If you can start a personal conversation and mail me some of the optimization templates by DBTech, it can be the case that I can help you fairly easily with Redis.
However, I am not certain though.
In essence, there is a tiny loop hole to configure php to use Redis partially (!), since some of the older versions seem to able to engage with Redis with the memcached module.
The above implies that a vBulletin, set up properly for using Memcache daemon (i.e. Memcached), can use Redis Cache (instead of Memcached), without big modifications.
This loop hole can only be of value, if the DBTech optimization templates are defined in an efficient and/or a proper fashion.
Let´s try it.....shall we?
Please note that the above mentioned approach will not allow usage of all excellent Redis features, but it will allow for the lightening speed of Redis.
Regards......
If you can start a personal conversation and mail me some of the optimization templates by DBTech, it can be the case that I can help you fairly easily with Redis.
However, I am not certain though.
In essence, there is a tiny loop hole to configure php to use Redis partially (!), since some of the older versions seem to able to engage with Redis with the memcached module.
The above implies that a vBulletin, set up properly for using Memcache daemon (i.e. Memcached), can use Redis Cache (instead of Memcached), without big modifications.
This loop hole can only be of value, if the DBTech optimization templates are defined in an efficient and/or a proper fashion.
Let´s try it.....shall we?
Please note that the above mentioned approach will not allow usage of all excellent Redis features, but it will allow for the lightening speed of Redis.
Regards......
Here is the link to DBTech's vBOptimise: http://www.dragonbyte-tech.com/product/1-vb-optimise/
You can always download free version (I think you only need to register to be able to download). I don't know how they programed it, but I think they usually try to use correct code as much as possible.
You can always download free version (I think you only need to register to be able to download). I don't know how they programed it, but I think they usually try to use correct code as much as possible.
@Alan_SP,
I am not going to downlaod the package, for many reasons.
In general, Redis is a tough cookie (i.e. one cannot suffice with the normal get/set code sets) and there are many attempts to create a set of appropriate Redis code.
There is no common approach and that is not surprising: each application should have has own set of code, aligned with the nature and core code of the application.
However, when "projecting" common Memcached code, it often can apply to Redis related code, with one main advantage: speed with values to 512MB (memcached values are 1MB).
Pointing Memcached related code to a Redis server often does the trick, you could try that yourself!
Regards.....
I am not going to downlaod the package, for many reasons.
In general, Redis is a tough cookie (i.e. one cannot suffice with the normal get/set code sets) and there are many attempts to create a set of appropriate Redis code.
There is no common approach and that is not surprising: each application should have has own set of code, aligned with the nature and core code of the application.
However, when "projecting" common Memcached code, it often can apply to Redis related code, with one main advantage: speed with values to 512MB (memcached values are 1MB).
Pointing Memcached related code to a Redis server often does the trick, you could try that yourself!
Regards.....
No problem.
I have one problem with xcache, I see this error:
SAPI Compatibility Error PHP_FCGI_CHILDREN<1 PHP_FCGI_CHILDREN should be >= 1 and use 1 group of parent/childs model. See http://xcache.lighttpd.net/wiki/Faq
How and where I set PHP_FCGI_CHILDREN, so xcache works faster in Plesk?
I have one problem with xcache, I see this error:
SAPI Compatibility Error PHP_FCGI_CHILDREN<1 PHP_FCGI_CHILDREN should be >= 1 and use 1 group of parent/childs model. See http://xcache.lighttpd.net/wiki/Faq
How and where I set PHP_FCGI_CHILDREN, so xcache works faster in Plesk?
@Alan_SP,
"That setting should be in php.ini." EDIT: My bad, should be something else (and not php.ini), depending on the setup. Too much work, too many projects, a little bit of sleep. Apologies.
One question though: are you now running Apache + NGINX and, in addition, lighttpd?.
That is a terrible trade-off of cache and performance. In general, lighttpd is not a good idea....
Regards....
"That setting should be in php.ini." EDIT: My bad, should be something else (and not php.ini), depending on the setup. Too much work, too many projects, a little bit of sleep. Apologies.
One question though: are you now running Apache + NGINX and, in addition, lighttpd?.
That is a terrible trade-off of cache and performance. In general, lighttpd is not a good idea....
Regards....
Last edited:
No, at the moment I'm still only on Apache and Plesk PHP 5.3 (older version of vB, it waits till I update it to latest vB4.2.4 which is still in beta).
But, this problem with PHP_FCGI_CHILDREN, please found where and how to set it up in Plesk. It seems that it affects all opcode cachers, not just xcache. Or it can't be used with fast cgi? https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Here it says:
But, this problem with PHP_FCGI_CHILDREN, please found where and how to set it up in Plesk. It seems that it affects all opcode cachers, not just xcache. Or it can't be used with fast cgi? https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
Here it says:
Jose_Antonio_Morales
New Pleskian
I´ve always used original php from vendors and some other rpm packages for many years... But last year came with the need to have several php packages for different subscriptions that needed a different specific version. I solved this using atomic packages. It was a blessing that the Odin team decided to package some of the main PHP versions... Now I still use both Odin and atomic versions... But so far Odin packages make the trick and are working good with several joomla versions ranging from the 1.5 versions ( very old and needs php 5.2) to the latest joomla ( using newer php versions )
Nginx was something i used about a year before the plesk inclusion... I think that the Fast CGI versions + Apache + Nginx + some tuning... gives a BIG BOOST on the overall response using really low resources... Thanks for the hard work Odin Team!
Nginx was something i used about a year before the plesk inclusion... I think that the Fast CGI versions + Apache + Nginx + some tuning... gives a BIG BOOST on the overall response using really low resources... Thanks for the hard work Odin Team!
The plesk-php56-devel seems outdated and is not installable:
Please fix this issue.
Code:
Error: Package: plesk-php56-devel-5.6.14-centos7.15102115.x86_64 (plesk-php-5.6)
Requires: plesk-php56 = 5.6.14-centos7.15102115
Installed: plesk-php56-5.6.15-centos7.15111714.x86_64 (@PHP_5_6_15-dist)
plesk-php56 = 5.6.15-centos7.15111714
Available: plesk-php56-5.6.14-centos7.15102115.x86_64 (plesk-php-5.6)
plesk-php56 = 5.6.14-centos7.15102115
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigestPlease fix this issue.
StayAllive
Basic Pleskian
It would be really nice to have a fast addition of the PHP 7 stable build 
Just wait MU#14 a little bitIt would be really nice to have a fast addition of the PHP 7 stable build
StayAllive
Basic Pleskian
Thomas Poisl
Basic Pleskian
After installing PHP7 on monday I found all my domains showing a 502 nginx error today evening around 1:40 am.
There was a problem related with the mod_security module. Deactivating, uninstalling and reinstalling did the job for now.
Details, also from other users with similar problems can be found here: http://talk.plesk.com/threads/modsecurity-fails-on-plesk-12-0-18-update-71.336166/
There was a problem related with the mod_security module. Deactivating, uninstalling and reinstalling did the job for now.
Details, also from other users with similar problems can be found here: http://talk.plesk.com/threads/modsecurity-fails-on-plesk-12-0-18-update-71.336166/
Support of different php Versions "out of the Box" is essential for us and helps a lot - thanks for implementing. It is allways a mess with a shared Webserver and within running a lot of Domains, some of the Users never touch there installation and other would like to have always the bleeding edge....
