Page 1 of 1
EVA vs 3PAR
Posted: Wed Oct 24, 2012 10:55 pm
by mlev.26s
Hi, anyone tried to compare between EVA and 3PAR on single thread sequential writes. It seems EVA is better. Did anyone try ?
Thanks
Re: EVA vs 3PAR
Posted: Wed Oct 24, 2012 11:42 pm
by Richard Siemers
Got any specs or benchmarks to add some substance and depth to your topic? How exactly does it "seem better"?
How big was the EVA disk pool vs the 3PAR?
Disk types/rpm?
Re: EVA vs 3PAR
Posted: Thu Oct 25, 2012 12:49 am
by mlev.26s
I tried 250G SQLdump.
From EVA8000(20 x 10K/vRAID5) to P6300 (16 x 7.2k /vRAID5) =
From EVA8000(20 x 10K/vRAID5) to 3PARF400 (16 x 7.2k /vRAID5) =
Re: EVA vs 3PAR
Posted: Thu Oct 25, 2012 7:29 am
by Richard Siemers
Wow, 300% slower... to get that huge delta in performance, something else is interfering with your benchmarks. One vendor's flavor of raid5 vs another's using identical spindle configuration should yield anywhere from a 0% to maybe 15% difference... 300% is cause to re-evaluate and analyze your benchmark environment until you understand WHY that is so different. I guarantee you something is not apples to apples there.
250gb at 20 mins is about 208 mb/s.
250gb at 62.4 mins is only 4 mb/s second.
Could compression have been turned on for one dump and not the other?
--Richard
Re: EVA vs 3PAR
Posted: Thu Oct 25, 2012 9:37 pm
by mlev.26s
I did a simple testing.
Local copy to EVA and Local copy to 3PAR. EVA is better
Re: EVA vs 3PAR
Posted: Fri Oct 26, 2012 5:53 pm
by Richard Siemers
I don't want to sound confrontational... 4 mb/s can be beat by a USB 1.0 external drive, single spindle. If it was a copy from local disk to SAN, I would guess the local drives you were reading from were busy doing something else at the same time.
If you re-run the test(s) you should keep an eye on the queue depth and response time of source drive and the target drive... as well as MB/s total on each. You can only write as fast as you can read in a test like that.
Better then that though, you may want to try using IOmeter for benchmarking instead.