PxPlus User Forum

Twitter Twitter Twitter

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - martinp

Pages: [1] 2
Web Services / Re: Pvxweb File Upload
« on: March 29, 2022, 10:43:44 AM »
Thanks for the ideas Mike!  Perfect.


Web Services / Pvxweb File Upload
« on: March 26, 2022, 05:28:17 PM »
Is there a way to receive a file with the pvxweb server?  (Web browser uploads file to pvxweb serevr)

I was able to do it by using apache and PHP, but I was curious if I can handle the POST of the binary file through the pvxweb server alone?


Thin Client/WindX / Windows 11 - strange window sizes with older windx/
« on: December 06, 2021, 11:51:43 AM »
Having lots of issues with an older pvx 5.14 windx on windows 11.  Anyone else notice this as well?  Mostly maximizing, extends larger than the screen all the time.

I tried the newer windx which helped running on older server.  I guess its time to upgrade? :) 

Great release!  How many users (using Webster+) for example a 2-3 license support comfortably?   Is this similar to the pvxplus web server task handler in terms of capability?  I'd imagine the pvxweb server is slightly more responsive but I am interested.  Thanks.

Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 10:38:50 PM »
Bingo!  We got it Mike!

I can't believe the performance hit this has resulted in.

There are ways to disable the fixes on the linux kernel which are available by research but I won't post those there due to security.  However I am glad the reason was found.  I am personally surprised at the level of impact it has on pvx.  It's probably because pvx is so fast as well that its a full single thread process that any delays are exasperated.

I had updated my ubuntu16 test machine and afterwards it too was patched and began to have the slow down.

Even though the test example I gave was an extreme case, I did notice a noticeable performance hit across the board.  Now in order to overcome these fixes, one needs to purchase newer hardware that are not affected by these security flaws.

Thanks again for your help on this, I'm not sure if this will help others or just help answer my stubbornness to understand the issue.  At least I have some baselines and examples to compare with now.

Have a great new years :)

Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 07:19:52 PM »
I also did another test by creating a ramdisk and transferred the test file to the ramdisk and the results were exactly as when the file is fully cached, no improvement.

I looked into some of the kernel tuning parameters, and I can't find anything to really get this to go any faster like the earlier kernels.

Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 04:05:35 PM »
Thanks Mike, I checked the free -m on two of them both appear to fill up the cash properly during the test and remain as I re-test.  I see no disk access during the tests.

The reason I am reporting this, is I notice across the board performance reduction, though it may not be as 'apparent' to the average user.

ubuntu 12:

             total       used       free     shared    buffers     cached
Mem:          7890       1056       6834          0         17        883
-/+ buffers/cache:        155       7735
Swap:         8092          0       8092

ubuntu 20:

              total        used        free      shared  buff/cache   available
Mem:           7865         171        6688           2        1005        7447
Swap:          8191           0        8191

Programming / New Linux Versions = Decreased performance?
« on: December 29, 2020, 02:04:58 PM »
Hey everyone, I am in the process of upgrading one of our servers and I have noticed a decrease in performance from newer versions of Linux.

To perform this test I have a large file and doing a basic read cycle test.  The file contains:

     Maximum Record size ..........: 256 (Variable)
     Maximum # records ............: (No limit)
     Current # records ............: 1867559
     Size of key block ............: 4096 bytes
     Record Expansion factor ......: 10%
     External key size ............: 0
     Alt. key 0 ...................: [1:1:6]+[2:1:8]+[3:1:2]+[4:1:3]+[5:1:5]+[6:1:2]+[7:1:16]

Read Cycle Program:

0010 BEGIN
0020 PRINT DTE(0:"%hz:%mz:%sz")
0030 OPEN (1)"/home/martin/TESTFILE"
0040 LET X$=KEY(1,END=0099)
0050 READ (1,KEY=X$)A$
0060 T++
0070 GOTO 0040
0099 PRINT DTE(0:"%hz:%mz:%sz")

The important part of this test is that it is to be run *MULTIPLE* times to fill the memory.  Usually two passes complete filling the memory.  Afterwards zero disk access is used, it's all memory based.  This eliminates the disk-io variable from the test.

Test Results:

Code: [Select]

ubuntu server 10.04 = 9 seconds 2.6.32-38-server
ubuntu server 12.04 = 9 seconds 3.2.0-23-generic
ubuntu server 16.04 = 9 seconds 4.4.0-21-generic
ubuntu server 18.04 = 14 seconds 4.15.0-128-generic #131 (running pxp for ub16)
ubuntu server 20.04 = 14 seconds 5.4.0-58-generic #64

debian 10 = 14 seconds 4.19.0-13-amd64

windows10 = 11 seconds  20H2 - 19042.685

All tests were done with pvx17 64-bit and the same hardware, however I've seen the same results with older providex as well.

So my current conclusions are something has happened around the 4.4+ kernel that seems to be causing this as you can see a 5 second difference between 16.04 and 18.04.  I'm not sure what the solution is yet, as I have just discovered this after numerous tests, I'd like to hear from the staff at pvxplus before I do any more tests.

Thanks for any thoughts,

Devon, Just related to this, was the Esc key also trapped at some point?  It also used to close windows as well.



Thin Client/WindX / Re: winproc.rsz performance - increasing speed
« on: December 21, 2020, 12:33:27 PM »
Thanks Mike, for commenting.  We are using the 'TU' turbo mode and I tried the new '+W' compression. 

PS.  I could prepare a video comparing the two performances if it would be of value.

Thin Client/WindX / winproc.rsz performance - increasing speed
« on: December 21, 2020, 10:18:47 AM »
Hi, I am still noticing significant performance issues with the *winproc.rsz screen and *winproc.  I've seen this issue in all the PVX routines since version 5 and it's never been addressed.  In fact the performance is getting slower and slower as more features get added, which is both understandable but also concerning.

This is mostly due to having a panel that is resized on start up with the *winpnl functionality and an automatically 'maximized' window.  (There are a few other routines in *winproc that can help as well)

Removing the GOSUB CHECK_MANUAL_MANIPULATION almost doubles the speed right away which is a great improvement (if you do not need that functionality)

If you are testing this on a local network you will not experience this as bad however its slightly visible.

On an internet connection it is very apparent (even a fast low latency connection). 

With my panel example (Folder panel, automatically maximized via *winpnl)

Currently:  pxplus has an 8 second delay.
Currently:  pxplus with check_manual_manipulation removed:  4 seconds
Older PVX5.14:  My screens at a snappy 2 second delay.

This is easily reproduced on the simple client server.

Thinking forward, perhaps I can eliminate the maximize feature and redraw the screen at a higher resolution however it would be nice if the response/packets could be improved.  It's been many years and the problem is still there.

Thanks for your time.

Thanks Devon!

Devon, Thanks for responding however, that was not the answer I was expecting.  I've been using pvx for over 20 years.  Sometimes I close the window that way.  Please show me one windows application that cannot be closed in such a way?

Regarding efficiency, if my mouse is already on that side of the screen, then moving the mouse to the opposite side of the screen is less efficient.

Programming / Can't close window/dialogue (double clicking top-left box)
« on: December 13, 2020, 10:48:46 PM »
Hello, I'm testing pxplus 2020 v17.10 and I am seeing strange behaviour that was not in my older versions.  Double clicking the top-LEFT box on the windows do not close the dialogue/window.

Works sometimes,  most often not.

Simple example:

0010 BEGIN
0020 PRINT 'DIALOGUE'(1,1,20,10,"Test"),
0030 INPUT *

Tested both windows/linux, same behaviour with local and Simple client server.  PC windows: win 10 pro - build 20H2


Programming / Am I the only one still using PVX 5.14? :)
« on: November 08, 2018, 09:36:32 AM »
Hey everyone!  Am I the only one still using PVX 5.14? :) 

We do have one pvxplus license that we use as a web server but our main software still runs off 5.14...  This version was so rock solid that it's still going strong after all these years.. 

I've been able to call into the pvxplus web server for PDF printing and we use ODBC for any SQL interfaces and haven't needed to upgrade after all this time.

We did not go the iNomads route but chose to develop straight HTML for the web client access, but our back-end still using pvx5.14

Anyone else on this platform?

Pages: [1] 2