No real questions at this time...but OMG, this is an AMAZING way to develop for the web.

[itg-assistant]

John Nagle asked 2017-05-30 19:00:40 UTC

I have been following you since Visual WebGUI and in those days it was "close", but not there yet. This is (so far) pretty flawless. I lost sleep last night thinking about things I want to build with it. When a tool does that to me, I consider it a game-changer.

I am curious as to how an instance of an app will tax the server as compared to a standard ASP site. It's such an awesome dev experience, I keep thinking there must be a catch somehow. Please tell me there's no catch.  :-)

Thanks Luca,

-John

[itg-assistant]

Luca answered 2017-05-30 19:15:11 UTC

Hello John,

Thank you for your feedback. We are not related to Visual WebGui in any way other than having used it on projects years ago.

A Wisej app will use more memory than an ASP site but a lot less CPU load. Of course it depends a lot on how the app is developed.

However, Wisej can scale easily and it has a built-in healthcheck system that allows a load balancer to skip an instance depending on configurable parameters: active sessions, memory usage, CPU load.

Wisej is primarily designed to build Line of Business applications, not web sites. It's hard to compare with an ASP app in a simple scenario.

And we have a cool self hosting or standalone feature here: https://wisej.com/blog/self-hosting-and-standalone-web-apps/

Regards,

Luca

[itg-assistant]

John Nagle answered 2017-05-30 19:26:12 UTC

Thanks for the fast response...I'm guessing the main issue with "website" development is that each instance of the application persists for specific amount of time before timing out from inactivity? Whereas ASP apps are transactional in nature? (I assume this is configurable?)

Has any stress testing been done to see how many concurrent sessions a typical server can accommodate with a reasonably-sized application?

Anyway...for me, the speed with which I can implement a site would trump any concerns unless it's, say, an order of magnitude more expensive to run at scale. And even then, if the site is expecting only light-moderate traffic, no problem.

[itg-assistant]

Luca answered 2017-05-30 19:39:02 UTC

Most (if not all) ASP sites and apps that do something useful :) use the Session object and persist in memory (or on disk/database, for the daring developers that have time to burn.) Wisej uses more memory because instead of recreating all the controls on each request/response it keeps a representation of the controls in memory. Wisej sessions also expire after a configurable amount of time. Wisej also detects user inactivity and has a keep-alive system to detect when the browser is closed or the connection is lost.

ASP.NET is based on an http request/response roundtrip and HTML concatenation on the server, like php. Outside of the request/response cycle, the server has no knowledge of the page or what's on the browser, it only has the session and whatever objects the app places on the session. If an ASP.NET app places a control on the session it's useless since it's not "wired" to the page, it's a dead control instance.

Wisej is a Real Time Web System from the foundation, so the server can update the client at any time without a request since it switches to websocket on the first load. So the server code can push updates to any control on the client at any time and from any thread. The server can even draw directly on the client.

Try the BackgroundTasks and CustomPainting: http://wisej.com/examples/

Or look at the ProgressCircle control here: http://wisej.com/extensions/

/Luca

[itg-assistant]

John Nagle answered 2017-05-30 19:52:48 UTC

Excellent information, thank you. Sorry to pepper you with questions...but back to the max. practical concurrent sessions question...has this been stress-tested?

My simple test application I've been playing with has the main window and another page, and the .dll that it compiles down to is around 17kb. I assume that that footprint plus wisej overhead plus whatever code is allocated during a session is more or less the memory footprint for each instance? A best practice would no doubt be to release memory you are no longer using...i.e. load, use, release. Is static data shared among instances?

If that's the case, I don't see a problem running running at least thousands of concurrent sessions on one box...does that seem reasonable?

Again, my apologies for the barrage of questions. (But I suspect other prospective customers would like to know the answers to these as well.) :-)

-John

[itg-assistant]

Luca answered 2017-05-30 20:16:26 UTC

We stressed test different scenarios in terms of memory (focusing on GC to make sure there are no leaks) and performance to optimize the JSON packets exchanged between client and server. We also have been running demo servers with live dashboard to monitor memory release and cpu peaks.

The dll size is not relevant since it's loaded only once. What's relevant is the total number of windows/pages and controls that are live at the same time. If your app creates a page with 300 controls, that's your memory. If it keeps creating windows and never disposes them, that it will use more memory. We have very complex apps (practically impossible to build in ASP Net) with 1,000-2,000 controls all on screen at the same time. Then you have the issue of data sets and whether they are kept in memory or discarded.

The overall memory load is highly dependent on the application and it's hard to tell you how many live sessions can a server of a certain size handle. With ASP.NET it's the same, if an app saves a 10MB result set in the session then each session consumes at least 10MB.

The best way is to create X sessions as a baseline, see the memory used in Task Manager, then add Y more and divide the memory used difference by the session difference. If an average server component uses say 100 bytes (location, size, name, other properties), and you have 1,000 live controls (textboxes, buttons, listboxes, widgets, etc) you use 0.1MB. Then it depends on the data and whether a data set is kept in memory or not (like an ASP Net app would do). On average a medium size business app (which would be quite large for ASP NET standards) can easily use 1 to 5MB so you can have 5,000 to 1,000 live sessions on a 8GB server.

The most important thing for us is to make sure that all objects are fully collected and memory is released when a session is terminated or a component (like a form, page, window) is disposed.

HTH

Best,

Luca

[itg-assistant]

Tiago (ITG) answered 2017-05-30 23:30:09 UTC

Hi John.

Static data is indeed shared among instances. You can use this feature to do amazing things. Have a look at http://wisej.com/support/question/bound-dgv-not-updating?sort=oldest 

There is this static collection. On one session, I updated the collection. As the collection is data bound, changes are pushed to the client, to all client sessions, each one running on a different browser. This is the kind of things you see on a desktop application but not on a web application.

This feature isn't Wisej specific as it depends on web sockets. The point is it's really easy to do it with Wisej.

[itg-assistant]

John Nagle answered 2017-05-31 02:49:55 UTC

That’s really really cool, thanks for the information Tiago! The more I use this, the more excited I get about the possibilities.