5 ms·

I haven't done any real dev with those frameworks you list so I'm wondering how do you manage session state? user profile, shopping cart, breadcrumbs, multi-re

by modoc 17y ago

I haven't done any real dev with those frameworks you list so I'm wondering how do you manage session state? user profile, shopping cart, breadcrumbs, multi-request flows, etc... Do you write/read all that into the db/memcached for each request?

jshen 17y ago
typically your session data is stored outside of the web app process. It could be in files, memcached, db, cookies, etc.
mcav 17y ago
Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.
- ilyak 17y ago
  ...while reducing perfomance...
  - mcav 17y ago
    Yeah. Sometimes per-request page performance is less important than overall throughput, though.
- modoc 17y ago
  PHP has session variables to put state objects into which are persisted between requests. Right?
  - mcav 17y ago
    PHP's sessions are stored in files by default, not persisted in memory.
  - simonw 17y ago
    Yes, but most people who make serious use of them hook up a custom session handler that writes session information out to the database (the default implementation that ships with PHP uses the file system). Sessions that are stored in memory by the application server instantly prevent you from load balancing requests across multiple servers and hence kill your scalability - unless you implement sticky sessions which adds yet more complexity. Personally I try to avoid using session storage whenever possible - I've recently started using signed cookies in their place.
    - modoc 17y ago
      Interesting. I mostly build J2EE apps and sticky sessions support is built in. Complex apps require a fair bit of session state (user profile, shopping cart, custom catalog, breadcrumbs, user promos, etc...) in general and the idea of having to persist and reload that data over a network (db or memcached) for each request would absolutely kill page response times. I guess it depends on how heavy the session data is for your app.
      - jshen 17y ago
        how long do you believe it takes to grab data out of memcached? I'll bet it's a lot faster than you think. Of course, if you keep that state in memory then you are fucked when you need more than one web app server to handle the load.
      - modoc 17y ago
        jshen: sticky sessions make it a non-issue. Sites I work on run on 3-100 server clusters with each server handling a few thousand active sessions. I know memcached is very fast. However it's at least an order of magnitude, or more, slower than in memory lookups. Given how simple sticky sessions are I guess I'm not sure why you'd want to incur the overhead of re-buildling your state via external network calls and object serialization/marshalling/etc... for every request, and doing it all backwards at the end of every request.
      - simonw 17y ago
        I'm quite surprised - I've never even considered building a stateful web app that doesn't talk to a database or caching layer at all for most requests. It's fascinating to me how different the approaches taken in the Java world are from the LAMP world I'm accustomed to.

by modoc 17y ago

jshen 17y ago

typically your session data is stored outside of the web app process. It could be in files, memcached, db, cookies, etc.

mcav 17y ago

Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.

ilyak 17y ago
...while reducing perfomance...
- mcav 17y ago
  Yeah. Sometimes per-request page performance is less important than overall throughput, though.
modoc 17y ago
PHP has session variables to put state objects into which are persisted between requests. Right?
- mcav 17y ago
  PHP's sessions are stored in files by default, not persisted in memory.
- simonw 17y ago
  Yes, but most people who make serious use of them hook up a custom session handler that writes session information out to the database (the default implementation that ships with PHP uses the file system). Sessions that are stored in memory by the application server instantly prevent you from load balancing requests across multiple servers and hence kill your scalability - unless you implement sticky sessions which adds yet more complexity. Personally I try to avoid using session storage whenever possible - I've recently started using signed cookies in their place.
  - modoc 17y ago
    Interesting. I mostly build J2EE apps and sticky sessions support is built in. Complex apps require a fair bit of session state (user profile, shopping cart, custom catalog, breadcrumbs, user promos, etc...) in general and the idea of having to persist and reload that data over a network (db or memcached) for each request would absolutely kill page response times. I guess it depends on how heavy the session data is for your app.
    - jshen 17y ago
      how long do you believe it takes to grab data out of memcached? I'll bet it's a lot faster than you think. Of course, if you keep that state in memory then you are fucked when you need more than one web app server to handle the load.
    - modoc 17y ago
      jshen: sticky sessions make it a non-issue. Sites I work on run on 3-100 server clusters with each server handling a few thousand active sessions. I know memcached is very fast. However it's at least an order of magnitude, or more, slower than in memory lookups. Given how simple sticky sessions are I guess I'm not sure why you'd want to incur the overhead of re-buildling your state via external network calls and object serialization/marshalling/etc... for every request, and doing it all backwards at the end of every request.
    - simonw 17y ago
      I'm quite surprised - I've never even considered building a stateful web app that doesn't talk to a database or caching layer at all for most requests. It's fascinating to me how different the approaches taken in the Java world are from the LAMP world I'm accustomed to.