PDA

View Full Version : Web App Speed problem.



colw
12-Aug-2022, 01:51 AM
Hi all, not sure if this is in the right forum but here goes. I seem to have a speed issue with Webapp that someone might be able to help me with.

I am exploring Studio 20.1 (64bit/Unicode) under windows 10 using a Postgresql UTF8 database on another server via ODBC 64bit.

I have a single table of country names (approx 250 records).

A simple grid in a windows app runs fine (down arrow scrolls to the last record in the table in about 10 seconds) however the same grid in a web app takes about a second to go from one line to the next. I am at a loss as to know why. I have back ported the same code into a Studio 19.0 32bit install and it runs fine (both windows and web app).

Any ideas will be appreciated. I have checked process pooling and it is set on.

Unrelated but also, I notice that dbbuilder cannot open a table that contains an overlap field in the INT file, it crashes with out error. Presumably this is not supported any more?

Thanks Col.

Marcia Booth
12-Aug-2022, 11:48 AM
Hi Col,


I am exploring Studio 20.1 (64bit/Unicode) under windows 10 using a Postgresql UTF8 database on another server via ODBC 64bit.

I have a single table of country names (approx 250 records).

I have DF 20.1 using PostgreSQL 14 accessing country (109 rows) from the sample dvdrental UTF8 database on a separate server. I use PostgreSQL 64-bit ODBC Unicode driver in the DSN. I created a webapp and a view/lookup for the country table and was not able to reproduce the delay you are reporting.

Does your webapp share the same workspace and INTs/CCHs as the Windows application? Is this delay happening only when accessing the country table or any table in that database?

colw
14-Aug-2022, 08:17 PM
Thanks Marcia for the prompt response.

Assuming I have an issue somewhere I am going to create a new PG database with just the Countries table. Then I will create a new workspace with a Windows and Web project containing the comparable views. I will let you know how I get on.

Col.

colw
15-Aug-2022, 03:42 AM
Hi Marcia,

So an update on my testing so far. The test I proposed above was completed and worked fine so it does seem to be performing well.

So I then went back to the original scenario to try and figure out why it is so slow.

After several hours and many dead ends it does seems like it slows dramatically when the WebServerProps table is in the PG database, whereas if it is embedded it runs fine. I am not sure why this is so, but I also notice that it is writing many more records into WebServerProps. Just opening up in a browser and selecting the panel puts 80+ records into WebServerProps! My Test one has only 1. Again I am not sure why that is so, but at one point there were 15,000+ records in Web Server Props. None of them are from me.

To summarise:-

- Windows app using cDbCJGrid works fine.
- Web App using cWebGrid is very slow. But moving the Webserverprops to embedded it works fine.

Both of above worked fine when using 19.0

Hopefully, you can shed some light on why?

Thanks,
Col.

Samuel Pizarro
15-Aug-2022, 09:02 AM
Just opening up in a browser and selecting the panel puts 80+ records into WebServerProps!

if you repeat it from the same session, it creates these new records every single time, over and over!?

Marcia Booth
15-Aug-2022, 03:12 PM
Hi Col,

In my test I have all tables in PostgreSQL and no performance problem. In your test workspace (the one you created for Country table only, where everything works fine), is webappserverprops a DataFlex or PostgreSQL table? IOW, do you only see the issue in your original workspace?

Here's the INT from my webappserverprops. Is that similar to what you have in your workspace?

colw
15-Aug-2022, 05:45 PM
Marcia,

Thanks for your continued help.

Your int file pointed me in the right direction. Closer examination of the data, I noticed that the 'data' field in WebAppServerProps was ASC 16, not Text 14336. I guess there must be an overflow process that was writing many records instead of 1, and why the cWebGrid was then reading all those records back on every down arrow. Also hence why the cWebPromptList did not have the same problem coz it did not need to reread Webserverprops!!.

So it does appear that the speed issue is solved. I am not sure how the data field type/size got changed but the PG database was loaded from a SQL backup, so I am going to backtrack to see if I can find out?

Also, I have had a couple of other crashes during this process as I have done numerous database conversions over the last few days. I will try and duplicate them if I can and provide documentation.

Thanks again for you help.
Col.

colw
15-Aug-2022, 05:48 PM
Samuel,

It was doing it for every new session. I have resolved it though. See my response to Marcia.

Col.

Samuel Pizarro
15-Aug-2022, 06:56 PM
Great!

Marcia Booth
15-Aug-2022, 07:29 PM
Super! I'm glad to hear that you were able to get that resolved. A few things to keep in mind about WebAppServerProps (https://docs.dataaccess.com/dataflexhelp/#t=mergedProjects%2FTools%2FWebProperty_class_memb er_meta-data_tag.htm):



By default this is an embedded table but it is advised to convert this table to the database being used by the rest of the application.
It is advised to increase the size of the data field when the database allows this.
The table contains an ExpiresDate field that can be used for automated cleanup of the data as the framework will not delete records by itself. It is advised to schedule a job inside SQL server to do this.

colw
16-Aug-2022, 01:31 AM
Marcia,

Ok, it is all becoming so very clear!!

The original data was in MS SQL Server and field 'data' was type Text and over 1Mb in size. It was converted back to embedded on the way to moving it to Postgres. That conversion changed the type to ASC 16 (I guess the embedded did not know what else to do with that size) and it stayed at that all the way through.

Such a simple thing really but so many hours to find!!

Still hopefully it might help some else. On a positive note it is a testament to Dataflex that with a few mouse clicks the entire system is working on a different database.

Thanks again for your help,
Col.

Marcia Booth
16-Aug-2022, 12:17 PM
Hi Col,

Thanks for the update.

For future reference, you don't need to go back to DataFlex database in order to move your tables to a different backend. You can convert from one backend straight to another - e.g. SQL Server (MSSQLDRV) to PostgreSQL or MySQL (ODBC_DRV) - using our conversion wizard. :)

Awesome to hear that your system is up and running on the new database!