On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard <aballard@xxxxxxxxx> wrote:
> The other developer in our office spent some time profiling the site with
> xdebug and found that an exec() call to netsh used on a couple pages seems
> to take 2-4 seconds to complete. Unfortunately, those exec() calls are the
> one function that we cannot test in our development environment. We are
> considering some optimizations, but since load on the production server is
> at a seasonal low we want to duplicate the problem so we can measure the
> impact of any changes we make. We spent most of today hammering the site
> with JMeter today in an attempt to reproduce the issue. While we were
> easily able to slow the site to a crawl (some samples taking over 2 minutes
> to complete), the server returned to normal as soon as the test concluded
> and it never became totally unresponsive like it did this past fall.
>
If you can't test the exec calls, directly, I'd refactor the functionality
that calls exec() so you could pass in replacement functionality that
creates that artificially creates the pause in your development environment:
function callnetsh($args, $func) {
$func($args);
}
// in dev environment, pass in $func that doesn't call exec but just sleeps
for the expected duration
callnetsh(['some', 'args'], function($args){
sleep(4);
});
We're both new to JMeter. I know a single test server may not be able to
> create enough simultaneous requests to accurately simulate real traffic,
> but I'm fairly confident that our tests involved far more (roughly-)
> simultaneous connections than we were experiencing live. (The first test
> used 20 threads; we gradually increased the threads for each test to 500
> threads before we quit for the day.) The site is on a private subnet, so
> distributed and/or cloud-based testing are probably not options.
>
2 quick notes:
If you have a linux box available, I like the simplicity of siege, but
jmeter is nice, too:
http://www.joedog.org/siege-home/
If the exec() calls were not being executed (e.g., they were bypassed) and
weren't being accounted for in terms of processing time, then these tests
would likely fail to recreate the load issues with similar numbers.
The site is running PHP 5.3 on IIS/Windows Server 2003. The netsh calls are
> to a DHCP server on a separate Windows server, and the database is SQL
> Server 2008 (previously 2000).
>
PHP 5.4 offers performance improvements. I don't suspect the migration from
SQL Server 2003 to 2008 caused any of these issues.
> So, any ideas we can try?
We'd probably have to know more about what the netsh calls were doing.
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
