Re: Meeting notes

Alex Russell <[email protected]> Fri, 26 Mar 2004 11:55:47 -0800
Newsgroups gmane.comp.web.mod-pubsub.devel
Organization netWindows.org
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 March 2004 10:44 am, Joyce Park wrote:
> Hey guys,
>
> So we had a fabulous meeting Wednesday night, mostly focused on
> server improvements.  My notes are appended.  Old Mod-pubsubbers
> also had a chance to meet the fresh blood, Alex and Vishy and
> Henry, who are pushing the effort on behalf of Friendster.

It was really neat to meet everyone. I (for one) and very excited 
about the possiblity of getting modpubsub to be scalable enough to 
handle some of the loads we are discussing.

[snip]

> Performance
>   --memory
>   --long queues (delivery bug)
>   --select()

So to outline this problem a little bit more for the list, the 
traditional select() and poll() mechanisms available on POSIX systems 
require a main-loop iteration over a list of open file descriptors to 
determine if an action needs to happen for a given file descirptor. 
When that list becomes very long, that traversal becomes increasingly 
expensive, chewing up lots of CPU time that we (as app programmers) 
would like to be using to actually _do_ something.

Given that clients of modpubsub protocol servers generally require 
long-lived connections in order to acheive low-latency, modpubsub 
essentially forces worst-case behavior of select() and poll(). 
Fortunantly, OS manufacturers have recently come to our rescue with 
kqueue/kevent (FreeBSD and OS X) and epoll (Linux 2.6). These 
event-driven file descriptor change notification syscalls allow app 
programmers to register callbacks which are called when something 
happens, so apps can spend less time figuring out if they need to do 
something, and more time actually _doing_ things. This asynchronous 
approach is how we intend to get modpubsub servers supporting 10K 
concurrent clients. This also dove-tails into using the Twisted async 
framework for the Python server nicely.

>   --old event initial route population has a long pause
>   --HTTP 1.1

HTTP 1.1 will buy us chunking and reusable connections. These are both 
Good Things (TM).

>   --robust (lazy expiration)
>   --topics never die
>   --overhead for reaping
>
> Security
>   --SSL

It was noted that in REALLY BIG installations, SSL is still expensive, 
but might allow moderately sized sites/apps to allow HTTP 1.1 through 
proxies.

>   --authentication
>   --security

Security requirements seem to be one of the largest areas for 
improvement. It was decided that authentication and authorization 
shouldn't be handled in the server deamon itself, but rather that the 
server should expose sane "hooks" or proxy-points to allow an 
external security monitor service to give the thumbs up or down to a 
message. The discussion about Unix Domain Sockets sprung out of this 
approach to security, sinc we'll need REALLY fast IPC to get this 
working well.

>   --do_method=batch loses errors, error handling unspecified
>   --sequencing (events have to be delivered in order)
>   --auth/auth policy callbacks or hooks
>   --e.g. unix-domain-sockets

This point refers to a concept of talking the modpubsub HTTP protocol 
over a UDS and that a security monitor could then insert itself into 
the processing stream via this connection.

>   --disable introspection
>
> Latency
>
> Scalability
>   --10K connections/box

With fewer connections than this supported by a single server, the 
communications overhead for replication and failover looks to become 
overwhelming.

> Failover
>   --topic-based expiration policy

Since topics are events, events can expire their sub-events, and 
therefore topics can enforce sub-topic expiration. This seemed an 
elegant way of dealing with te reaping problem, but we don't have any 
experience with this in the wild. Time will tell if this design 
works.

>   --weak ref topic for route dest
>   --lease-extension for expiring objects

Topic creation events for existing topics will re-set their 
time-to-expire timestamps and then be dropped. This seems a good way 
to allow applications to do topic "keepalive".

I'm sure others will have better clarifications.

Regards

- -- 
Alex Russell
[email protected]   BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
[email protected] F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAZIrGoV0dQ6uSmkYRApRkAJ9+1Ls9Ztq7I18VtZweJKC6aQUFYACfetys
jYJPq7Pj20zX4drsSbKsD/0=
=G/6h
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click