Closed saviorand closed 5 months ago
@alainrollejr ah, good to know, thanks. I'm refactoring more today, expecting some major improvements both in reliability in performance after it's done. Will keep you posted
@alainrollejr made some really major refactoring this weekend on this branch. Below is a selection of a couple test runs I made. I don't see a steep increase anymore with the size of the packet, although as you can see overall the rate is slower now. This is with connection: close
though, which is not how it should work by default. Setting tcp_keep_alive
should improve the performance up to 2x-2.5x based on experience. Working on this currently.
=======================
packet size 1280 Bytes:
=========================
Sent and received 1000 packets in 1.4183 seconds
Packet rate 0.71 kilo packets/s
Bit rate 7.2 Mbps
=======================
=======================
packet size 8500 Bytes:
=========================
Sent and received 1000 packets in 2.3081 seconds
Packet rate 0.43 kilo packets/s
Bit rate 29.5 Mbps
=======================
packet size 10000 Bytes:
=========================
Sent and received 1000 packets in 2.2904 seconds
Packet rate 0.44 kilo packets/s
Bit rate 34.9 Mbps
packet size 12800 Bytes:
=========================
Sent and received 1000 packets in 2.5152 seconds
Packet rate 0.40 kilo packets/s
Bit rate 40.7 Mbps
=======================
=======================
packet size 100000 Bytes:
=========================
Sent and received 1000 packets in 2.0973 seconds
Packet rate 0.48 kilo packets/s
Bit rate 381.4 Mbps
=======================
packet size 128000 Bytes:
=========================
Sent and received 1000 packets in 2.1425 seconds
Packet rate 0.47 kilo packets/s
Bit rate 477.9 Mbps
packet size 128000 Bytes:
=========================
Sent and received 1000 packets in 1.9405 seconds
Packet rate 0.52 kilo packets/s
Bit rate 527.7 Mbps
@saviorand It's cool to see you're using some of the other structs from Gojo! I'm just going through the code to see if I spot anything else that might help speed up the code.
new_buffer()
wants ownership of buffer b
. Since that's declared as an owned
arg, and ownership is not being transferred with the ^, Mojo is creating a copy of b. b
is no longer used in the function after creating the buffer, so I think you can safely transfer ownership.
https://github.com/saviorand/lightbug_http/blob/feature/no-string-conversions/lightbug_http/sys/server.mojo#L172
var buf = buffer.new_buffer(b) -> var buf = buffer.new_buffer(b^)
Same with the reader on the next line
https://github.com/saviorand/lightbug_http/blob/feature/no-string-conversions/lightbug_http/sys/server.mojo#L173
var reader = Reader(buf) -> var reader = Reader(buf^)
Copyable
has been removed from these structs in the latest gojo
release to prevent this from accidentally happening.
To get a feel for the problem, I basically searched for all magic number occurences equal to 4096 (there are quite a lot) and replaced them all by 1048576. Might be not all of them needed enlarging but then I have not grown with the code so hard for me to go analyse that. I can then increase packet sizes without the client or the server crashing. The fundamental problem remains though that speed still rapidly decreases with packet size. I suspect there is room for optimization by considering whether all those allocs really need to be within the function calls themselves. I.e. you could probably allocate a big buffer at struct instantiation time and then point to that one over and over again rather than alloc and free ? For what it's worth, output of my test client: