Re: xinetd vs php socket server

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@gmail.com> wrote: > On Mon, Mar 28, 2011 at 12:38 PM, Bostjan Skufca <bostjan@a2o.si> 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 >