On Sun, Nov 03, 2002 at 01:22:15PM +0800, George Chung wrote: > Thanks for you advice. > > Actually program b is also a POE program. > It does the following.
[...] > After accepting data from the main program via pipe, > it will ask the tcp server to send it to client. > i.e. > data source client -> main program -> program b -> destination client This seems to follow the same design as http://poe.perl.org/?POE_Cookbook/TCP_Forwarding # This sample sets up two servers. One of them accepts an input feed # from its clients and broadcasts that input to the clients of the # other. For lack of a better name, I've called this a tcp bridge. # This version supports multiple feeds and multiple data consumers. # Every feed will broadcast to every consumer. If this is what you're trying to do, you may do it without fork and pipes. That should eliminate #2 below. > I suspect two sources of problem. > 1. POE::Component::Server::TCP is not concurrent enough. > After data source client sends data, it's not fast enough to > fire up event and handle it when there are a lot of client > connecting to it. This may occur for a few different reasons: - Several connections may be sending a lot of events. This will increase the latency for any given event because it must wait behind all the ones that came before it. - Event handlers may be blocking or contain inefficient code. It is important for them to be efficient since other events may be waiting for them to finish. - POE itself may be too heavy for your hardware. You mention a lot of clients, so I suspect that the first reason is your problem. Removing program b (if you can) may cut your events in half. If all else fails, could you put your code on the web and make an URL available for review? > 2. The pipe between POE::Wheel::ReadWrite and POE::Wheel::Run > is not fast enough. I suspect it's the main problem as > POE::Wheel::ReadWrite is buffered IO. > > BTW, POE seems quite CPU resource hungry. Is there any way to improve it? Most of POE is already highly optimal. The big bottlenecks occur where we must work with select() or similar functions. There is no convenient or fast way I know to find the filehandles available from select() short of migrating that code to C. So we plan to have C versions of POE's most CPU hungry code by version 0.25. Work schedules being what they are, though, we may need more XS developers to make this goal. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
