On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson <simpleshot@xxxxxxxxx> wrote: > > 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: > I'm not sure the issue is solely because of the delay. At any rate, we were running the load test yesterday against the production system that was having problems last fall. I wish we had a test system where we could test everything end-to-end, but unfortunately we can't duplicate the DHCP part of the production environment. > 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/ Hahahaha. This system AND the DHCP both USED to run on linux boxes. This task was much simpler then, because the DHCP table was a text file that we parsed and updated directly from PHP. It was decided to standardize on a single platform to make system maintenance and security management simpler, and most of our client/server stack was already Windows. If necessary, I could probably spin up a virtual box for testing though. >> 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. I can't imagine the DB upgrade would have caused it. I think at the same time he switched to using Zend_Db (not the full framework, just the DB library) over top of the SQL Server driver for PHP for database queries. >> >> So, any ideas we can try? > > > We'd probably have to know more about what the netsh calls were doing. This particular call is querying DHCP for a list of leases within a specific scope so we can get the MAC address of the client. Once we authenticate the user, calls on later pages expire the current lease for that MAC address on a private subnet and create a semi-permanent lease on the public subnet. Our testing yesterday stepped through the process beginning with this initial DHCP query (which was the long running process identified in profiling) and the next few very simple pages but stopped short of actually making any changes to the network assignment. With a single user, the first page takes a couple seconds and the next few pages are <50ms. During testing yesterday, we had the system stressed enough to stretch those times out past a couple minutes. It looks like we're going to have to continue the test into the next part of the sign-up process, but that will take some time to learn about JMeter conditional logic. I suspect we'll have to wait a couple weeks until students are gone before we can actually run that level of testing. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
