-
Notifications
You must be signed in to change notification settings - Fork 86
EZP-25972: Clustering guide improvement #428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
docs/guide/clustering.md
Outdated
|
||
!!! note | ||
|
||
To use Memcached, you need to set `cache_service_name` to `cache.memcached`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me it's not an additional information but a step that must be taken so I would move it into the core text.
docs/guide/clustering.md
Outdated
- active/passive database for failover | ||
- more recent versions of PHP and MySQL/MariaDB within [what is supported](../getting_started/requirements.md) for your eZ Platform version to get more performance out of each server. Numbers might vary so make sure to test this when upgrading. | ||
For a [cluster](clustering.md) setup you need to configure sessions to use a back end that is shared between web servers and supports locking. | ||
The only options out of the box supporting this in Symfony are the native PHP Memcached session save handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only out of the box options supporting
docs/guide/clustering.md
Outdated
### Shared binary files | ||
|
||
eZ Platform supports multi-server setups by means of [custom IO handlers](file_management#the-dfs-cluster-handler). | ||
They make sure that files are correctly synchronized among the multiple clients that might use the data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
among the multiple clients using data.
- a CDN for improved performance and faster ping time worldwide | ||
- active/passive database for failover | ||
- more recent versions of PHP and MySQL/MariaDB within [what is supported](../getting_started/requirements.md) for your eZ Platform version to get more performance out of each server. Numbers might vary so make sure to test this when upgrading. | ||
For a [cluster](clustering.md) setup you need to configure sessions to use a back end that is shared between web servers and supports locking. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.. , alternatively usage of a load balancer that supports session affinity ("sticky sessions") so a user is served by single server once he gets a session.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we move memcache config over to Clustering doc, when we recommend Redis for use as cache in other parts of the doc?
Also, php-redis is about to get support for session locking in upcomming 4.2, so I think we can update the section about us recommending memcached for sessions (which contradicts our cache recommendation and our default p.sh config). But maybe we'll need to send that via Eng or at least QA to verify that.
Moving the Memcached section was recommended in ticket description by @bdunogier, but I guess the ticket is a bit aged by now... |
Yes, starting with 2.0 we recommend Redis as performance on memcache was terrible (In one extreme case I saw 0,5s vs 22s to load frontpage). That should have been fixed now in Symfony v3.4.15 and up, but we have not verified the fix yet. |
Could we put this on hold until #418 is in? They overlap each other quite a bit. |
Closing in favor of #443 (too many conflicts) |
Reorganizes sections as suggested in ticket description.