I haven’t tested that much since clients 99% of the time don’t need to fire events every frame,e etc so CPU usage isn’t a issue, so I belive it is the same or better then packet client → server but feel free to test it and let me know so I can improve it!
Here is the place file. I named the scripts Alexander so you can see which one is being used. I commented out the event in the server script so you can test one by one the one you want to test.
SImple_Testing.rbxl (195.0 KB)
It would really help if there was support for RemoteFunction-like behaviour, just like in Packet, where it’s called responses.
Nevermind, that’s already a thing!
Amazing.
What’s the circuitBreaker parameter for requests? This is the example in the documentation:
circuitBreaker = { failureThreshold = 5, resetTimeout = 30 }, -- Example
Btw I’m very impressed with the performance it has with all of these features!
The documentation is very thorough too.
Overall it’s an amazing resource, which you really need to get out to more people.
failureThreshold = 3, -- Trip to OPEN after 3 consecutive/recent failures
resetTimeout = 20, -- Wait 20s in OPEN state before trying HALF_OPEN
This is more deeply explained in the Circuit Breakers section of the documentation
Thank you very much. I am going to continue to try and improve the modules performance etc, and hopefully fix any issues you guys find
Also I think that one of the main reasons it’s not so attractive is due to the post.
There’s no logo or images or videos, but instead just text — a lot of text.
Of course you need text to explain things, but just make sure to wrap things in categories and make it more manageable for users to read.
Use
[details="Cool stuff"]
Hidden stuff here, that is expandable with an arrow.
[/details]
to hide things.
Just like this:
Hidden stuff here, that is expandable with an arrow.
And try to make a logo. I’ll gladly make one for you if you want.
I tried to and failed so bad 
I would appreciate it very much
I just realized you’re one version behind with Signal+. Make sure to update to v2.6.1 in the next update.
Sorry for the delay, but this will be fixed in version 1.0.1 wich will come out soon hopefully
Changes and Improvements
Thank you to
@AlexanderLindholt
@tututuana
@Planet_Dad
For pointing out the issues and bugs
Good job! I will keep an eye ont his module 
Looks like I got everything setup. But, I am getting warning errors on on the compression. I don’t see anywhere where to suppress this. Looking at DataCompression and DynamicSender, the warnings looks hardcoded. Of course I “could” go comment out each one, but am I missing something?
*This is using the latest v1.0.1
21:24:08.212 LZW Decomp: Final deserialization resulted in nil. - Server - DataCompression:406
21:24:08.212 [NetRaySender] Failed to decompress data: nil - Server - DynamicSender:247```
21:15:36.040 --- convertDataToString: Encoding data --- - Client - DataCompression:198
21:15:36.040 --- convertDataToString: Structure type pre-JSON: nil - Client - DataCompression:211
21:15:36.040 --- convertDataToString: Calling JSONEncode --- - Client - DataCompression:213
21:15:36.040 --- convertDataToString: JSONEncode succeeded, length: 4 - Client - DataCompression:219
21:15:36.041 LZW Compress: Using uncompressed (LZW larger/equal) - Client - DataCompression:359
21:15:36.078 LZW Decompress: Handling UNCOMPRESSED data - Server - DataCompression:381
21:15:36.079 LZW Decomp: Final deserialization resulted in nil. - Server - DataCompression:407
21:15:36.079 [NetRaySender] Failed to decompress data: nil - Server - DynamicSender:247
21:15:41.585 Disconnect from ::ffff:127.0.0.1|60129 - Studio
21:15:41.629 [NetRaySender] Game closing. Flushing remaining batches... - Server - DynamicSender:560
are you sure with
your own benchmark?
I get approximately the same results as he does:
He send the place file here:
After further testing, I have to say, this is absolutely amazing.
Here’s a quick review:
Any type, that can’t handle all things like e.g. tables.Overall a really great library. If it receives a few polishing updates I will be using it in all of my works, because there’d be no reason not to.
thats not a “true” benchmark works 
that benchmark is very lightweight benchmark, the benchmark i given is how is benchmark an networking library actually…
here the result test using ur benchmark…
roblox (regular remote event):
packet (v1.1):
netray (v1.0.0):
netray new update: extra stonk++ bandwidth, slightly better fps perf…
SImple_Testing.rbxl (192.4 KB)
plz learn more how to benchmark 
You did the same thing as me.
I tried with some advanced tables too, and NetRay did great.
Weird how it doesn’t handle this correctly.
download the file i given recently, test it, prove it.
wat
Didn’t say it wasn’t a true benchmark you did. I tested it. But so did I with many other tests, where NetRay performed amazing, so it may be a huge bug, I’ll try to find out what it is.
--!optimize 2
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local packet = require(ReplicatedStorage.Packets)
local NetRay = require(ReplicatedStorage.Shared.NetRay)
local Event = NetRay:RegisterEvent("Testing")
local remote = game.ReplicatedStorage.RemoteEvent
local Player = game.Players.PlayerAdded:Wait()
local random = Random.new(908248)
local data = {}
for _ = 1, 1e2 do
table.insert(data, {
id = random:NextInteger(0, 65535),
x = random:NextInteger(-128, 127),
y = random:NextInteger(-32768, 32767),
z = random:NextInteger(-128, 127),
orientation = random:NextInteger(-32768, 32767),
animation = random:NextInteger(0, 255),
})
end
while true do
for _=1,1e2 do
--packet.Testing:FireClient(Player,data)
Event:FireClient(Player,data)
--remote:FireClient(Player,data)
end
task.wait()
end
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Packet = require(ReplicatedStorage:WaitForChild("Packet"))
return {
Testing = Packet("Testing", {
{
id = Packet.NumberU16,
x = Packet.NumberS8,
y = Packet.NumberS16,
z = Packet.NumberS8,
orientation = Packet.NumberS16,
animation = Packet.NumberU8,
}
})
}
then why new update, more worse the bandwidths 