Comments for PerformanceEngineer.com

Comment on Glassbox by dhartford

dhartford — Wed, 02 Dec 2009 14:39:21 +0000

Followup post, I’m evaluating a similar tool to Glassbox and Infrared called ‘Javamelody’, and I’m really liking the balance between relatively low setup/complexity with the amount of information available.

http://code.google.com/p/javamelody/

I would enjoy an experienced opinion on this option.

p.s. I’m not a developer to the project, but I’ve starting using and contributing some thoughts to the project.

Comment on Performance Testing from the Cloud by Mark Tomlinson

Mark Tomlinson — Wed, 02 Dec 2009 08:18:11 +0000

disclosed: I am the HP LoadRunner Product Manager.

I think that our Software-as-a-Service Performance Testing solutions at HP are very well suited for anyone, and the technology we use is built on the core LoadRunner components.

It’s important for us to take a great testing tool like LoadRunner and deliver with more self-service, on-demand models…that would appeal to developers or agile testing teams.

Comment on Monitoring WebLogic using JMX by shashi

shashi — Fri, 06 Nov 2009 15:45:04 +0000

Thanks for the most usable tips on configuring weblogic for JMX. i configured this with JVisualVM. And it worked on first go. I am mentioning this because i saw lots of other posts talking about this topic and none of them worked (atleast for me).
Thanks a ton once again.

Comment on Glassbox by William Louth

William Louth — Fri, 18 Sep 2009 07:17:01 +0000

The gold standard in this area that is extremely extensible, customizable with an enhanced AspectJ runtime fit with production capabilities such as byte code caching, filtering and aspect/class runtime inspection is JXInsight.

Comment on Performance is not a Check Box by William Louth

William Louth — Fri, 18 Sep 2009 07:13:12 +0000

The key to successful performance engineering is in the creation or capture of both the software (steps, flows, interactions) and system (resources, concurrency, queues, contention plans) execution models.

Knowledge acquisition should drive any related efforts and it should start as early as possible and be archived so that others can understand the context for various technical decisions that impact scalability, reliability and performance.

William

Comment on Performance is not a Check Box by Andrew

Andrew — Tue, 15 Sep 2009 20:35:27 +0000

Charlie

One thing I find helps the performance engineering process is if during the design stage a simple performance model can be built that can identify what are the key performance critical areas. This then means the developers of those particular areas can then concentrate on producing good performing code. Less performance critical code areas can be given to junior programmers etc.

Comment on Performance is not a Check Box by Tola

Tola — Tue, 15 Sep 2009 16:44:21 +0000

Nice article…captures the meat of performance testing…however, one key component of performance testing that is less mentioned is the role of functional testing, there are several options to handling this type of testing within an organization, some in parallel with performance testing based on completed scope testing, while others consider a fully functionally tested apps before engaging in performance testing. I’ve had the opportunity to be involved in both, and there are no single bullet solution. The decision often boils down to cost, time-lines, and other external factors that influence the project.

Just to add my two cent!

Tola

Comment on Introduction to The Grinder by Andrey Isaev

Andrey Isaev — Tue, 01 Sep 2009 09:17:41 +0000

Hi Steveo,

If you are still interested in The Grinder and GrinderStone, we’ve recently released new version 2.0.1.

What new:
support for Eclipse 3.4 and 3.5
support for The Grinder 3.1 and 3.2
support for latest versions of PyDev Eclipse plugin

New Features:
Ability to add and pass to script arguments via JVM parameters
Select grinder.property file dialog: should allow to select any file rather than “grinder.properties” only

What was fixed:
Eclipse 3.4.1 support
Eclipse 3.3 compatibility is broken
Unable to create new Grinder Run Configuration (PyDev 1.4/Grinderstone 2.0.0)
Grinderstone does not launch script (NoSuchMethodError – IpythonPathNature.getProjectSourcePath()Ljava/lang/String)
An internal error occurred during “Launching”

Download information:
GrinderStone home site: http://code.google.com/p/grinderstone/

Andrey.

Comment on Performance is not a Check Box by Chanson

Chanson — Tue, 18 Aug 2009 20:25:20 +0000

Charlie – Great article you wrote here =)

Comment on Glassbox by dhartford

dhartford — Thu, 06 Aug 2009 13:08:05 +0000

bumping an old post, as I also have been trying to find ‘easier’ ways to identify performance troublespots as easy and as soon as possible.

I’ve used InfraRED in the past, and thought it was definately on to a great start, but as you mentioned support dwindled. Also tried Glassbox, also liked it, but didn’t really stick with it.

Do you plan on doing a followup post for the more recent times of any findings similar to these toolkits?

thanks

Comment on Monitoring WebLogic using JMX by Tanmoy Roy

Tanmoy Roy — Mon, 03 Aug 2009 18:48:39 +0000

Hi,
This article is really wonderful.
I have a question, can we monitor JDBC statics using jconsole for weblogic server? If so how? I am on wls10.3.
Also when I set -Dcom.sun.management.jmxremote.port=8888 it says, read access must be restricted for JMXremote.password file.
I changed the file properties to read-only on windows box, but it still saying the same.

Comment on LoadRunner: Creating a custom dll by James

James — Sat, 18 Jul 2009 00:59:35 +0000

Hi Don,

Did you put the dll in the LoadRunner bin folder on the generator?

Comment on Performance Testing from the Cloud by Web performance in seven steps; step 3: representative testing | Xebia Blog

Web performance in seven steps; step 3: representative testing | Xebia Blog — Thu, 16 Jul 2009 21:09:03 +0000

[...] The emergence of cloud computing adds new possibilities for performance testing. An elastic compute cloud like Amazon EC2 provides the ability to scale up quickly with the number of application deployments because of increasing load. For performance testing, the cloud can be used the other way around: for temporary use of many load generating test clients to generate expected and peak loads for your application. This saves you from having to buy many servers to run the load generating clients and if you run these performance tests say only a couple of days in a release cycle, this can be an economically attractive solution. Quite some information is available how to test with various performance tools from the cloud. [...]

Comment on Introduction to The Grinder by Fiat filip

Fiat filip — Mon, 22 Jun 2009 09:55:16 +0000

Steveo did you managed to use a datafile to feed a test script? If yes, could you point me some details?

Comment on Introduction to The Grinder by Mark

Mark — Thu, 18 Jun 2009 08:28:11 +0000

I am new to both The Grinder and GrinderStone. I used the update manager to install GrinderStoner after manually downloading and installing Jython and The Grinder.

I am running the following configuration:

Jython 2.2.1
The Grinder 3.2
Pydev 1.4.6.2788
GrinderStoner 2.0.0
JDK1.5.0_16

After having followed the instructions above I right click on my GoogleHomePageTest.py file (which I created under the /src folder) and click ‘Grinder Run’. Nothing happens, i.e. nothing appears in the console.

When I go into the run configuration context menu and attempt to create a new ‘Grinder Run’ I get the following error message:

Plug-in com.googlecode.grinderstone was unable to load class com.googlecode.grinderstone.debug.ui.GrinderTabGroup

Can someone please help me?

Thanks.

Mark.