uws-react-native 0.0.2 → 0.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +4 -2
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -63,9 +63,9 @@ There are development and research things that you can read for your information
|
|
|
63
63
|
|
|
64
64
|
### Performance & Stability
|
|
65
65
|
|
|
66
|
-
This library is indeed focusing on performance, but we will focus more of it later until we reach the stability of uws-react-native due to [threading](#threading) issue. It does not mean uws-react-native will performs badly in terms of
|
|
66
|
+
This library is indeed focusing on performance, but we will focus more of it later until we reach the stability of uws-react-native due to [threading](#threading) issue. It does not mean uws-react-native will performs badly in terms of speed, but it is not stable enough in under a stress situation because we run uWebSockets only in one thread.
|
|
67
67
|
|
|
68
|
-
I have tested a stress test in an Android device. A lot of incoming request roughly 100 requests per second in roughly
|
|
68
|
+
I have tested a stress test in an Android device. A lot of incoming request roughly 100 requests per second in roughly 5 seconds for files uploading (multipart/form-data) may crash the app. We do not have the proper benchmark yet, but it is as we expected from one thread only. I am keeping my eyes on this issue to keep improving the performance.
|
|
69
69
|
|
|
70
70
|
### Threading
|
|
71
71
|
|
|
@@ -73,6 +73,8 @@ We are embracing the main chaos of supporting uWebSockets in React Native archit
|
|
|
73
73
|
|
|
74
74
|
Intentionally, we make the uWebSockets runs in another thread, therefore we have to make sure the communication safety between uWebSockets runner thread to the JS thread and vice versa. In theory, we can make uWebSockets runs in the main thread, but the app will be unusable, and then force closing the app is the only way to stop the server.
|
|
75
75
|
|
|
76
|
+
Yet, we only use one dedicated thread per uWebSockets run. I am in my own research to improve this by maximizing it to the hardware concurrency limit, but also to be careful about JavaScript runtime, because we have no control of it.
|
|
77
|
+
|
|
76
78
|
We have another issue because of the uWebSockets runs in another thread. From the JSI C++ side, we have to assume any JS function as a callback especially the route method handler is asynchronous. We cannot make a sync call to the JS function from an arbitrary thread to the JS thread, and it makes JS call to the uWebSockets runner is also late.
|
|
77
79
|
|
|
78
80
|
There some topics you may to read regarding this threading research
|
package/package.json
CHANGED