Contributions
Re: When testing jms, ready api is having error while it works fine on soapui
johandis it possiblefor you to try the 1.2.1 as i suggested in my post above? It's relevant to know to track down if virt-refactoring between 1.2.1 - 1.3.1 caused this.9 years agoPlace ReadyAPI QuestionsReadyAPI Questions5.7KViews0likes14CommentsRe: Fixed Rate Generator Varying Requests
You are wrong in the fact that LoadUI does not wait for a request to return before sending a new one, at least not when you are using the Fixed Rate component (Fixed Load is another story). The fixed rate sends out X number of requests each second, no matter if the server can handle it or not. This makes it real obvious to see what happens when the server can't handle more requests. The statistics count responses that arrived during the latest second and the latest second only. This means that some requests leak into the next second because they may take an arbitrary amount of time to return. Internally this is because the timer that sends requests from a generator (G-timer) and the timer that displays data (D-timer) are not the same, but are started at roughly the same time. This means that if G-timer triggers requests just before D-timer starts collecting data then some requests may return before the D-timer collects them, thereby ending up in the previous data-point. These variances in the number of requests sent/received should be taken with a grain of salt and are mostly only visible on very tiny loads. I hope that explains your pondering somewhat. Best, Osten10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.7KViews0likes0CommentsRe: Requests Interval in different Generators
Hello, You are looking for the Fixed Load Component. Make sure you read up on how to connect it, which is a little funky as far as LoadUI goes. Also make sure that what you are trying to accomplish makes sense, because releasing an undeterministic amount of "virtual users" creates results that are tricky to interpret. that is described here Best, Osten10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.8KViews0likes0CommentsRe: Problem Launching LoadUI 2.6.7 and LoadUI 2.7.0
Hey, You should probably ask this question in the LoadUI forums. Also, the userfolder $HOME/.loadui is kept intact between installations, you might want to try renaming that and try to start LoadUI again. Best, Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions694Views0likes0CommentsRe: Running LoadUI from command line CentOS not working
Hello Patrick, To my knowledge reporting should work just fine. There's one thing you might want to investigate and that is to make sure that the jenkins-user has access to create reports where you are specifying it to. Are you really sure you want to export your reports to /home/ ? I might be mistaken but not even my local user has access-rights to that folder. osten@WRK-OSTEN /home $ mkdir myfolder mkdir: cannot create directory ‘myfolder’: Permission denied Best regards, Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.2KViews0likes0CommentsRe: Running LoadUI from command line CentOS not working
Any progress Patrick? Otherwise, it could be interesting to look into starting both Xvfb and create environment variables through jenkins, it's likely that it isolates itself from anything profile-related. I'm not entirely sure about it though. I do know that there's a settings to start Xvfb before the build and configure what screen it should create. I haven't tried it myself, but the envInject plugin might be worth looking into. Do get back with any solutions you might find! Best, Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.8KViews0likes0CommentsRe: SoapUI Runner Issue
Hello there! Impressive! You are running LoadUI 2.1.1, i honestly did not expect that version to still start. The first question i have to ask, have you been able to reproduce this with any LoadUI-version after 2.5+ ? You can find the older versions of LoadUI: Here Best regards, Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.5KViews0likes0CommentsRe: Running LoadUI from command line CentOS not working
Hey again Patrick, It looks as if your automation-script is not picking up the environment variable, and it depends on where you export your environment variable. export DISPLAY=:99.0 There are of course many ways to do it but if you do it only from the command-line then that environment variable is only active for your SSH session. If you want to set variables for your session each time you logon then you can add the export to bashrc. ~/.bashrc If you want the system to pick it up on startup then i suggest you add it to rc.local which is run on system boot. /etc/rc.d/rc.local or similar file of your distribution version if they changed it recently. There's also an option of putting it as a standalone script that is called by /etc/profile or /etc/bashrc /etc/profile.d /etc/bashrc.d I think that should resolve your trouble. Best of luck! Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.8KViews0likes0CommentsRe: Increasing the Thread Count Of Load UI
Hello Ranjit, First we need to straighten something out. What is your requirement? Do your requirement specify that your server is supposed to handle 1500 Transactions Per Second (TPS) or does it say that you are supposed to handle 1500 concurrent virtual users (VU)? I can't stress how much this is two very different requirements and how they should be reasoned about. If 1500 TPS: Then having 1500 concurrent threads hammering your server does not solve your problem. That the thread managing the request is unique for that second has nothing to do with whether you can satisfy that requirement. Solve the problem If you set 1500 requests / second with a rate-component and investigate whether the server can handle them or not. If 1500 VU's Each thread will complete a request and immediately upon completion continue with another one. This makes it very hard to enforce that exactly 1500 users are running at the same time. Most of the time it only makes sense to do this when you have to put stress on a server continuously and then do some manual testing on the user experience of your service. This is simulated in LoadUI using the Load generators. see the link for usage as it needs an additional connector to the runner it is generating users for. Solve the problem If you set 300 load with a 200ms delay on a fixed-load component. This makes LoadUI only use 300 threads, which won't make Java unstable as seen in the link below. It will theoretically generate: ( 1000ms / 200ms ) * 300vus = 1500 VU's using 300 real threads. LoadUI Is written in Java, Java threads are very expensive to the virtual machine it is running in. Often, increasing the threadcount does not really help you in this endeavour in any other way than making the JVM highly unstable, keep this in mind when increasing internal threads like this. On maximum threads in Java This was essentially a summary of what is already written here. I hope this solves your problem. Best regards, Mikael10 years agoPlace ReadyAPI QuestionsReadyAPI Questions2KViews0likes0Comments