Ajax or websocket to send messages?

Question

PHP

Hello.
I am writing a chat on php 7.2 + websocket + workerman, apache server.
The question is, what is the best way to send messages to workerman (via ajax or via an already open websocket)?

Of course, I first chose via websocket.
Why not sure about this choice? On the workerman side, you need to understand who sent the message, but I don’t want to add this information to the message itself (for security reasons, since you can add anything on the front). Accordingly, you can determine the sender with an ajax request to the server (there we add the sender to the message and forward the message to the workerman via TCP) or on the workerman, where the current list of users (in the form of a multidimensional array) with their info and open connections is in memory.
If there are few users, let's say up to 1000, then searching in this multidimensional array by the id of an open connection will not take much time and resources. What if there are 100,000 or more users?

What will ultimately be faster and less resource-intensive?

Answer 1

And where did you put the client's connection identifier?! :))

Answer 2

You won't know without a profiler.

Answer 3

I use Websocket as an indicator that "the server has changed", sending a minimum of information. I do not send anything from the client up through ws. The client understands that it is necessary to pull the API, has session keys with him and sends a full request. Otherwise, confusion with the data. For some clients, ws does not work and needs to be replaced with another method. The basic logic of "pull the API and change the state of the client" remains unchanged.
The approach has the right to life in personal accounts, order lists, etc. not too fast updated data. The WS connection hangs, consuming almost no traffic, and sends numbers for indicators of the number of orders.

Answer 4

I made a multiplayer game with browser clients. The advantage of ajax is the guarantee of the request-response protocol, it is easier to maintain consistency. With websocket you are shooting into the air, you don't know if a message was received or not, you don't know which one was received earlier, you don't know the state of the receiving side. In the absence of consistency guarantees, it is more difficult to prescribe logic. In all other aspects , websocket is better - more modern, faster, more asynchronous, more continuous and at the same time less resource-intensive . As a result, I did it on websocket, built on a text protocol, invested and parsed metadata on the server and client to synchronize the state.