Jump to content

How scalable is UniGui?


Mike O.

Recommended Posts

I haven't used uniGui but before I get my hopes up, I'd like to know if it can scale.

 

For example.

 

How many concurrent users can a web server support at a time? 10? 50? 100? 500? How much memory does it consume per connection?

Is it stateless?

How many page views per second can it produce (excluding db access times)?

Does it have page caching?

Will it run on a server farm? For example. Can I have 10 web servers all connected to a central database server? And will the session data be centrally located? Or is the session data stored on the web server that initiated the session?

 

TIA

Mike

Link to comment
Share on other sites

  • Administrators

Scalability is an important aspect of a web server which must be taken seriously. I'll try to explain in detail.

 

 

An atomic uniGUI app containing a single MainForm only consumes a few KB of memory per session. As developer adds new components to Form and datamodules per-session memory usage starts to increase. uniGUI apps are fully stateful. Each session stays in server memory space as long as that session is active. Once that session is terminated the memory is returned to server memory pool. Each component such as a Button has a shadow in server which stores all the properties and "state" information. Stateful apps are easier to develop, as developers shouldn't take care of handling state info. The price paid here is more memory usage which increases in parallel with number of sessions. Developers must take care of per session memory usage if number of sessions will be more than 100 sessions. If each session consumes one megabyte then 1000 sessions will sum up more than one gigabyte which is not good for a 32-bit server. If Embarcadero delivers a 64-bit Delphi soon then we can hope that the memory barrier will no longer be an issue here. A 64-bit server can use all available server memory so number of sessions may not be no longer an issue.

 

On the contrary stateless apps do not have in memory sessions and server doesn't store a single bit of in-memory state information of any sort. If there are any state information they must be handled by the app itself. There are several techniques to save state information in a stateless environment such as ASP.net and PHP. View state, cookies, db tables, text files and etc are off-server methods used to keep state information. uniGUI apps don't need any of these techniques to save state because current state is already there in server memory. This makes developing uniGUI apps much easier because you can develop apps in classical RAD way without a need to develop extra techniques to keep track of state, but again as stated in above there is a price to pay for this: more memory usage.

 

Memory usage is not the only problem here. Another problem that we may face is OS handles. Here I'm talking about GDI handles which are a limited resource in Windows OS family. uniGUI is designed to have a minimal use of GDI handles where possible but some components can't function without GDI handles. For example a TBitmap uses GDI handles to keep, convert and modify bitmaps. If each session uses lots of GDI handles there is a chance that your app may run out of handles when there are say 1.000 active sessions. This may even happen much sooner than you run out of memory. UniGUI core components will be designed to use as less as handles as possible. We will implement our own TUniImageList instead of default TImageList because TImageList can use lots of handles.

 

However, we can't control handle usage of 3rd party components and other user components. For example almost all Delphi reporting tools claim to be multi-thread ready, but a closer look shows that it is not correct. Many of such tools use some dirty hacks to solve multi-threading issues. A deeper look reveals that such tools extensively use GDI handles to render report pages. This means that they can easily overrun OS handles if there are 100 simultaneous reports being prepared. The only solution for this is to use a report server which runs in a separate process and communicate with uniUGI apps using various inter-process communication methods.

 

Load balancing is another issue. uniGUI apps can be load balanced. To achieve this a specialized load-balancer application is needed. Load balance app will recognize uniGUI web requests and after extracting the session info, request will be redirected to server which is keeping the state for that session. Each request should be redirected to the server which has initiated that particular session. Requests can not wander around different servers as it is possible in a stateless server farm. All these may make load-balancing a bit more complex, but it is achievable.

 

As you can see there is a big difference between developing a uniGUI server which will serve 100 sessions and a uniGUI which will serve thousands of simultaneous sessions. In first case you will simply develop and deploy the app, but for 2nd case you should carefully design the server keeping all above issues in mind.

  • Upvote 1
Link to comment
Share on other sites

Farshad,

Thanks for the detailed response. :)

 

I don't understand why the server is using actual controls to store the state instead of using a simple TList or JSON array to handle all of the session data.

 

Mike

Link to comment
Share on other sites

  • Administrators

State data are not limited to visual controls only. All user variables, Forms, data modules, DataSets, data connections, other non-visual components and etc. all together build a very complex state for current session which can only be kept inside memory. While more memory usage is a disadvantage here, there is a big advantage here in favor of stateful apps. uniGUI apps consume much less CPU and bandwidth usage compared to a stateless application. In a stateless application state info should travel back and forth between server and client. Each time a request is received session should be built using these state info which highly increases CPU and bandwidth usage. In a UniGUI app each Ajax calls send as few data packets as possible. There is no repeated traffic or state data inside an Ajax request packet.

 

I've seen ASP.NET applications with view state streams in magnitude of tens of KB which travels back and forth each time user sends a new request.

  • Upvote 1
Link to comment
Share on other sites

Hi Farshad,

That's a good article especially for GDI usage, it's a good thing if it was published as a UniGUI documentation,

and as I've said Fast-CGI is more important for this scenario.

 

To Mike,

By the way, for real world application developers should take care of a memory used by them-self as first stage.

To reduce a memory used per session and to increase overall of ability a real usage of physical memory, and for load balancing we can distributed an application out of process of web server, even if we can make native 64-bit for Delphi, but it was limited for a single web server. It is a good idea to redistribute an application to another process or another machine.

Link to comment
Share on other sites

I have 4 uni apps as ISAPI modules running for 1 month on 2 different 2003 servers, no problems so far, no memory leaks, no loose files, and a peak amount of concurrent sessions was around 200 (I count subfolders inside cache folder). Apps work with SQL Server 2005 through standard ADO components. So Farshad is right "In first case (not much sessions) you will simply develop and deploy the app".

My only complain is "session timeout" messages in log files, they are useless without IP (and even with IP too I guess). Is it possible to add periodical logging of concurrent sessions, like every hour... and perhaps have some log settings in ServerModule?

Link to comment
Share on other sites

Hello !!!!

 

I was out some days caused by a problem with my home router.

 

I read the thread entire and I think is a very good theme to know and/or discuss. I had the same questions like Mike and I expected the same answers from Farshad. So thank you both you for that and for all people that contribute to know about these issues (memory usages, sent and recieved informations between Client and Server, and so on). We are so interested in this framework, also we would like to use it in mobile applications, i.e. to use with router with sim cards. For example, we test some simple apps made with UniGUI and they work better with 3G than with 2G. modems/routers. So any knowledge of the general form of work of UniGUI framework will help in the development of future applications. So thanks to Montri and Zilav too.

Link to comment
Share on other sites

State data are not limited to visual controls only. All user variables, Forms, data modules, DataSets, data connections, other non-visual components and etc. all together build a very complex state for current session which can only be kept inside memory. While more memory usage is a disadvantage here, there is a big advantage here in favor of stateful apps. uniGUI apps consume much less CPU and bandwidth usage compared to a stateless application. In a stateless application state info should travel back and forth between server and client. Each time a request is received session should be built using these state info which highly increases CPU and bandwidth usage. In a UniGUI app each Ajax calls send as few data packets as possible. There is no repeated traffic or state data inside an Ajax request packet.

 

I've seen ASP.NET applications with view state streams in magnitude of tens of KB which travels back and forth each time user sends a new request.

 

As they say, "proof is in the pudding". :)

 

Someone is going to have to stress test an application with Unigui on a webserver to see how many connections it can support and how much CPU and memory is needed for each connection. There is an excellent stress test software called StresStimulus Web Load Testing that works with Fiddler (both are free). They will show you in real time the memory and pageviews/sec etc. using only local machines. This is a "must do" BEFORE releasing a webserver into the wild. :)

 

Mike

Link to comment
Share on other sites

  • 2 years later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...