EZWeb takes approx 20 seconds for actions

[Jon Toomsen]

Running Windows 10.
I've switched pxplus from basic to web 64 bit.
Installed Webster plus using pxplus ez web server.
Update Lib and Editors.
It takes about 20 seconds to switch from inspector to setup.
Any action takes as long. When using basic did not take so long. Both versions are 2023.

[Devon Austen]

Hi Jon,

Did you just switch the license used or did you switch from 32-bit to 64-bit as well. Or did you switch to a different install?

One thought is anti-virus software could be doing scans on the new install but the old one was white listed?

[Jon Toomsen]

I switched from 32 bit to 64 bit doing a fresh install.
Other programs work well its just webster taking so long.
Disabled anti virus for a while - did not make any difference.

[Mike King]

Are you connecting to your own machine and if so what URL are you using? 

I have seen instances where Windows has issues with resolving localhost if you have both IPv4 and IPv6 enabled.
If using localhost try using the direct IP address of 127.0.0.1

The issue is that localhost often has two definitions -- one for IPv4 (127.0.0.1) and one for IPv6  (::1).  I have seen this get things confused as the browser first tries the ::1 address then the 127.0.0.1.

[Jon Toomsen]

if the Ide is not in use the ezweb actions act normally as you would expect.
if the Ide is launched the ezweb introduces a pause for actions.
The admin logon user - Last known IP address:   ::ffff:127.0.0.1 in either case.

[Mike King]

The fact that when the IDE is running you see a slowdown sounds like you are hitting the concurrent user count.  Note that windows users are not shared with Remote users as there is no way to know if the remote web user is the same user as the Windows user.

So, if using a 1 user license only one user can run at a time; running the IDE will consume the only user slot.

When Webster detects the user limit has been hit it stalls the process for between 10-20 seconds waiting for a user slot to free up.  Should a slot not free up it will let the process through rather than reporting the user limit error.  This is done so your end users (who could be anybody) won't see the problem that they could not fix anyway, they will just perceive a slow response time.

[jhendrickx00]

Hi Mike, can you explain how are handled the users in Webster+?

[Mike King]

Webster+ uses the PxPlus Web server interface which can run on EZWeb, Apache, or IIS uses a user slot for the duration of the process.  That is a user slot will be needed/allocated when the host server receives the request then freed up once the request has been completed.

When using the Web Server interface there is nothing actually running on the server until the user makes the request. 

In normal Windows/Linux processing once the user starts the application a user slot is allocated and will remain in use until they totally exit the application and all processes have completed. 

For example on Windows/Linux non-Web applications there is always at least one process running on the server and as such it requires a user slot for the duration.  When running using the Web server interface when a request is received a PxPlus process is started (using a user slot) and terminated once the response is sent.

[jhendrickx00]

 We're planning to develop a kind of widget who will be running at every desk/user (It's like a delivery control system and the want to know when the package changes its status, to take some metrics and then develop a plan to enhance the procedures), the 'problem' is: In a blink this could rise the thousand of users; some customers can have 10+ users and now there around 100 customers (and they plan to twofold the customer when the system be online... Of course, we need to tell them about the user load (for choose the [hardware] server) and the number of licenses... Any thoughts?

TIA

[Mike King]

There are a number of ways you could handle this.  You actually have two issues, one is the central server that the desktops will connect to and will serve up the status changes, the other is the software on the workstation.

For the central server you should be able to use PxPlus to handle the load.  To determine the number of concurrent users you would need to determine how long a request takes to respond and the frequency that you want workstations updated.

For the workstation this would be fairly easy to do using PxPlus however the license costs might be prohibitive.  If you find that is the case you could use something like powershell to create a workstation process or create a C, .NET or VB application to do the same. 

Now technically depending on your actual application requirements you might be able to have the host simply maintain 'status files' on the server and use Apache (or any other web service like IIS) simply serve up the status files.  PxPlus could update the status files as needed.

Last, but not least, you might be able to use Web Notifications as that may provide you the functionality you are looking for.

Of course, all of the above depends a lot on the exact needs of your application.

[Mike King]

I was thinking about your issue last night and wondering if perhaps the easiest solution for you would be to use RSS.

There are a number of free RSS readers for Windows and other platforms, many of which can reside in the task bar or run in the background and display an alert when an RSS feed changes. 

On the server you could create RSS files and have your  internet web server (Apache, IIS, etc) simply serve up the RSS file.  Depending on your needs you could have multiple RSS feeds, a global for all users, company specific feeds, even user specific feeds.  These RSS files could be updated on the server as required using PxPlus either as the events occur or by a background task.  As for load, most servers can easily handle 1000s of requests per minute if all they are doing is forwarding a data file (the RSS feed).  This avoids you having to worry about how many PxPlus licenses you might need as PxPlus would not be directly involved in the RSS request.

Of course a lot of this depends on exactly what your application requirements are, but using RSS might be a real simple solution.

BTW: Another solution might be to use something like WhatsApp to send messages.  This is something I am looking at presently.

[jhendrickx00]

Hi Mike thanks for your (very) valuable feedback; the 'background problem' can arise because some of this 'notifications' can be money-related (Money on place/The delivery took the money/Money at warehouse/Money left place X/...), and of course, this could be very atractive to someone with 'not so clear intentions', so the security is important ... we consider to develop a HTML page (no Webster/PxP+) and refresh it every 5 minutes or so, then call the Webster+page, if there changes, show the changed, update the results and be back to the 'wating page', but still we're just gathering info; my first goal was to try to keep the development with an all-pxplus solution, but perhaps using a mix one should get better results.

Jean H//

[Mike King]

That sounds like it would work.  The actual waiting page could be generated by Webster+ since a page that is being displayed and idle waiting to request an update itself would not consume a user slot.  Basically the user slot will only be used while Webster generates the page, not while its displayed.  Actually this is one of main benefits of developing using Webster+.  Less active resources used on the server.

Now if you only need to update the display every 5 minutes (300 seconds) and assuming your logic can generate the response in 1/2 second (which is likely an overkill) for 1000 users you likely only need a 2-3 user license (with 1/2 second processing 300 seconds will allow for 600 requests).

Let us know if you need any help.