On 29/04/14 10:31, Santos Das wrote: > Hi, > > Thanks for all the inputs..... > > Had a discussion with few Nginx developers and running the nginx workers as > thread model is not advisable. The work was there to support the thread > model but it was dropped because of some issues and we still have the dead > code there.
Well I still think that making nginx use threads is easier than the other alternative, and it will perform better. But let's discuss the more generic option below. > Now, I am think to run nginx and for all the TCP/IP communication it will > talk to another process (say APP) which will be using rump-netmaptcpip. I > am not sure if this "APP" process will be bottleneck. I am wondering if > this will help me in providing better results than running Nginx directly > on the kernel. Any thoughts ?? > > I read about "rumpclient" and I am thinking this might not help me. > > Let me share my thoughts here such that you can throw some lights on this > (I am hoping to get some lights :-) ) > > 1. Say from Nginx I want to connect to a server. Now, I will inform the APP > process to perform the connect operation and APP will do the connect and > return me the fd. As the APP process will be communicating with more than > one worker process of Nginx, the APP process needs to maintain a hash table > which will map the fd with the process. Such that any further notification > on that FD will be correctly conveyed to the process. > > 2.Similarly, when it receives the data arrival notification on the socket, > it will read the data from the socket (the address passed to the read is > taken from the shared memory which is shared between Nginx worker process > and the APP process), and inform the Nginx worker process that the data has > arrived. > > Similarly for other TCP funtion calls... > > Will the above idea have any issues ? That will "just work" without writing any code (it's been supported for several years). If you want to know why it works, read chapter 3.12 of the blue book. > Now, I am thinking what kind of IPC I can setup between APP process and > Nginx process. All the IPCs go through the kernel and there is an overhead > . Any suggestions. A good starting point would be looking at microkernel research and seeing which of their techniques can be used. Note, the rumpclient abstraction is unfortunately not good (it's abstracted on a socket). I once wrote code to generalize it ... but I've lost that code :/ But speaking from experience, it's not too difficult to hack an alternative communication mechanism in there. If you come up something that's useful, we can work to integrate it properly. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
