search

tatsuhiro-t / spdylay

The experimental SPDY protocol version 2, 3 and 3.1 implementation in C
http://tatsuhiro-t.github.io/spdylay/
MIT License
602 stars 103 forks source link

Multi-core configuration #40

Closed peteroconnor closed 12 years ago

peteroconnor commented 12 years ago

I am playing around shrpx. It works great, btw.

One of the config option is the number of the workers. I assume the master thread will create the specified number of workers, trying to situate each worker on a different core of cpu. The master thread then will distribute the traffic to each worker, in a "sticky" way of loan-balancing. Is that correct?

Some back-end servers do multi-threading in a similar way -- it seems to be a popular way these days. Each thread will listen on a dedicated port , e.g. Foreman, Squid.

It looks natural to align the shrpx's workers and the back-end server's workers, in order to avoid an additional dispatcher (in front of back-end servers).

Do you have suggestions on this?

tatsuhiro-t commented 12 years ago

The master thread then will distribute the traffic to each worker, in a "sticky" way of loan-balancing. Is that correct?

Yes. Currently, the balancing strategy is not smart; just a round robin.

Some back-end servers do multi-threading in a similar way -- it seems to be a popular way these days. Each thread will listen on a dedicated port , e.g. Foreman, Squid.

It looks natural to align the shrpx's workers and the back-end server's workers, in order to avoid an additional dispatcher (in front of back-end servers).

Are you suggesting that remove the master thread dispatcher and make shrpx listen on dedicated ports for each thread? I think it requires another front end program to distribute load to each shrpx thread, is that correct?

I first considered the similar way you described. But my version is multiple process listening the same port (e.g., stud). Listening on each thread may simplify the code a bit. I don't know which is more robust and scalable. Since most CPU intensive job is SSL/TLS encryption/decryption part, I think dispatching is not a major bottleneck.

peteroconnor commented 12 years ago

Are you suggesting that remove the master thread dispatcher and make shrpx listen on dedicated ports for each thread? I think it requires another front end program to distribute load to each shrpx thread, is that correct?

shrpx has a dispatcher, and the back-end server has another dispatcher. There may be a way to save the second dispatcher.

However, if there is no "sticky" session feature on shrpx, then the second dispatcher still serves some important functions. It is better to keep shrpx the current way and only do the heavy lifting in a stateless way.

tatsuhiro-t commented 12 years ago

shrpx has a dispatcher, and the back-end server has another dispatcher. There may be a way to save the second dispatcher.

Ah, I think I see your point. Your idea is that shrpx worker directly communicate to the back-end server worker, right?

However, if there is no "sticky" session feature on shrpx, then the second dispatcher still serves some important functions. It is better to keep shrpx the current way and only do the heavy lifting in a stateless way.

If "sticky" means something like cookie bound session, shrpx does not support it and just forwards to the back-end server by terminating SPDY. We agreed that keep shrpx the current form.