Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6
Hi Dirk, I would not recommend the OXID eShop application database for storing sessions in high load scenarios as well. Thats the reason why we decided to recommend other solutions like Memcached or Redis. But there can be reasons to tie other session storages to OXID eShop. Even a separate MySQL database should perform well, if you use a primary key for data access. Regards Gregor Von: dev-general-boun...@lists.oxidforge.org [dev-general-boun...@lists.oxidforge.org]" im Auftrag von "Uwe Degenhardt [degenha...@sdsolutions.de] Gesendet: Mittwoch, 17. August 2016 22:18 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6 Von: Dirk Ollmetzer<mailto:dirk.ollmet...@ollmetzer.com> Gesendet: 17.08.2016 21:47 An: dev-general@lists.oxidforge.org<mailto:dev-general@lists.oxidforge.org> Betreff: Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6 Hi Marco, I would not recommend to use the normal database for session storing - particularly not in high load scenarios, because DB load is already a serious bottleneck then. Storing the Session Data in Memcache was a solid, reliable and scalable solution in a setup, I had to manage some years ago, like it is mentioned in the article. But nonetheless, thanks for the info. Regards, Dirk Am 17.08.2016 um 14:18 schrieb Marco Steinhaeuser: > Hey folks, > > if you run high load scenarios with multiple application servers, this > blog post might be interesting for you, as there will be changes in > session handling in OXID eShop 6. > > Until now, we used the regular PHP session handling and optionally, > centralized session storage for high load scenarios. In this blog post, > Gregor shows up clever alternatives and how to write an own session > handler if you want to use a database for session storage anyway: > http://oxidforge.org/en/session-handling-with-oxid-eshop-6-0.html > > Regards > > Marco > > ___ > dev-general mailing list > dev-general@lists.oxidforge.org > http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6
- Ursprüngliche Nachricht - Von: "Dirk Ollmetzer" Gesendet: 17.08.2016 21:47 An: "dev-general@lists.oxidforge.org" Betreff: Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6 Hi Marco, I would not recommend to use the normal database for session storing - particularly not in high load scenarios, because DB load is already a serious bottleneck then. Storing the Session Data in Memcache was a solid, reliable and scalable solution in a setup, I had to manage some years ago, like it is mentioned in the article. But nonetheless, thanks for the info. Regards, Dirk Am 17.08.2016 um 14:18 schrieb Marco Steinhaeuser: > Hey folks, > > if you run high load scenarios with multiple application servers, this > blog post might be interesting for you, as there will be changes in > session handling in OXID eShop 6. > > Until now, we used the regular PHP session handling and optionally, > centralized session storage for high load scenarios. In this blog post, > Gregor shows up clever alternatives and how to write an own session > handler if you want to use a database for session storage anyway: > http://oxidforge.org/en/session-handling-with-oxid-eshop-6-0.html > > Regards > > Marco > > ___ > dev-general mailing list > dev-general@lists.oxidforge.org > http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Blog post: session handling in OXID eShop 6
Hi Marco, I would not recommend to use the normal database for session storing - particularly not in high load scenarios, because DB load is already a serious bottleneck then. Storing the Session Data in Memcache was a solid, reliable and scalable solution in a setup, I had to manage some years ago, like it is mentioned in the article. But nonetheless, thanks for the info. Regards, Dirk Am 17.08.2016 um 14:18 schrieb Marco Steinhaeuser: Hey folks, if you run high load scenarios with multiple application servers, this blog post might be interesting for you, as there will be changes in session handling in OXID eShop 6. Until now, we used the regular PHP session handling and optionally, centralized session storage for high load scenarios. In this blog post, Gregor shows up clever alternatives and how to write an own session handler if you want to use a database for session storage anyway: http://oxidforge.org/en/session-handling-with-oxid-eshop-6-0.html Regards Marco ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
