sgoms
asked on
***URGENT*** Jrun/Servlet/SQL is very very slow!
Iam using a servlet to fetch data from a SQL 7.0 database and display it on the browser via a Excel spreadsheet.(Iam using a 'Formula One' Java bean to do that). The first time i load the servlet, a default parameter is passed to it and data is fetched and gets displayed. When i select a diff parameter thru a drop down list box to display data thru' the same servlet but on a diff worksheet it works fine. BUT, if i try to access the same worksheet again ot try to alter the parameters, all it does is 'Web site found. Waiting for reply..' and stops.
Iam using IE 5.O. Is it to do with the databse or with the worksheet?
any leads wud be appreciated. My deadline is today..so its really URGENT!
Thanks in advance.
Iam using IE 5.O. Is it to do with the databse or with the worksheet?
any leads wud be appreciated. My deadline is today..so its really URGENT!
Thanks in advance.
ASKER
I have isolated the problem to populating the grid from the database.
The worksheets does not matter. whether it be the same worksheet or a new one, if i dont populate the sheet with data its very fast..if i try to populate it then it slows down & dies!
i guess for this u shud've worked with Formula one or Excel/JDBC.. but if u can throw in any other ideas they'r welcome.
The worksheets does not matter. whether it be the same worksheet or a new one, if i dont populate the sheet with data its very fast..if i try to populate it then it slows down & dies!
i guess for this u shud've worked with Formula one or Excel/JDBC.. but if u can throw in any other ideas they'r welcome.
- Could it be something with the caching the same URLs? Servlets are normally called through with GET method which is basically a parametrized URL.
- Another idea, close the connection to the database between connections. This might lead you to the problem.
- Yet another one, copy and paste the servlet call in the browser address tab (surpass the spreadsheet component) and see whether the data that comes back does come back quickly. May be this will give you a hint where the problem is.
Nik
- Another idea, close the connection to the database between connections. This might lead you to the problem.
- Yet another one, copy and paste the servlet call in the browser address tab (surpass the spreadsheet component) and see whether the data that comes back does come back quickly. May be this will give you a hint where the problem is.
Nik
ASKER
1. No URL is not a problem 'cos when i do it without populating the databse it works fine. so the dat gets passed to the servlet thru the get method.
2. The connection gets closed bet the 2 calls. shud i or shud i not?
3. The servlet outputs the excel component so i cant surpass it!
2. The connection gets closed bet the 2 calls. shud i or shud i not?
3. The servlet outputs the excel component so i cant surpass it!
Start by isolating the problem further.
Instead of populating the grid, send the data to System.out.
Determine if whats failing is the front end or the back end.
If its the front end, try populating ony one cell, then only one row, then a few rows. Determine if the problem is related to volume.
Try instantiating a new component on the servlet each time. The component (spreadsheet) might not be garbage collected before your next call to it. Isnure that the servlet is compleatly unloaded and the grid instance is set to null between calls.
Instead of populating the grid, send the data to System.out.
Determine if whats failing is the front end or the back end.
If its the front end, try populating ony one cell, then only one row, then a few rows. Determine if the problem is related to volume.
Try instantiating a new component on the servlet each time. The component (spreadsheet) might not be garbage collected before your next call to it. Isnure that the servlet is compleatly unloaded and the grid instance is set to null between calls.
sgoms ,
Tidestone Formula 1 bean is BUGGY ,see for confirmation
cheekycj's question ,he isolated it after 1/2 months
https://www.experts-exchange.com/jsp/qShow.jsp?ta=java&qid=10235790
hope it helps you,and you change the bean to something else.
It just eats up Memory like a Hog...
his research after many days found out
We are back and alive!!! I don't know if all of you noticed but the question disappeared after the new year and we just got back.
My memory issues were mostly caused by a Java Bean called Formula1.
It is a spreadsheet bean. We were loading 403K rows and 38 cols in it.
After extensive tech. discussion with their engineers we found out that the bean allocates 44 Bytes per cell w/out any data-- Thats is 643 MB of RAM w/out any DATA!!! so when we were loading about 4 Bytes on average but we allocated 6 Bytes to be conservative and the min required memory was 731 for just the BEAN. So then adding on the application and other functions and iterations we were going through the new target machine needed about 1GB of memory to run safely. Needless to say this was not an option for us so we ripped our code apart and wrote code that would break up the history into segments and load segment at a time (partitions of 5-7 days) instead of the whole 30 days of history. We are still implementing this but it is *supposed* to fix our memory issues.
Tidestone Formula 1 bean is BUGGY ,see for confirmation
cheekycj's question ,he isolated it after 1/2 months
https://www.experts-exchange.com/jsp/qShow.jsp?ta=java&qid=10235790
hope it helps you,and you change the bean to something else.
It just eats up Memory like a Hog...
his research after many days found out
We are back and alive!!! I don't know if all of you noticed but the question disappeared after the new year and we just got back.
My memory issues were mostly caused by a Java Bean called Formula1.
It is a spreadsheet bean. We were loading 403K rows and 38 cols in it.
After extensive tech. discussion with their engineers we found out that the bean allocates 44 Bytes per cell w/out any data-- Thats is 643 MB of RAM w/out any DATA!!! so when we were loading about 4 Bytes on average but we allocated 6 Bytes to be conservative and the min required memory was 731 for just the BEAN. So then adding on the application and other functions and iterations we were going through the new target machine needed about 1GB of memory to run safely. Needless to say this was not an option for us so we ripped our code apart and wrote code that would break up the history into segments and load segment at a time (partitions of 5-7 days) instead of the whole 30 days of history. We are still implementing this but it is *supposed* to fix our memory issues.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I contacted the Tidestone tech engineers regarding this problem. Yups..todestone has a problem with populating the grid fast 'cos it takes some time to check the existing contents of the cell(its formula, font etc..) and then popuulates it. so it obviously takes some time.
for the mmt 'cos its the prototype we will be going along with this. and maybe later we can locate a more efficient one.
Thanks experts!
for the mmt 'cos its the prototype we will be going along with this. and maybe later we can locate a more efficient one.
Thanks experts!
ASKER
Iam out of the project which needed 'Check if my system is connected to the Net ?' so i deleted it. ;-)
well can u give points b4 u finish this project ?
:)
:)
ASKER
;-)
iam done with my work..but 'cos i sortof solved it on my own iam kinda confused as to who to give the points to..
iam done with my work..but 'cos i sortof solved it on my own iam kinda confused as to who to give the points to..
anybody will do but do distribute it to somebody or a bunch of guys...
:)
:)
If you solved it yourself, perhaps you should just delete the question.
ASKER
Ur comment lead me to contacting the support engg & conclude that Formula One has a performance issue.
Thanks.
Thanks.
Nik