Sending information to a ngnix from php on the same server without http

Question

We are developing a realtime app and we are using nginx push stream module for a websockets part. Firstly, data is send from a client to a php script that does some authentication and stores needed information in database and then pushes information to nginx that later sends it to a subscribed users on a specific sockets. Quite often there will be situations when there are more that 30 http requests made from this script to local nginx (which I am not exactly sure is a bad thing?).

Question
Is it possible to send information from php to nginx without http requests? Is there any way that my php script can communicate with nginx? What is a best practise to handle this kind of communications? Is sending 30+ http requests per php script a good practise?

I have read towards some AMQP solutions but haven't found information where nginx is a consumer of messages from rabbitmq.

I will gladly provide any additional information if something is not clear.

Answer 1

I am assuming the following:

Current work flow:

1. User run php script from command line, which communicate with a server side script/cgi setup in Nginx using http request
2. Server side script/cgi in Nginx will take the incoming data, process it and put it in database, or send out to end user

OP concern:

Efficiency of command line php script communicating with Nginx server side script using http protocol, which maybe overkill as the communication happen within the same server.

Proposal 1

1. Command line php script will write all information into file(s), then send one http request to Nginx server side cgi script
2. Nginx server cgi script, upon receiving the request, will pick up all information from file(s), then process it
3. ramfs (ram disk) can be use to minimize I/O to physical HD

Proposal 2

Combine your command line php script into the Nginx server side script, and create a web interface for it. Current command line user will login webpage to control the process they used to do it with command line tool.

Pro: No more inter-scripts/inter-process communication. The whole work flow is in one process. This maybe more scalable for the future also, as multiple users can log in through web interface and handle the process remotely. Additionally, they do not require OS level accounts.

Con: May need more development time. (But you only have to maintain one code base instead of two.)