Contributions
loadUI 2.0 Stats Workbench feedback
Top ten gripes about the Statistics Workbench after intensive use of loadUI 2.0 Pro in an ecommerce setting. 1. There should be one button control to put all graphs in the statistics workbench in the same PRECISE zoom and range. ONE. BUTTON. EXACTLY IN SYNC. Right now you can set two graphs to 'seconds' and one will scale to minutes and the other will auto-range to about a 25-second span as expected. I like the idea of having seconds-level resolution while seeing 5 minutes of data with by-second updates, but it REALLY needs it to be consistent across graphs. I suspect there's a bug in there somewhere, but while you're at it - make it so that humans using logic can comprehend the application. 2. There should be ONE button on each graph that selects it for deletion - NOT - clicking ANYWHERE on the graph 'tells' the UI that you're about to drag it to the garbage can. Drag and drop might have been a fun exercise for those learning JavaFX, but it's a truly silly 'feature' for a tool that's about precision. This is made the app maddeningly difficult to manage when running tests through a Remote Desktop Connection into a controller that's co-located with the performance test environment. With the ENTIRE app looking to pick up click/drag and drop actions I can't get anything useful done without being VERY VERY VERY VERY VERY VERY VERY CAREFUL about where I click on the screen. If I release the mouse at a time when the RDC connection "thinks" I didn't release the mouse click then suddenly the graph is ghosting under the mouse and is getting dragged all over the screen. Aside from being amazingly annoying, it can be VERY VERY VERY VERY VERY difficult to release - and sometimes it disappears altogether because the workbench 'thinks' I meant to drag it to the trash can. 3. User should be able to mouse over/right click on the graph legend to see *what* exactly is being traced. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at) 4. Zoom Tool needed: The user should be able to 'draw' (by click and drag) an X-Y grid/box over an area of a graph to zoom in (essentially 'breaking' zoom/follow sync with other graphs) to view an area in detail. Then, the 'Sync' button should snap the zoomed graph back to tracking with the baseline zoom/follow setting. (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at) 5. Graphs should be re-sizable. Seriously. The children's toy UI for this app makes me want to slap the first European software designer I see. Fortunately there are only French Canadians in the office from time to time - and they merely rate an aggressive look to keep them in line. But seriously - again - there should be a button/control/handle to collapse/expand the graph to a Y-scale that's useful to the user (i.e. I want to see more graphs at once) (see comment above about the silliness of using any click over a graph to mean you want to trash the object you're looking at) 6. Graphs should be 0-scalable. Wow. Really? Do I have to state this 'out loud'? 7. Graphs should have an option to 'lock' the scale baseline (Y-axis start point) at the outset of the test run. 8. Monitors in the Components views should take the (unique) name given to them when they're created. I have four app servers that I'm monitoring via SNMP and the component drop-down doesn't show me WHICH app server I'm graphing. THIS. IS. INSANITY.[/font:37638p7f] Aside from the annoyance, it robs me of the chance to have stacked graphs where the style is aligned per app server across separate graphs (one for CPU, one for IO, one for disc, etc) WE HAVE TO SHOW THESE GRAPHS TO OTHER USERS WHO NEED TO BE ABLE TO FOLLOW THE LOGIC EASILY. THIS. IS. TOO. DIFFICULT. WITH. LOADUI. I had to invest a considerable amount of time extracting raw data and curating/graphing it in Excel to get an executive to look at any work product. Furthermore, it's IMPOSSIBLE to convince an operations manager that the Netscaler is misconfigured when EVERY CHART has a different color assigned to a particular app server. These missing details exact a specific opportunity cost that robs loadUI of potential value as a tool to communicate to other working groups. The reporting is something I'm not even going to comment about here. I'll save that for another post. In short, SPEED KILLS CONSISTENCY MATTERS 9. There really need to be a split-pane view between the primary loadUI interface and the Stats Workbench. I spent a LOT of time just trying to get to the point where I could have *just* the right graph in view so that I could context-switch to the primary loadUI interface and make changes to the Generators. MORE. INSANITY.[/font:37638p7f] Extra credit goes to putting the VU Gen controls directly on the Stats Workbench main view to control load drive while looking at graphs without switching app views/context. Dare I dream? 10. The Stats Workbench should manage JVM memory better. If it starts to run out of headroom - it should 'trap' and warn the user to either stop the test or some other action that will load data. I had a 35-minute run that was critically important - getting really good findings - on the day of a go-no-go decision. The Status workbench crapped out when I tried to generate a report, and after reloading the app the previous run data would not run/load so I 1) couldn't see the data, and 2) couldn't generate a report from the app. I was able to extract the raw data and graph in Excel - but again, this is time-consuming. I think there are bugs in this area that can and should be addressed.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.3KViews0likes0CommentsExtend loadUI 2.0 JVM settings on Windows Controller
I'm running on a Windows controller with 4GB of memory. I have 35-minute runs of my test (to go through cache resets several times) and have a LOT of data to collect and report on. There are times when the report just DOESN'T generate. I suspect that the JVM is at its memory limit and cannot render the report. (though it seems to try but come back with no report - as though I hadn't selected the report icon [and OK button] at all) I've tried to change the values in the sjvm and .bat files - but that just causes an error. Please help with specific steps to increase the JVM settings SAFELY on a Windows controller. (could it be about re-saving as a certain file type? Encoding? I give up) Thanks.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews0likes1CommentloadUI 2 stats workbench largely broken
Both in the production and Apr4 snapshot of loadUI the Statistics Workbench is broken. I think it's brittleness largely due to the JVM space being too small for long runs. (30-35 minutes) But - even after a clean shut-down of loadUI and restarting the app - just going to the Statistics Workbench and trying to load an old data set - NONE of the values graph. This is in Windows primarily - but I've also seen this on Mac. This means that anything having to do with comparison or reloading old runs is USELESS. That makes loadUI largely useless. Seriously. I'm left with a LOT of lift in exporting the raw data and parsing everything out into charts in Excel - not fun - not fast - not pretty. Actually - charts in Excel rock - mainly because they're zero-scaled, can be re-sized and have a lot of flexibility in presentation. This area in loadUI needs a ***LOT*** of work.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews0likes1Commentdrag and drop of MySQL instance does NOT create CHART
You cannot drag a MySQL monitor to create a new CHART lane in the Statistics Workbench (Mac). You *can* however add it to an existing chart. For now my workaround is to create a chart by dragging a Tomcat monitor to create the new lane. Then deleting the two default Statistics it auto-instantiates. Then I drag the MySQL object over that chart (to create a "group") and then add Statistics from there. Kind of a kludge, but it works.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions2KViews0likes0Commentsbeta 2 not populating dependencies into agents
I sent an email to support about this - but thought I'd echo it here. I have a simple test that uses a Groovy script to call into an XML file to find a data element at random and then pass it into a test case-level property that is then expanded by the RESTful call into the service I'm testing. This is a basic cache-busting strategy. When running the test locally in loadUI (on the controller) no problem. But when sending the VU scenario out to the agents, it all goes awry. As it turns out - the XML file that is used for retrieving the data element is NOT pushed out to the agents. I know this because when I put the file directly in the /.loadUI/fileStorage folder on the agents SUDDENLY the tests started working in distributed mode. So - there ya go - that's my contribution to this beta. :-) You're welcome. (two working days of my life I'll never get back) // standard context call def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context ) // general threadid set for logging - should be in every script def threadId = Thread.currentThread().getId() as String // set the project path def projectPath = groovyUtils.projectPath //Define a file pointer for groovy to handle the file operations. def File inputFile = new File(projectPath + "/SOLR_output.xml") if(!inputFile.exists()) { testRunner.fail("Input File Not Found.") } else { //Read and parse XML file and store it into a variable def InputXML = new XmlParser().parse(inputFile) //get number of Events from a single element in the SOLR result def numberOfEventsArray = InputXML.result.@numFound def numberOfEvents = numberOfEventsArray.get(0) as Integer // generate a randomized value based on the number of events def randomEvent = (int)Math.random() * (numberOfEvents.value) // retrieve the EventID of the randomly selected value def selectedEvent = InputXML.result.doc[randomEvent].str.text() // log the values retrieved to the console log.info "[${threadId}] Event [${randomEvent}] ID [${selectedEvent}]" testRunner.testCase.setPropertyValue( "EventId", selectedEvent ) // return selectedEvent }13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1KViews0likes1CommentRe: Linux Agent Install Problem
What we're seeing right now relates to firewall issues - the CentOS machine is blocking the ports. We've enable the ones that know of - but still no joy. What are the ports that should be enabled in order for this to work. I don't think we'll have the option of disabling the firewall completely.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.6KViews0likes0Comments