How can I monitor the following socket.io statistics on both client and server?
byte sent/s
byte received/s
total message sent
total message received
Related
I need to find out what is the average size of request in gRPC when Im sending a string to server and receiving a string from server?
I read somewhere it should be around 20 Bytes but what I see in Network Monitor app is that the request is above 500 Bytes. So is it the smallest possible size of a gRPC message size or what?
For a single rpc, gRPC needs to do a few things:
Establish HTTP/2
(Optional) Establish TLS
Exchange headers for the RPCs (size depends on schema)
Exchange actual RPC messages (size depends on schema)
Close connection
gRPC is meant to be used for many RPCs on a single connection so the smallest possible rpc message is really the bytes used for 4.
[Edit]
I checked and the minimum data exchanged for an rpc is over 500 bytes, in terms of raw IP packets.
I used the gRPC helloworld.proto, changed to send an int32.
Inspecting packets in Wireshark showed the following IP packet totals:
1286 bytes to establish connection, exchange headers and do the first rpc
564 bytes for each subsequent rpc
176 bytes for client Shutdown
Of those 546 "minimum" bytes:
67% was TCP/IP overhead (acknowledgements, packet headers)
10% was "trailer" data sent after the rpc
Standard squid config only logs one CONNECT line for any https transaction. What is being counted/timed by the reported bytes and duration fields in that line?
Got an answer via the squid-users mailing list [1]:
Unless you are using SSL-Bump or such to process the contents specially.
The duration is from the CONNECT message arriving to the time TCP close
is used to end the tunnel. The size should be the bytes sent to the
client (excluding the 200 reply message itself) during that time.
[1] http://lists.squid-cache.org/pipermail/squid-users/2016-July/011714.html
when using ZMQ transfer data, the transmitted port is fast and the data is huge, but the receive port processing is slow and the data is accumulated between the two processes. Does any one know how to solve this problem? Thanks.
Instead of sending all the data at once, send in chunks instead. Somethings like this...
Client requests file 'xyz' from server
Server responds with file size only, ex: 10Mb
Client sets chunk size accordingly, ex: 1024b
Client sends read requests to server for chunks of data:
client -> server: give me 0 to 1023 bytes for file 'xyz'
server -> client: 1st chunk
client -> server: give me 1024 to 2047 bytes for file 'xyz'
server -> client: 2nd chunk
...and so on.
For each response, client persists chunk to disk.
This approach allows the client to throttle the rate at which data is transmitted from the server. Also, in case of network failure, since each chunk is persisted, there's no need to read file from beginning; the client can start requesting more chunks from the point before the last response failed.
You mentioned nothing on language bindings, but this solution should be trivial to implement in just about any language.
I'm using SMPPsim to sent SMS to my task through it's MO Service.
I've put 15000 messages into deliver_messages.csv file, but SMPPsim sends them permanently.
Is there any way to limit count of SMS sent by SMPPsim?
As per SMPPSim there is no logic implemented to limit the count of messages.
For more details you can find classes called MoService.java ,MoMessagePool.java in SMPPSim source code .Smppsim simply fetching the values DELIVER_MESSAGES_FILE ,DELIVERY_MESSAGES_PER_MINUTE from smppsim.props and submitting respectively .
Has anyone had experience with this tool (WCS). Some sms messages are not being sent. The log says:
2007-04-14 10:59:53,490 [logica-smpp2-receiver] ERROR logica-smpp2 - Message not sent, SubmitSM command status: 0x14
If I've read the specs correctly, command status 0x14 means "message queue full".
I suggest:
- Try spreading the messages over a longer period
- Ask your SMPP provider what the limits are, how many messages can you send in how much time? Make the appropriate changes in the calls, or ask them to increase the amount of messages you can send for a given time period.
Hope this helps!