If you need high performance you probably already know that it will be very expensive CPU wise if workers are spawned on each request. If you don't, I would not bother with daemon and just use xinetd. You can always add daemon-handling stuff later on. Well I do hope you find a good working solution with as little inconvenience as possible, b. On 28 March 2011 21:27, Nathan Nobbe <quickshiftin@xxxxxxxxx> wrote: > On Mon, Mar 28, 2011 at 12:38 PM, Bostjan Skufca <bostjan@xxxxxx> wrote: > >> Xinetd will definitely be faster way than coding your daemon in PHP. >> > > In this case: > >> You have to consider many other things as well: >> - do your worker processes run under various UIDs (do they do >> setuid/setgid)? >> > no > > >> - do your workers die after processing each request/client or do they >> process multiple connections? >> > die after each request > > >> - do you need inter-worker communication? >> > no > > >> - resource locking issues, etc? >> > perhaps some, but i think this could be handled via a select to the > database prior to a write > > >> What is your goal, the function of your daemon/socket server? >> > basically to process an incoming payload from a client, parse and store the > results. not sure why the requirements are to accept the payload over > non-http, but that is out of my control. > > i guess you can see where im going with this, basically, why reinvent the > wheel w/ the daemon code when xinetd is available. i suppose those php > libraries you mentioned are an argument against that, but then there is the > speed benefit of xinetd. i guess it just comes down to a battle of > tradeoffs. > > -nathan >
