I ran a test app (master - detail - 4(!) sub-details) on a Tomcat installation on the DB server itself and on a separatly installed Tomcat machine (still the same Gbit LAN as the DB) and found no noticable difference in reaction time.

=> the speed of the Tomcat - to - DBserver connection is not relevant for app speed

I can disable the 4 sub details but the lag of key-down at the master panel doesn't change a lot, when going from 4 queries refreshed to just one.

=> the number of synchronized details, too, is not a major field of concern (with is very cool)

Hence: what can we do to tune the internal working of formspider? (indexes, indexonly tables..)

ressource consumption findings so far, in decreasing effect:

 1. insert into t_bdf_websession_log  (physical I/O)
 2. one of my PL/SQL master detail row change procs
 3. select longname from javasnm$ (ORACLE prob w/ java objectnames being long the 32chars)
 4. one of my PL/SQL master detail sync procs
 5. BDFEngine.mainforAS
 6. update T_BDF_Applicationsession (physical I/O!, weird)
 7. SELECT DISTINCT BDF_SUBPANELINS_OID
 8. ....

Number 3 is ORACLE's "fault". Number 2 is me calling formspider APIs to do work. Number 1 and number 6 do phsyical I/O and are from formspider.

This ranking chance slightly over time (I'm along on the machine, huuuge PGA and SGA)

Can we disable 1 ? (or does formspider need the websession_log)

BUT the most active process is the logwriter (36%).

In an environment where the users doesn't do a single modification this is not ideal.

Any chance to make formspider non-writing (committing), except when the USER modifies something ?

asked 08 Dec '14, 05:12

dipr's gravatar image

dipr
1561327
accept rate: 0%

edited 08 Dec '14, 05:55


Hi Paul,

The writing to t_bdf_websession_log can be turned off. No problem.

Formspider issues commits in autonomous transactions. So the user transaction is never committed. You can do DML in the database and unless you commit it yourself, Formspider will never commit it for you.

Formspider issues autonomous transaction commits when you run the executeQuery API, set API's and make a reference to a Panel the very first time. There are ways to reduce these commits but we never needed them because they never caused any performance problems. Formspider is used in systems with a lot of concurrent users and we never really had any performance issue related to this.

Does your system have a lot of concurrent users like thousands or even tens of thousands that you worry about this?

Kind Regards
Yalim

link

answered 08 Dec '14, 06:29

Yalim's gravatar image

Yalim ♦♦
2.8k5
accept rate: 21%

No way, the worst case is 100 internal office and warehouse workers + a couple concurrent WebShop Users and at-customer-site ServiceReps (via iPads).

I was just worried, that with deploying formspider, all userinterface round-trips actions become DB-transactions!

But I think I see your issue: in stateless formspider you query a page and save the rows to the "DB buffer" of the datasource (autonomous commit), closing cursors and cleaning up. When the user wants "the next page" your rerun the same query from beginning(!), skip the first X rows and save the next batch to be displayed, close the query cursor + commit. For every "next page"...

Do you plan for statefull formspider 1.9, in utilizing the advantages of ORACLE session state, to use an OPEN cursor per datasource, from page to page REALLY only "fetching as needed"? In my eyes that would be the "correct" infinite scroll + fetch as needed, closing the cursor only at clear/executeQuery or session timeout. That way people could scroll down as much as they want, while the 99% cases (top 10 rows) don't need to "Query All", saving a lot of unnecessary work. And, w/o requerying while paging, the result would be read-consistent!

(08 Dec '14, 06:48) dipr
1

This depends on the hardware set up but assuming the current set up is not maxed out or anything you should be fine with Formspider and 100 users. This is a non-issue.

With Formspider 1.9 developers will be able to run their applications stateful. We will not start taking advantage of this in other areas of Formspider in 1.9.

We'll deliver this feature and see how it is received. If we think it'll help developers, we can start taking advatange of stateful implementation in other areas.

We can put more of the application state in memory (datasources, panels etc...) when the applications runs stateful. We can also do a "correct" implementation of infinite scroll. We'll see how it goes.

(08 Dec '14, 07:12) Yalim ♦♦

Wow, that would be awesome! Put down my vote for going stateful. I'd advertise "stateless Formspider" as "designed for the Internet" with users comming and leaving, w/o plan, and "stateful Formspider" as "ORACLE Forms successor for desktop office work".

(08 Dec '14, 09:05) dipr

Hi Paul,

Aside from obvious best practices, the single best thing you can do is to add more memory to your Oracle Database Server and make sure it gets used by the database.

We ship Formspider the best way we know how to make it fast (proper indexes etc...) so I don't know what else to tell you. We never really had a big performance problem with our customers. The one case I remember is a thread on this Q&A site. Here is the link:

http://osqa.theformspider.com/questions/2883/oracle-db-active-sessions-waiting-application

As you can see on the thread, the issue was resolved and since then we updated Formspider and added the missing 2 indexes.

Kind Regards,
Yalim

link

answered 08 Dec '14, 05:49

Yalim's gravatar image

Yalim ♦♦
2.8k5
accept rate: 21%

Okay. Seems to be very well behaved, out of the box.

But what about formspider generating transactions when the user does not? If many users (read WebShop customers) click around the Logwriter will be very busy logging formspider transactions, when there are actually NO user transactions!

Come to think of it, that might be the reason for the "constant offset lag" that I see. Every roundtrip to a READING user session results in formspider WRITING a transaction (=> logwriter work) that is committed (=> synchronously waiting for disk to finish!)

I really would like to switch off formspider's writing unless there is a user transaction.

link

answered 08 Dec '14, 05:59

dipr's gravatar image

dipr
1561327
accept rate: 0%

edited 08 Dec '14, 06:06

Hi,

How to disable formspider log writing?

George

(14 Jan '15, 11:50) grajan777

Only by not starting transactions. Every write will need a commit and this trigger logwriter, no way around that, and that is good, mind you. What I'd WANT is a Formspider that does NOT write anything when neither the user nor my PL/SQL procs change data. Seems Formspider still has some way to go to catch up with ORACLE Forms :)

(14 Jan '15, 12:05) dipr
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×2
×2

Asked: 08 Dec '14, 05:12

Seen: 2,100 times

Last updated: 14 Jan '15, 12:05


© Copyright Gerger 2017