> > > > In production code, if your really worried about efficency you'd take > the time, all three seconds of it, to add > > -define(LETTERS, > "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"). > > > at the top of the module if I understand you correctly.
Basically, but I would also use a tuple instead of a list to enable constant lookup time. > > This little corner of the attracted my attention because it's > something I initially did really badly - more worried about other things > - and started to wonder if there's an "optimal" length key vs cpu usage > to generate it. It also shows up in a lot of other places such as cookie > generation. I was thinking last night that it might be better to start > with a list length of 5 octets, then if a collision occurs try 6, then > 7, etc. This would keep the keys short, but if you've got images of > several KB flying around and all the overhead of HTTP 5 versus 10 or 20 > bytes is neither here nor there. I think that in generating keys, the lookup for collisions is much more expensive than adding a few more random bytes. I think the best approach would be to select a string length that's big enough so that the probability of collision is close to 0. > > Getting back on topic. Any reason you used mnesia:dirty_* functions? The reason is that I don't have to worry about consistency and the dirty_* functions have better performance because they don't do any locking. It's like using ets through the Mnesia interface, with the extra benefit of Mnesia indexes. > > It looks as if it should be able to handle cases and ifs without a > problem. I only mention this in that it seems that continations relies > on side effects and I've been meaning to see how Haskell handles this > with Monards and Arrows (not up on Haskell at all). I'm not up on Haskell either, but as I understand it you have to use monads in Haskell to force strict processing of code blocks in an otherwise purely lazy language. But Erlang is strict, not lazy, so why would you want to bother with isolating side effects? It would just create more confusion about how to use the language properly. > > Would it be possible to separate out the functional and non-functional > parts a-la OTP gen_* modules? Also, if the functional parts of the code > are seperated out then the state could be serialised and written to disk > after short timeout so as not to consume resources then brought back > when needed or deleted entirely after a longer timeout. Unrelated to > this, you could have multiple machines running with the sessions being > forward to the correct machine should a connection be made by the client > to a machine on which the session exists. > > The other thing I was think of was: Each process is for each component > instance, hence the max number of processes equals the max number of > session times the max number of components. Ignoring birth/death of > session and components. Anyone care to fill in some realistic numbers or > supply a better model? Why would you want to model each session component with a process? I think having a process per session is sufficient. That process would maintain the state for all its components between requests. > > Anyway, I'd be interested in seeing Erlyweb scale horizontally across > machines in a manner which minimises the use hardware such as external > load balances. Mnesia is location transparent and so is Erlang message passing. This allows you to write [Pid] = mnesia:read(cont, Id), Pid ! Msg without being concerned of where the Pid lives -- it could be either on a local or a remote node. This feature is one the best things about Erlang and why it makes writing distributed systems so easy. This means you won't need a sticky load balancer if you cluster your web servers and have them share the Mnesia schema. That said, having a sticky load balancer would reduce some of the backend chatter between servers but I can't say I know the cost/benefit ratio for this design. Yariv --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "erlyweb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/erlyweb?hl=en -~----------~----~----~----~------~----~------~--~---
