On Fri, Nov 7, 2008 at 12:35 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Ashish wrote: >> >> On Tue, Nov 4, 2008 at 10:33 PM, Emmanuel Lecharny <[EMAIL PROTECTED]>
>>>> >>>> Multiple places to implement SEDA (before ProtocolDecoder, before >>>> IoHandler) >>>> >>>> >>> >>> I would like to know if you are not ask risk to have a hell lot of thread >>> if >>> you do so. And I'm not sure that it has any added value, as the idea is >>> to >>> use a thread to handle a costly operation, no need to spawn a new thread >>> when it's already done... Am I missing something ? >>> >> >> Well we needed SEDA to attain a very high processing rate. > > But SEDA means that each stage is managing its tasks, communicating with the > other stages with queues. here, what you do is to multiplex the incoming > messages in one stage, then multiplexing again at the next stage, and so on. > What are the odds that the first multiplexing can't be enough ? Well from a Framework perspective, we needed to be able to cater to multitude of the solutions out there. My apology, can't use exact terms. Agree that there will be a situation where, first level of multiplexing can be enough, but we kept it flexible. Again our solution didn't dictated its term, but was designed to gel into existing solutions as much as possible. Yes we designed it in a way that each stage manages it own tasks. The design is more close to MINA filter chain. plugin IO filters and change the behaviour. Again, didn't wanted to do everything in receiver thread. That thread should only receive. Before MINA, were using DatagramSocket. We implemented our own version of filter chain, though much crude than MINA Filterchain. To be precise, after decoding, we do enriching based on some rules, and then dump them into DB and some magic as well. Here we SEDA helped us, last operation a bit more costly and queue broke the dependency between the two. BTW, this last queue is always the heaviest one. The First multiplexing as you suggested shall be good for simple cases, where there is not too much of business logic later. If there is heavy business logic, can't afford to do everything in my IoHandler. I hope it simplifies > >> Since its >> one way, no response to be sent back. That's why we choose this >> approach. Again at each stage, we do something meaningful. Say in >> protocolcodec, we convert raw bytes into objects, next these objects >> get converted into OSSJ object and then handler dumps them into DB. >> Each of these stages are decoupled, > > but they are chained, and executed into the same JVM, so as soon as you > limit the number of thread at some point, you won't process the messages > faster than the slowest stage. You can have two executor with say, N and M > threads, if processing events is slower in the second executor, the queue > between N and M will fill up and at some point, the first executor pool will > be exhausted when the second pool will be. This is true for any solution, the link is only as strong as the weakest link. Agree, with your statement, this is risk, and as of now I will prefer to live with it. Any suggestion on how to overcome this? >> onces passed no need to look back. >> Processing in one thread was like blocking it, let the messages be in >> queue and then use them. This is quite helpful for a high burst or a >> sustained load for a while. >> > > There is already a backlog in the first executor... >> >> I hope I have used MINA correctly, though I haven't benchmarked my >> application for sustained load, for a peak load it did fairly well, >> taking care of 5000 packets/sec, though had to set slightly higher >> value of receive buffer. >> > > The problem here is to know when your server hit it's limit? If it's around > 10000 req/s, then that's just fine : any architecture will work :) Now, if > you are targetting a higher rate, this is were things start to be > interesting :) Yup when we create the software we claim a sustained rate. Something like a sustained rate of 1000 packets/sec and a sustained burst of 5000/sec for 5 min. Interestingly, it becomes more as political statement :-) > > As much as I like the SEDA architecture, in a single VM, I don't know if > it's a valuable approach... > > I would be very interested to know if it sustains a better load than a > standard approach with a single executor :) Well this is the benchmark that I have to do, with predefined packet size so that I precisely see what is happening and how to improve. May be Trustin can guide me how he benchmarked different Frameworks. To be true, I am running away from this task, as long as I can :-) -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
