Unable to import large aggregate report in jmeter UI, on linux OS

[Khan Navaz <na...@gmail.com>]

Hi,

I ran my jmeter test for last 3 days in cmd line mode. The aggregate result
is writing to a jtl file in "Save Field Names (CSV)" format. I thought xml
would be lot of data so using csv. The result file size is 80 MB.

Now when I try to import it, i am not seeing any results imported in jmeter
UI. I waited long but seems like jmeter gives up and i am able to move to
other nodes.

I tried increasing the heap size as well but it didnt help
set HEAP=-Xms256m -Xmx2048m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=1024m
set EVACUATION=-XX:MaxLiveObjectEvacuationRatio=50%

Pls let me know how this could be solved.

thanks in advance.

Re: Unable to import large aggregate report in jmeter UI, on linux OS

[sebb <se...@gmail.com>]

On 12/04/2010, Deepak Shetty <sh...@gmail.com> wrote:
> Hi
>  bigger files are best processed by loading them to database.

I suspect most spreadsheets would have problems with a dataset this size.
How many records are there?

Alternatives are to use a scripting language which can accumulate data
line by line or a specialist charting package.

Having said that, I would have thought that JMeter could handle any
size of CSV file so long as you only used the Summary Report, as that
does not keep a copy of each sample, and CSV files are processed as
they are read.

The Aggregate report in 2.3.4 uses lots of memory, but should be a lot
better in the new version.

Most other reports need to save a copy of every sample.

>  What errors did you get in jmeter.log (after heap size increase)? Try
>  starting Jmeter with a console  (use jmeter.cmd instead of jmeterw) and see
>  what happens . if it seems to get stuck , you can take a thread dump  (pause
>  + ctrl break on windows , kill -3 on *nix) and see where its stick
>  regards
>
> deepak
>
>
>  On Mon, Apr 12, 2010 at 10:17 AM, Khan Navaz <na...@gmail.com> wrote:
>
>  > Hi,
>  >
>  > I ran my jmeter test for last 3 days in cmd line mode. The aggregate result
>  > is writing to a jtl file in "Save Field Names (CSV)" format. I thought xml
>  > would be lot of data so using csv. The result file size is 80 MB.
>  >
>  > Now when I try to import it, i am not seeing any results imported in jmeter
>  > UI. I waited long but seems like jmeter gives up and i am able to move to
>  > other nodes.
>  >
>  > I tried increasing the heap size as well but it didnt help
>  > set HEAP=-Xms256m -Xmx2048m
>  > set NEW=-XX:NewSize=128m -XX:MaxNewSize=1024m
>  > set EVACUATION=-XX:MaxLiveObjectEvacuationRatio=50%
>  >
>  > Pls let me know how this could be solved.
>  >
>  > thanks in advance.
>  >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Unable to import large aggregate report in jmeter UI, on linux OS

[Deepak Shetty <sh...@gmail.com>]

Hi
bigger files are best processed by loading them to database.

What errors did you get in jmeter.log (after heap size increase)? Try
starting Jmeter with a console  (use jmeter.cmd instead of jmeterw) and see
what happens . if it seems to get stuck , you can take a thread dump  (pause
+ ctrl break on windows , kill -3 on *nix) and see where its stick
regards
deepak

On Mon, Apr 12, 2010 at 10:17 AM, Khan Navaz <na...@gmail.com> wrote:

> Hi,
>
> I ran my jmeter test for last 3 days in cmd line mode. The aggregate result
> is writing to a jtl file in "Save Field Names (CSV)" format. I thought xml
> would be lot of data so using csv. The result file size is 80 MB.
>
> Now when I try to import it, i am not seeing any results imported in jmeter
> UI. I waited long but seems like jmeter gives up and i am able to move to
> other nodes.
>
> I tried increasing the heap size as well but it didnt help
> set HEAP=-Xms256m -Xmx2048m
> set NEW=-XX:NewSize=128m -XX:MaxNewSize=1024m
> set EVACUATION=-XX:MaxLiveObjectEvacuationRatio=50%
>
> Pls let me know how this could be solved.
>
> thanks in advance.
>