Re: CL Scaling for High Traffic Web Sites

On Apr 29, 5:34 am, "Alex Mizrahi" <udode...@xxxxxxxxxxxxxxxxxxxxx>
wrote:
(message (Hello 'bob)
(you :wrote :on '(28 Apr 2007 12:26:48 -0700))
(

b> 1) Scaling out: have a distributed in-memory cache (eg. memcached)
b> that sits between the app and the db.

personally i have no experience with building high traffic web sites yet,
but i strongly believe that it would be better to use in-memory simple
cache, like just some hash table.

recently there was a question on Y Combinator news: "What are the best
non-database solutions you've seen? What did Viaweb use?" -- http://news.ycombinator.com/comments?id=14605

Paul Graham replied: "Keep everything in memory in the usual sort of data
structures (e.g. hash tables). Save changes to disk, but never read from
disk except at startup." then he also made a note that it's was easy to
scale this solution to multiple servers simply partitioning servers among
clients.
Paul Graham seems to have experience with high-traffic web sites :)

memcached thing is actually PHP style -- PHP is very limited, so it needs an
external entity for caching.
with Common Lisp you can just use internal data structures for it, and you
can make it easily scalable w/o complex 'distibuted hash table' thing (that
introduces some overhead by the way) if you'll analyse your data processing.

b> I remember Marco Baringer mentioned in an old thread that he was going
b> to implement fast session serialization,
b> which could eventually lead to these things. Is it available in UCW
b> already? Is it done in other servers/frameworks?

most likely Marco Baringer was going to implement CONTIUNATION
serialization, that's kinda much more complex that session serialization if
you are not useing continuations.
are there really any problems with session serialization?

and actually i don't think there's really any need in session serialization.
simply do not keep anything important in the session. if you'll have a
hardware failure and sesssion will be lost, person using it will need to
re-login, for example. i don't think it's a big deal, web applications were
never meant to be anyhow reliable.. and actually do you really have hardware
failures each day, so it's an issue?

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")

Thanks for the reply! :)

I guess I could use sticky session on the load balancer. However,
there's still the problem with caching database queries in memory once
they grow too big for in-memory data structures and have to be stored
on disk constantly. Caching them in local hash tables would result in
a lot of duplications. This is a fairly common problem now a days.

There could be another solution, but I don't know if it would be an
overkill for web farms; We could use OS-level distributed shared
memory, such as in a beowulf cluster. So basically, each thread would
be locked onto its own CPU, while the user data can be shared among
the different machines transparently. From the outside it would
appear as a single multi-processor machine with a single memory
address space. DragonFly BSD has some features that makes it easy to
do this over a slow and loosely-connected ethernet (they aim to do
this efficiently over the internet in the future!). Theoretically,
right now you can run all the NetBSD ports on it, but I'm not sure how
well the SBCL threads work in this manner, or if it runs at all.

Cheers!

Bob

.