I've been playing with the BlockSize on my app (that's not quite done yet) and am wondering what the downside of having a larger BlockSize is? If I know that my max message size will be 30k what is wrong with setting the BlockSize to 30k (now I understand that you don't want to set it to really really large sizes but where are the tradeoffs?
thx, bobm > -----Original Message----- > From: "Rocco Caputo" <[EMAIL PROTECTED]>@INTERNET@HHC > Sent: Thursday, January 24, 2002 8:53 AM > To: [EMAIL PROTECTED] > Subject: Re: POE::Component::Server::IRC > > <<...>> > On Thu, Jan 24, 2002 at 11:12:42AM -0500, alex j avriette wrote: > > > > I wanted to pop into this conversation briefly... I wrote a napster > > server using POE and a module I called POE::Filter::LittleEndian (before > > I had really tinkered with PoCo::IRC). I believe most of that code is > > available on http://envy.posixnap.net/~alex/perlcode/, but I could be > > mistaken (theres some odd proxy/firewall issue with that site)... > > Unfortunately it really was only able to handle about 250 connections > > before it became so slow as to become useless. > > perlserver.pl is 403 forbidden. Have you tried increasing the SysRW > maximum read/write size? POE 0.17's default block size is 512 bytes, > so a 10MB file would require at least 20480 events be processed. POE > 0.18 defaults to 4096 byte blocks, so the same file would be streamed > in at least 2560 events. With this code, you can do it in only 640 > events, assuming the other end can keep up with you: > > Driver => POE::Driver::SysRW->new( BlockSize => 16384 ); > > The event counts will be higher if the other side can't keep up. > > > So while I admire the project (and I've thought of writing an IRC server > > myself, as I like bahamut but dislike not being able to hack on it), I'd > > like to inject a little caution ... useful as Services, probably. Not > > particularly useful as a drop-in for an ircd however. This strikes me as > > unfortunate. > > It's possible to write POE servers at three levels. Each successively > higher level trades away some control and performance for convenience. > > At the lowest level, there's POE::Kernel's select_foo() methods and > raw socket calls. The select_foo() methods simply invoke your event > handlers when a filehandle becomes ready; the reading and writing is > left as an exercise for the programmer. > > $kernel->select_read( HANDLE => EVENT ); > $kernel->select_write( HANDLE => EVENT ); > > The POE::Wheel::Foo classes are implemented in terms of select_foo(). > They have evolved over time to do a lot of things (like flow control), > some of which are probably not necessary in any given program. > > Finally there's POE::Component::Server::TCP. It's implemented in > terms of POE::Wheel::SocketFactory and ReadWrite. You get virtually > no control over any of the particulars of server I/O, but it lets you > write servers with very little extra code. > > I guess my point there is that performance can be claimed back by > moving down to lower-level code. > > > I'd love to contribute if I can however. > > Publishing your Napster code would help. There are lots of options if > you want a more direct hand in POE's development... > > There's a lot of room for optimizing in the file I/O code, even at its > lowest level. I recently added some quick hacks for Windows > compatibility, and I'm certain they could be done better. > > On a more higher level, there are a lot of half-baked ideas on POE's > web site. Implementing one of them, or even just commenting on them, > would be a big help. It's a lot of stuff to think about, and it would > go faster with more brains working on it. See: > > http://poe.perl.org/?POE_RFCs -- General ideas. > http://poe.perl.org/?POE_RFCs/object_layer -- Component architecture > ideas. > > No help is too small. Thanks! > > -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net >
