 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Databases / February 2004Slow-loading drop down boxes
I'm building a data entry application using Java servlets. I had hoped to use drop down boxes to provide the user with data entry selections pulled from a database into an html form, but am now questioning, given the latency with which the data loads to the browser, whether drop down boxes are viable for providing a large number of select options. I've put identical examples of the problem on two different web/database hosts for review (I wanted to test on different hosts to rule out a problem with the database server and the web/tomcat server). One host uses SQL Server and Tomcat 3x, the other is using PostgreSQL 7.23 and Tomcat 4.124. I'd appreciate anyone who could take a look at these examples and comment on whether what I'm trying to do via drop down boxes seems feasible, and if not, well, suggestions on another tack would be welcome. Here are the two examples, but please don't be too impatient because both pages can take upwards of 10 seconds to load. http://128.32.224.162/Devt/servlet/autest http://librarian.www7.kc.aoindustries.com/servlet/autest In these two examples, the servlet has gone to the database to load the author names to a Vector, and then the author names are written to the browser by iterating through the vector three times (I am not going to the database three times). A single box using the MULTIPLE attribute will not work in this case because the sequence of the selections is significant. Also, if these option boxes are part of an edit screen, the list has one of the names pre-selected, so technically, the three lists could all be slightly different from each other. Here is the servlet code that produced the autest html above: http://128.32.224.162/misc/optionBox/aucode.html . I have read the discussion at http://www.cs.tut.fi/~jkorpela/forms/countries.html and yet cannot believe that what I'm trying to do is not being done successfully by others. Am I misguided in thinking drop down boxes are an attractive means of making these selections available to the user? Or am I just doing it wrong? Last week I posted to comp.infosystems.www.authoring.html but there's been no discussion there. If anyone over here has ideas I'd love to hear them. leigh Ps. appreciated the recent middle-tier discussion. I keep my business logic in java in the middle and have been able to move my applications pretty easily back and forth between SQL Server and PostgreSQL (platform at work vs. platform at home). My applications are comparatively small, however. I would first of all run the servlet WITHOUT drawing the drop down boxes, but still doing your database retreival. If that is fast, then you should think about using a different selection method, i.e. a search instead or a series of letters A-Z that displays everything starting with A, B etc. Very long drop down boxes become self-defeating as it takes users too long to find what they want. If it slow, even without the drop down box I would : (a) Look your indexing, use views etc - speed up the SQL (b) Perhaps vectors are slow ? All of my recent work in this kind of thing uses an array of strings (or objects) instead of a vector as you can run through that extremely fast. Best thing to do is find out what is fast, and what is slow, and go on from there. > I'm building a data entry application using Java servlets. > I had hoped to use drop down boxes to provide the user with [quoted text clipped - 55 lines] > (platform at work vs. platform at home). My applications > are comparatively small, however. > If it slow, even without the drop down box I would : > (a) Look your indexing, use views etc - speed up the SQL > (b) Perhaps vectors are slow ? All of my recent work in this kind of thing > uses an array of strings (or objects) instead of a vector as you can run > through that extremely fast. I seriously doubt switching from Vector to an array is going to matter even one bit, compared to the time it takes to make a query on the RDBMS. As Vector is basically just a wrapper around an array of Objects, the performance cost is minimal. All the methods of a Vector are synchronized though, and since you're probably only reading once it has been filled, using a non synchronized List implementation, like ArrayList for example, wouldn't hurt. But those are all micro optimizations. As you said, the OP should first of all check the speed of the actual SQL itself. > Best thing to do is find out what is fast, and what is slow, and go on > from there. >  SignatureKind regards, Christophe Vanfleteren Fair comment - I've not really used vectors much so it was a bit of a shot in the dark. As others have said, if the data retrieval and vector creation on its own is fast, then the original poster should look at how he is displaying the data. Any list that long or HTML source that big should be looked at again. > > If it slow, even without the drop down box I would : > > (a) Look your indexing, use views etc - speed up the SQL [quoted text clipped - 16 lines] > > Best thing to do is find out what is fast, and what is slow, and go on > > from there. > Fair comment - I've not really used vectors much so it was a bit of a > shot in the dark. > > As others have said, if the data retrieval and vector creation on its own > is fast, then the original poster should look at how he is displaying the > data. Any list that long or HTML source that big should be looked at again. The other thing you should try is to create a static HTML version of the same page on the same servers, and download them to your browser. It's hard for us to tell how much of the problem is network latency and how much is in database access times. Luke > The other thing you should try is to create a static HTML version of the > same page on the same servers, and download them to your browser. It's hard > for us to tell how much of the problem is network latency and how much is in > database access times. I just realised that you haven't shown us your database logic yet. Where's this "table" class? BTW, you really should capitalise your class names, you know. To follow the standards. Luke > BTW, you really should capitalise your class > names, you know. To follow the standards. I guess it shows I'm self-taught : ) Thanks for the tip on capitalization, I didn't realize there was a standard. Though actually I started with capitalized classes, and then in the process of revision, moved to lower-case to distinguish old from new. I didn't realize there was a standard. > I just realised that you haven't shown us your > database logic yet. Where's this "table" class? There's no logic in the class 'table' (it's all html formatting) but you're probably thinking of the query class, which creates sql statements, and perhaps the sql class, which sends the statements to the JDBC connection. I've copied both here: http://128.32.224.162/misc/optionBox/query.html http://128.32.224.162/misc/optionBox/sql.html I've also been double-checking my memory that the data loads super-fast if not in option boxes-- I seem to be wrong there. I put up two tests that write the data to the browser, but not in a select box. It's slow too. For the curious, here are those two tests: http://128.32.224.162/Devt/servlet/autest1 http://librarian.www7.kc.aoindustries.com/servlet/autest1 It's slow enough to make me think I was wrong in assuming the option boxes were the problem. Must mull. Thanks for all the comments, still happy to hear others, and I expect to report back on my progress... leigh > > BTW, you really should capitalise your class > > names, you know. To follow the standards. [quoted text clipped - 5 lines] > revision, moved to lower-case to distinguish old > from new. I didn't realize there was a standard. Hey me too. I was more or less case-blind when I started out, from using too many case-independent languages (like VB and Object Pascal). My C background didn't help when it came to OO paradigms. There's a document somewhere on the Sun site which describes the standards, but I don't have a link handy. Hold on (google...google...google) here it is... http://java.sun.com/docs/codeconv/ > > I just realised that you haven't shown us your > > database logic yet. Where's this "table" class? [quoted text clipped - 9 lines] > > http://128.32.224.162/misc/optionBox/sql.html Heh. Well I think I see your problem. Rather than establishing a new connection for each query, you would do well to keep a single connection open at least for the duration of the HTTP transaction, but better yet, you should use connection pooling so the connections are each only opened once for the lifecycle of the servlet. But that might be a little advanced at this stage. Try just opening your connection and result set once, and iterating through it three times (reset to the beginning using the beforeFirst method). I think you'll find that goes a lot faster. > I've also been double-checking my memory that > the data loads super-fast if not in option boxes-- [quoted text clipped - 13 lines] > hear others, and I expect to report back on > my progress... Good luck. Luke You won't believe it, but it turned out to be the Vectors I'm using!!!!!! Check this out, it only takes a couple seconds to load, and it's *five* boxes with all the original html. http://128.32.224.162/Devt/servlet/autest5 Something Luke said about messing around with the ResultSet got me thinking, and after some experiments, I've discovered is that it's actually much, much faster to work with the result set directly rather than read results into a Vector and then do manipulation. And that it's faster to go to the database five separate times to get the SAME list, than it is to go once, stick the results in a Vector, and then use the Vector for iteration through the list. Totally counter-intuitive to me. But thank god I made some progress, and I have this group to thank for that! My users thank you too! Everyone, I appreciated everyone's comments. leigh > I would first of all run the servlet WITHOUT drawing the drop down boxes, > but still doing your database retreival. [quoted text clipped - 12 lines] > Best thing to do is find out what is fast, and what is slow, and go on > from there. > You won't believe it, but it turned out to be > the Vectors I'm using!!!!!! [...] > that it's faster to go to the database five separate > times to get the SAME list, than it is to go once, > stick the results in a Vector, and then use the > Vector for iteration through the list. > > Totally counter-intuitive to me. That seems counter-intuitive to me, too. Counter-intuitive enough, in fact, that I'd start looking for fishy stuff in the way you are dealing with the Vectors. They aren't really that slow. Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> You won't believe it, but it turned out to be >> the Vectors I'm using!!!!!! [quoted text clipped - 11 lines] > fact, that I'd start looking for fishy stuff in the way you are dealing > with the Vectors. They aren't really that slow. I agree. I could imagine that there would be a small advantage to directly reading your ResultSet once instead of putting it all in a Vector. But creating a ResultSet 5 times faster than filling a Vector once, that can't be right. SignatureKind regards, Christophe Vanfleteren Well, it's good to hear this. Maybe I am doing something wrong in my use of Vectors. But they just don't seem that complicated! I read each row of the result set into an object, then stick the object in a vector. I use a for loop to iterate through the vector, casting each object as appropriate. I'll post some code in the next couple days. Cuz if I'm doing something wrong with the Vectors I'd just as soon figure it out now rather than later. thanks for the feedback! leigh >>That seems counter-intuitive to me, too. Counter-intuitive enough, in >>fact, that I'd start looking for fishy stuff in the way you are dealing [quoted text clipped - 4 lines] > creating a ResultSet 5 times faster than filling a Vector once, that can't > be right. Hey here's some Vector code if anyone is up for checking it out-- there are two code snippets, the first where I read the result set into a vector, the second where I iterate through the vector to put its contents into an option box, they're both quite short: http://128.32.224.162/misc/optionBox/vsample.html If there are any glaring (or even subtle) problems that you guys see I'd love to hear about it. I appreciate the ongoing remarks, leigh > Hey here's some Vector code if anyone is > up for checking it out-- there are two [quoted text clipped - 11 lines] > I appreciate the ongoing remarks, > leigh There's nothing too nasty there. It might be better to create an Enumerator using Vector.elements() and iterate through it rather than using the for loop, but that's not a biggy. OTOH, what about this "option" class? Maybe you've got something in there that's giving trouble. Luke > > You won't believe it, but it turned out to be > > the Vectors I'm using!!!!!! [quoted text clipped - 11 lines] > fact, that I'd start looking for fishy stuff in the way you are dealing > with the Vectors. They aren't really that slow. I suspect that's true. There's still a lot of Leigh's code that I haven't seen, like the "option" class, frex. Still, for this type of thing there is really no reason to buffer the results in a Vector, because they should be fairly effectively buffered in the database client code anyway. If nothing else, there's less coding in just reading from the ResultSet each time. Luke The Vector is slow because it has built-in synchronization. Use a java.util.List (eg. the ArrayList). Steven > You won't believe it, but it turned out to be > the Vectors I'm using!!!!!! [quoted text clipped - 37 lines] > > Best thing to do is find out what is fast, and what is slow, and go on > > from there. > I'm building a data entry application using Java servlets. > I had hoped to use drop down boxes to provide the user with [quoted text clipped - 19 lines] > > http://librarian.www7.kc.aoindustries.com/servlet/autest [snip] Given that the data for the listboxes is the bulk of the HTML, it will naturally make the page load slower. If you really plan to have three separate listboxes, each with the same data, it might be better to load the first one and then call a JavaScript method to copy the data from the first to the second and third. It's less than ideal to use client-based scripting (largely due to browser compatibility issues) but it could get you out of trouble here. Luke Hey, it's great to get some feedback! As for whether bringing the data to the browser is faster when the option boxes are not present, yes, pages that have as much data loading, but not to option boxes, are really fast. I'm pretty sure the option boxes are the culprit here. I've considered a few different schemes to get the data from the user if I can't speed up the option boxes. I could just use one pickbox with a MULTIPLE attribute, and then ask the user to sequence the authors later. This has the added advantage of not requiring an arbitrary number of permitted authors to be designated. Also I've considered JavaScript (though am unfamiliar it)-- I could just grab the resultset and then use JavaScript to set it up for the browser. It's something I should explore. Thanks for the comments! Still happy to hear any others! leigh > Given that the data for the listboxes is the bulk of the HTML, it will > naturally make the page load slower. If you really plan to have three [quoted text clipped - 5 lines] > > Luke The size of the whole page is about 177kb which is rather large for a HTML page and would load very slowly over dialup link. (Don't know what the server connection is) For me it seems to be on the server side, because if a load the whole file from harddisk it is shown in the browser nearly instantenously (IE6 and Firebird 0.7) I daubt that any copying of data via JavaScript would be any faster. Manfred > Hey, it's great to get some feedback! > [quoted text clipped - 32 lines] >> >> Luke Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.