simple web server support for static files

[linsong]

communityWebServer kit try to add the basic web server feature to sedona, it mainly focus on serve static files for now and only handle 'GET' request. For example, you can put a mirror of sedona docs under 'statics' folder within folder 'doc', then you can view the document in browser from 'http://SEDONA_IP/statics/doc'.

It can serve a rich client web application developed by React, Vue or Angular etc, and if the web application talks to our RESTful API, there will many possibilities.

[linsong]

Hi @divisuals,

When you have time, can you review this pull request ? As we discussed before, this is simple WebServer to serve static files, so that user can store rich client web app on controller and serve by this kit. Thanks.

[divisuals]

Added a few initial comments. Few other thoughts:

• What is the plan for security (authC and authZ) for the static files?
• Can we also add 'stress' tests for larger gz payloads? Trying to understand how this weblet would behave for serving larger files from embedded devices

[linsong]

My understanding of static files are html, javascript, css, image etc. They will be downloaded and rendered in web page by browser. User's data should not be stored in static files. So for most of case, static files does not need security.

The main use case of this kit is:
Someone build a Single Page Application(SPA) using a JS framework(ReactJS, VueJS etc) for example, the frontend only includes static files, this kit will serve these files; javascript will communicate with backend(sedona) to load/save data through the RESTful data API, security is a must for the communication. We make the sedona side ready: static files serving, data API(including security). So that others can develop their SPA and ship it together with their sedona app.

[linsong]

@divisuals I have pushed a new commit that will allow user to config the URL prefix. Please see my commit comments for more details, thanks.

[divisuals]

My understanding of static files are html, javascript, css, image etc. They will be downloaded and rendered in web page by browser. User's data should not be stored in static files. So for most of case, static files does not need security.

The main use case of this kit is:
Someone build a Single Page Application(SPA) using a JS framework(ReactJS, VueJS etc) for example, the frontend only includes static files, this kit will serve these files; javascript will communicate with backend(sedona) to load/save data through the RESTful data API, security is a must for the communication. We make the sedona side ready: static files serving, data API(including security). So that others can develop their SPA and ship it together with their sedona app.

Makes sense. However, from my understanding of sedona, the services get only a fraction of time in every execution cycle so serving large files can become problematic. This is probably why even small files are chunked before sending over sox (UDP). Also, your recently reported issue #27 could be related to these contentions/ timeouts.

Anyway, we can mark this feature as experimental, fix #26 / #27 and then release it.

[divisuals]

Is there any test application for validating the behavior? Perhaps an app snippet that I can add to validate? Will try hand-crafting app.xml and kits.xml files to validate.

Long-term, probably a good idea to start creating test application (.xml) files within the /apps directory.

[linsong]

Makes sense. However, from my understanding of sedona, the services get only a fraction of time in every execution cycle so serving large files can become problematic. This is probably why even small files are chunked before sending over sox (UDP). Also, your recently reported issue #27 could be related to these contentions/ timeouts.

Yeah, I guess the time slice is probably the reason. Maybe we should handle IO specially to make it more responsive, not sure how to do it yet.

The good part is gzip and cache will make this problem less to happen. It is surely not production ready, hopefully after #27 we can find way to improve it.

Anyway, we can mark this feature as experimental, fix #26 / #27 and then release it.
Yeah, agreed.

[linsong]

I just add a demo app apps/webServer.sax and scode/webServer.xml. After you can build the communityWebServer kit, you can just run

$ makeapp webServer && runapp webServer

then open http://127.0.0.1:8080/doc/ in browser.

[divisuals]

I just add a demo app apps/webServer.sax and scode/webServer.xml. After you can build the communityWebServer kit, you can just run

$ makeapp webServer && runapp webServer

then open http://127.0.0.1:8080/doc/ in browser.

Thanks for the demo scode/ apps for testing. Seems makeapp and runapp are your local scripts for sedona compilation. Anyway, I was able to test the webServer. The web service reliability has worsened with this Weblet - getting a lot of 'ERR_CONNECTION_RESET' situations in the chrome browser. As you mentioned, #27 should help test this theory.

[linsong]

Thanks for the demo scode/ apps for testing. Seems makeapp and runapp are your local scripts for sedona compilation. Anyway, I was able to test the webServer. The web service reliability has worsened with this Weblet - getting a lot of 'ERR_CONNECTION_RESET' situations in the chrome browser. As you mentioned, #27 should help test this theory.

After some testing with the ab benchmarking tool, I find that the issue is caused by concurrent requests. If I run command:
$ ab -n 100 -c 1 http://localhost:8080/docs/index.html
It works pretty well, svm can handle 20reqs/sec in average, and I can run it multiple times without issue;

But if I add some concurrency:
$ ab -n 100 -c 2 http://localhost:8080/docs/index.html
I will get connection reset error after 3 or 4 times.

You can get the same result if you do the benchmark on SpyWeblet and SpyRestWeblet, I think there is some bug in web kit when handling concurrent requests.

The reason why you can get the 'ERR_CONNECTION_RESET' in browser when accessing http://localhost:8080/docs/index.html is: index.html includes a style.css file, so browser sends 2 concurrent requests; but for http://localhost:8080/spy, there is only one request. If you pressing the refresh button fast enough, you can get the 'ERR_CONNECTION_RESET' error, too. So the issue hasn't any worsened.

I will start to work on #27 to fix this concurrency issue. Let's merge this branch in after #27 is done.

[divisuals]

After some testing with the ab benchmarking tool, I find that the issue is caused by concurrent requests. If I run command:
$ ab -n 100 -c 1 http://localhost:8080/docs/index.html
It works pretty well, svm can handle 20reqs/sec in average, and I can run it multiple times without issue;
That's good to know!

But if I add some concurrency:
$ ab -n 100 -c 2 http://localhost:8080/docs/index.html
I will get connection reset error after 3 or 4 times.

Another experiment you should try is to remove spy and spyREST weblets and just run the static pages to see if it improves the performance.

You can get the same result if you do the benchmark on SpyWeblet and SpyRestWeblet, I think there is some bug in web kit when handling concurrent requests.

The reason why you can get the 'ERR_CONNECTION_RESET' in browser when accessing http://localhost:8080/docs/index.html is: index.html includes a style.css file, so browser sends 2 concurrent requests; but for http://localhost:8080/spy, there is only one request. If you pressing the refresh button fast enough, you can get the 'ERR_CONNECTION_RESET' error, too. So the issue hasn't any worsened.

My observation is just empirical - with all 3 weblets enabled, I see 'ERR_CONNECTION_RESET' even on simple spy pages that aren't pulling two files (sending concurrent requests). The preliminary explanation is that with 3 weblets enabled, each of them is getting even a smaller time slice. Additionally, webkit is certainly buggy as you pointed out.

I will start to work on #27 to fix this concurrency issue. Let's merge this branch in after #27 is done.

Agree!

[divisuals]

After some testing with the ab benchmarking tool, I find that the issue is caused by concurrent requests. If I run command:
$ ab -n 100 -c 1 http://localhost:8080/docs/index.html
It works pretty well, svm can handle 20reqs/sec in average, and I can run it multiple times without issue;

That's good to know!

But if I add some concurrency:
$ ab -n 100 -c 2 http://localhost:8080/docs/index.html
I will get connection reset error after 3 or 4 times.

Another experiment you should try is to remove spy and spyREST weblets and just run the static pages to see if it improves the performance.

You can get the same result if you do the benchmark on SpyWeblet and SpyRestWeblet, I think there is some bug in web kit when handling concurrent requests.

The reason why you can get the 'ERR_CONNECTION_RESET' in browser when accessing http://localhost:8080/docs/index.html is: index.html includes a style.css file, so browser sends 2 concurrent requests; but for http://localhost:8080/spy, there is only one request. If you pressing the refresh button fast enough, you can get the 'ERR_CONNECTION_RESET' error, too. So the issue hasn't any worsened.

My observation is just empirical - with all 3 weblets enabled, I see 'ERR_CONNECTION_RESET' even on simple spy pages that aren't pulling two files (sending concurrent requests). The preliminary explanation is that with 3 weblets enabled, each of them is getting even a smaller time slice. Additionally, webkit is certainly buggy as you pointed out.

I will start to work on #27 to fix this concurrency issue. Let's merge this branch in after #27 is done.

Agree!

[linsong]

You can get the same result if you do the benchmark on SpyWeblet and SpyRestWeblet, I think there is some bug in web kit when handling concurrent requests.
The reason why you can get the 'ERR_CONNECTION_RESET' in browser when accessing http://localhost:8080/docs/index.html is: index.html includes a style.css file, so browser sends 2 concurrent requests; but for http://localhost:8080/spy, there is only one request. If you pressing the refresh button fast enough, you can get the 'ERR_CONNECTION_RESET' error, too. So the issue hasn't any worsened.

My observation is just empirical - with all 3 weblets enabled, I see 'ERR_CONNECTION_RESET' even on simple spy pages that aren't pulling two files (sending concurrent requests). The preliminary explanation is that with 3 weblets enabled, each of them is getting even a smaller time slice. Additionally, webkit is certainly buggy as you pointed out.

hmm, that's weird. with 3 weblets enabled but not requesting data from them should only add a little load on svm(in WebService.findWeblet).

I just go over the execution cycle logics, for Service object, it can get more chance to run compared to normal Component object, more than once per scanPeriod(50ms by default). I can reproduce the issue easily on my mac with just manually refreshing browser, I guess there must be something else wrong.

Anyway, I will figure it out in #27. Since there is no work left here, I will close it now and let's comment on #27 later.

[linsong]

sorry, let's keep this open so that later I cann't forget to merge it after #27 is done.