Hi,
I am about to try to figure out how to do sticky load-balancing for multiple Seaside instances using Nginx (I know how to do it using Apache). I currently have this working: upstream t3-mobile { server localhost:9090; # server localhost:9091; # server localhost:9092; # server localhost:9093; } server { listen 443 ssl; location / { proxy_pass http://t3-mobile; } } I just have to get the stickiness in. There seems to be a difference in available options between the open source and commercial versions. Any experiences, recommendations, pointers ? TIA, Sven_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hey Sven,
We use session affinity based on the seaside session parameter. I think you will find what you need in this article: http://johanbrichau.blogspot.be/2012/05/when-to-use-http-session-affinity-in.html There are other nginx modules to achieve session affinity based on another parameter too, but I do not remember what they were. regards, Johan On 26 Mar 2014, at 12:08, Sven Van Caekenberghe <[hidden email]> wrote: > Hi, > > I am about to try to figure out how to do sticky load-balancing for multiple Seaside instances using Nginx (I know how to do it using Apache). > > I currently have this working: > > upstream t3-mobile { > server localhost:9090; > # server localhost:9091; > # server localhost:9092; > # server localhost:9093; > } > > server { > listen 443 ssl; > > location / { > proxy_pass http://t3-mobile; > } > } > > I just have to get the stickiness in. There seems to be a difference in available options between the open source and commercial versions. > > Any experiences, recommendations, pointers ? > > TIA, > > Sven_______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Thanks Johan, that was interesting.
I am still reading other documentation. On 26 Mar 2014, at 12:13, Johan Brichau <[hidden email]> wrote: > Hey Sven, > > We use session affinity based on the seaside session parameter. > I think you will find what you need in this article: > > http://johanbrichau.blogspot.be/2012/05/when-to-use-http-session-affinity-in.html > > There are other nginx modules to achieve session affinity based on another parameter too, but I do not remember what they were. > > regards, > Johan > > On 26 Mar 2014, at 12:08, Sven Van Caekenberghe <[hidden email]> wrote: > >> Hi, >> >> I am about to try to figure out how to do sticky load-balancing for multiple Seaside instances using Nginx (I know how to do it using Apache). >> >> I currently have this working: >> >> upstream t3-mobile { >> server localhost:9090; >> # server localhost:9091; >> # server localhost:9092; >> # server localhost:9093; >> } >> >> server { >> listen 443 ssl; >> >> location / { >> proxy_pass http://t3-mobile; >> } >> } >> >> I just have to get the stickiness in. There seems to be a difference in available options between the open source and commercial versions. >> >> Any experiences, recommendations, pointers ? >> >> TIA, >> >> Sven_______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi,
I want to share the nginx configuration I am currently using and that seems to work fine: === upstream t3-mobile { ip_hash; server localhost:9090; server localhost:9091; } server { listen 443 ssl; server_name XXX; ssl_certificate /home/ubuntu/t3-mobile/XXX.chained.cert; ssl_certificate_key /home/ubuntu/t3-mobile/XXX.key; location /files { alias /home/ubuntu/t3-mobile/static-files; try_files $uri @seaside; gzip on; gzip_types application/x-javascript text/css; expires 30d; } location / { proxy_pass http://t3-mobile; add_header X-Server Pharo; } location @seaside { proxy_pass http://t3-mobile; add_header X-Server Pharo; } } === I any case, it gives me an all A score on YSlow (except for the CDN usage). I deploy my static resources from FileLibraries to the filesytem. I share some session state in a memcached instance, mainly for recovering expired sessions. The web app accesses a large REST based system, so does not do its own persistency. I am happy - thanks for keeping Seaside alive ! Sven On 26 Mar 2014, at 15:10, Sven Van Caekenberghe <[hidden email]> wrote: > Thanks Johan, that was interesting. > I am still reading other documentation. > > On 26 Mar 2014, at 12:13, Johan Brichau <[hidden email]> wrote: > >> Hey Sven, >> >> We use session affinity based on the seaside session parameter. >> I think you will find what you need in this article: >> >> http://johanbrichau.blogspot.be/2012/05/when-to-use-http-session-affinity-in.html >> >> There are other nginx modules to achieve session affinity based on another parameter too, but I do not remember what they were. >> >> regards, >> Johan >> >> On 26 Mar 2014, at 12:08, Sven Van Caekenberghe <[hidden email]> wrote: >> >>> Hi, >>> >>> I am about to try to figure out how to do sticky load-balancing for multiple Seaside instances using Nginx (I know how to do it using Apache). >>> >>> I currently have this working: >>> >>> upstream t3-mobile { >>> server localhost:9090; >>> # server localhost:9091; >>> # server localhost:9092; >>> # server localhost:9093; >>> } >>> >>> server { >>> listen 443 ssl; >>> >>> location / { >>> proxy_pass http://t3-mobile; >>> } >>> } >>> >>> I just have to get the stickiness in. There seems to be a difference in available options between the open source and commercial versions. >>> >>> Any experiences, recommendations, pointers ? >>> >>> TIA, >>> >>> Sven_______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Thank you for sharing this Sven.
Are you storing Seaside sessions in memcache? Regards! Esteban A. Maringolo 2014-04-24 9:53 GMT-03:00 Sven Van Caekenberghe <[hidden email]>: > Hi, > > I want to share the nginx configuration I am currently using and that seems to work fine: > > === > upstream t3-mobile { > ip_hash; > server localhost:9090; > server localhost:9091; > } > > server { > listen 443 ssl; > server_name XXX; > > ssl_certificate /home/ubuntu/t3-mobile/XXX.chained.cert; > ssl_certificate_key /home/ubuntu/t3-mobile/XXX.key; > > location /files { > alias /home/ubuntu/t3-mobile/static-files; > try_files $uri @seaside; > gzip on; > gzip_types application/x-javascript text/css; > expires 30d; > } > > location / { > proxy_pass http://t3-mobile; > add_header X-Server Pharo; > } > > location @seaside { > proxy_pass http://t3-mobile; > add_header X-Server Pharo; > } > } > === > > I any case, it gives me an all A score on YSlow (except for the CDN usage). > > I deploy my static resources from FileLibraries to the filesytem. > > I share some session state in a memcached instance, mainly for recovering expired sessions. > > The web app accesses a large REST based system, so does not do its own persistency. > > I am happy - thanks for keeping Seaside alive ! > > Sven > > On 26 Mar 2014, at 15:10, Sven Van Caekenberghe <[hidden email]> wrote: > >> Thanks Johan, that was interesting. >> I am still reading other documentation. >> >> On 26 Mar 2014, at 12:13, Johan Brichau <[hidden email]> wrote: >> >>> Hey Sven, >>> >>> We use session affinity based on the seaside session parameter. >>> I think you will find what you need in this article: >>> >>> http://johanbrichau.blogspot.be/2012/05/when-to-use-http-session-affinity-in.html >>> >>> There are other nginx modules to achieve session affinity based on another parameter too, but I do not remember what they were. >>> >>> regards, >>> Johan >>> >>> On 26 Mar 2014, at 12:08, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>>> Hi, >>>> >>>> I am about to try to figure out how to do sticky load-balancing for multiple Seaside instances using Nginx (I know how to do it using Apache). >>>> >>>> I currently have this working: >>>> >>>> upstream t3-mobile { >>>> server localhost:9090; >>>> # server localhost:9091; >>>> # server localhost:9092; >>>> # server localhost:9093; >>>> } >>>> >>>> server { >>>> listen 443 ssl; >>>> >>>> location / { >>>> proxy_pass http://t3-mobile; >>>> } >>>> } >>>> >>>> I just have to get the stickiness in. There seems to be a difference in available options between the open source and commercial versions. >>>> >>>> Any experiences, recommendations, pointers ? >>>> >>>> TIA, >>>> >>>> Sven_______________________________________________ >>>> seaside mailing list >>>> [hidden email] >>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >>> >>> _______________________________________________ >>> seaside mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
On 24 Apr 2014, at 16:31, Esteban A. Maringolo <[hidden email]> wrote: > Are you storing Seaside sessions in memcache? No, not as such. The ip_hash directive tells nginx to send all requests from the same IP to the same Seaside worker image, one way to implement sticky sessions. But of course, when one of the workers of the pool fails, either because of a crash or because of updates, requests will move (temporarily) to another worker. Then the user will lose its session. Users also lose sessions when they are timed out. To fix this, I implemented both http://book.seaside.st/book/in-action/session/recovering on some pages as well as an extra cookie (login-token) that remains valid for 14 days. It is that cookie that is stored in memcached and thus shared among workers (the user might move and get another IP). The cookie is used to recover the login and keep the illusion of maintaining the session (even though it actually changed from Seaside's perspective). The only disadvantage is that often the user will go back to the web page, click on something, and first get the page back (session/login recovery) and then has to click again to make the action work. I don't think there is a way around that unless you want to give up on Seaside's generated links. Sven_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Free forum by Nabble | Edit this page |