-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
civetweb issues #27020
Comments
I do not know Zephyr (although I know some other embedded operating systems), but I might be able to provide some details on civetweb (I came here from civetweb/civetweb#895). Regarding stack size:Indeed civetweb assumes the stack size to be some pages larger than the MG_BUF_LEN size. A buffer needs to contain at least the entire HTTP/1.x header. This is
Once the header is longer than MG_BUF_LEN, the request cannot be processed anymore - the current definition Regarding priority:I cannot recommend any details, since I do not know the priority levels of Zephyr. Not knowing Zephyr, I cannot directly tell you where the performance bottleneck might be. From another real time operating system, I know it was important to get the priorities right, together with the priorities of the network interface card interrupt and the priorities of the thread responsible for the TCP/IP stack. It was required to keep these thread priorities one level higher than the civetweb master thread. The worker threads could be the same as the master thread or one level lower. I hope this explanation "from the CivetWeb side" is of any use - probably if you add proper know how from the Zephyr side, it might help you solve this issue. |
Thank you @bel2125 for sharing useful info about CivetWeb. I'm still sniffing around, trying to set correct prioirities etc. Unfortunatelly I'm struggling with errors like |
Ok. At least I have found the reason for failed allocations of packets or buffers. When I set civetweb priority close to TCP/IP stack it means that we are in cooperative range (zephyr priority < 0). In such case when civetweb is serving a bigger page (multiple My upload is still quite slow, though. |
For the slow upload, you might be impacted by #26330. Have a look at the TCP window using Wireshark. We have been hit by this when implemented also an HTTP upload with civetweb. It seems that this comes from Zephyr's TCP module and not civetweb. @armandciejak in #26330 is my co-worker. |
@xhpohanka I noticed the same issues as you. For the allocation problem I increased the value for I do not fully understand the relation between allocation failing and thread priorities. Shouldn't |
From the pure civetweb point of view (no Zephyr specifics): CivetWeb does not care (cannot know) why "send" is not ready ... peer not responding, no memory in TCP/IP stack, ... but will work as long as it returns "EWOULDBLOCK" (or OK). Any other return value will be treated as error, and the mg_write function returns immediately with an error. I just found in the CivetWeb source: in most places it checks for "EWOULDBLOCK" and "EAGAIN", in some places only for "EWOULDBLOCK". In all gnuC libraries, they have the same value. According to google, there are some old (historic?) UNIX variants where they had different values. I hope this is not the case for Zephyr, since it might cause some issues. |
EWOULDBLOCK is the same as EAGAIN in Zephyr.
|
I also am not sure how |
@PiotrZierhoffer could you please take a look since you are the maintainer of the civetweb module? |
same new notes from my side:
|
@xhpohanka Try to gzip your files served from your civetweb http server and use mg_send_chunk() for bigger files. Still, there may be issues. Let me know, if mg_send_chunk() improves your performance. If you need more information how to use it, see my PR #28323. P.S.: How much Bytes, KiB or MiB needed your biggest file be on your civetweb http server? |
@Nukersson Thanks for suggestion of Currently I have quite stable implementation of web server on my platform. Only time-to-time one of the pages is not transfered and need to be refreshed. I have merged mbedtls support for civetweb (originaly by qinch) and it also works with exception of loading files (firmware update). I also tried to alter civetweb source to use zephyr's internal tls_socket implementation and it works (no big testing though) the same (normal pages ok, upload fails). The biggest web page is jquery. So around 85kB/ |
@xhpohanka Thank you for sharing of your experience here.
Believe me, I've seen same production code with well tested network staks and web/http servers. They do same files dropping and whole page reloading from time to time. I think, we need dig deeper here 😄
Take a look at #28323 PR and search for |
@xhpohanka By the way: does this conversation solves your civetweb problems mentioned here? Can then we close this issue? Otherways, if you have more questions I can try to answer - you're welcome! |
@xhpohanka Do you have any new insights? |
Hello, I think that we can close this issue. The original problems was solved with TCP2 introduction and now I have just an occassional instabilities that are probably caused by tcp stack in connection with STM32H7 driver. I understand your suggestions with compressing the pages but I think that this should not be neccessary. We had a similar web on the same architecture and freertos and it works without any issues. |
I'm playing with
civetweb
webserver module on latest zephyr tree and I see some issues herestack size
When I try to serve a bit bigger pages that are in provided in samples I got stack overflow errors. Looking into code this does not lookg good to me
MG_BUF_LEN
sized arrays are allocated on stack on several places and this size is even bigger than default stack size used in zephyr sample.very slow upload
I have tested upload using form (
FileUploadForm
handler) inmodules/lib/civetweb/examples/embedded_c/embedded_c.c
. It is unacceptably slow on my embedded platform (stm32f429) and also very slow using qemu_x86, so I think it is not platform related.Civetweb threads are made by pthread api with default priority equal to 0 which corresponds to lowest preempt priority of 15. I was able to speed up the upload only by changing the priority to highest one (-15). The same priority is used in
zephyr/samples/net/sockets/dumb_http_server_mt
. However with such setup my pages stop to work entirely with errors like<err> net_pkt: Data buffer (28) allocation failed (arp_prepare_reply:495)
. I was not able to found the connection between packet allocations and civetweb priority yet. It seems wierd to me, this failed allocations start to appear even when the priority is inreased only by a small number, not neccessarily to -15.Do anyone use civetweb on zephyr for some real project?
my config
The text was updated successfully, but these errors were encountered: