Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Monday, June 25, 2018

Guerrilla 2018 Classes Now Open

All Guerrilla training classes are now open for registration.
  1. GCAP: Guerrilla Capacity and Performance — From Counters to Containers and Clouds
  2. GDAT: Guerrilla Data Analytics — Everything from Linear Regression to Machine Learning
  3. PDQW: Pretty Damn Quick Workshop — Personal tuition for performance and capacity mgmt

The following highlights indicate the kind of thing you'll learn. Most especially, how to make better use of all that monitoring and load-testing data you keep collecting.

See what Guerrilla grads are saying about these classes. And how many instructors do you know that are available for you from 9am to 9pm (or later) each day of your class?

Who should attend?

  • IT architects
  • Application developers
  • Performance engineers
  • Sysadmins (Linux, Unix, Windows)
  • System engineers
  • Test engineers
  • Mainframe sysops (IBM. Hitachi, Fujitsu, Unisys)
  • Database admins
  • Devops practitioners
  • SRE engineers
  • Anyone interested in getting beyond performance monitoring

As usual, Sheraton Four Points has bedrooms available at the Performance Dynamics discounted rate. The room-booking link is on the registration page.

Tell a colleague and see you in September!

Saturday, May 14, 2016

PDQ 7.0 Dev is Underway

The primary goal for this release is to make PDQ acceptable for uploading to CRAN. This is a non-trivial exercise because there is some legacy C code in the PDQ library that needs to be reorganized while, at the same time, keeping it consistent for programmatically porting to other languages besides R—chiefly Perl (for the book) and Python.

To get there, the following steps have been identified:

  1. High Priority

    1. Migrate from SourceForge to GitHub.
    2. Change the return type for these functions from int to void:
      • PDQ_CreateOpen()
      • PDQ_CreateClosed()
      • PDQ_CreateNode()
      • PDQ_CreateMultiNode()
      Using the returned int as a counter was deprecated in version 6.1.1.
    3. Convert PDQ-R to Rcpp interface.
    4. Clean out the Examples directory and other contributed code directories leaving only Examples that actually use the PDQ C library.
    5. Add unit tests for PDQ C library, as well as the Perl, Python, and R languages.
    6. Get interface accepted on CRAN
    7. Add the ability to solve multi-server queueing nodes servicing an arbitrary number of workloads.

  2. Low Priority

    1. Get interface accepted on CPAN and PyPI.
    2. Convert to build system from makefiles to Cmake.

Stay tuned!

—njg and pjp

Monday, August 24, 2015

PDQ Version 6.2.0 Released

PDQ (Pretty Damn Quick) is a FOSS performance analysis tool based on the paradigm of queueing models that can be programmed natively in

This minor release is now available for download.

Tuesday, December 18, 2012

PDQ 6.0.1 is Released

As already described previously, the main purpose of Release 6.0.1 Build 121512 is improved compatibility and stability between PDQ and the R statistical environment. For example, many of the PDQ models, previously found in the ../examples/ directory, can now also be accessed via the demo() command in the R-console. Testing was carried out using R version 2.15.2 (2012-10-26).

Operationally, PDQ, in any of the supported languages, should appear cosmetically the same as Release 5.0; no additional programming required. Since the PDQ-R source can be compiled separately, this release will be of special interest to Microsoft Windows users.

If you're new to PDQ, here's a simple PDQ-R model you can paste directly into the R-console:


library(pdq)
# input parameters
arrivalRate <- 0.75
serviceRate <- 1.0
## Build and solve the PDQ model
Init("Single queue model")         # initialize PDQ
CreateOpen("Work", arrivalRate)    # open workflow
CreateNode("Server", CEN, FCFS)    # single server
SetDemand("Server", "Work", 1/serviceRate) # service time
Solve(CANON)                       # solve the model
Report()                           # tabulated output
Please see the online release notes for the download links and more detailed information, as well as the top-level README file in the distribution. Beyond that, check out the relevant books and training classes.

Merry Xmas from the PDQ Dev Team!

Monday, June 29, 2009

PDQ 5.0 Test Suite or ... How I Spent My Weekend

I was planning to blog about the amazing time I had at Velocity 2009 last week, when this landed in my mailbox (edited for space and privacy):

Subject: Seeking help with PDQ-R ...
Date: Thu, 25 Jun 2009 15:51:21 -0500

My name is James and I've been trying to learn to properly use PDQ after reading two of your books, "Guerrilla Capacity Planning" and "Analyzing Computer System Performance with Perl::PDQ." I'm still getting a grip on PDQ-R. ... I decided to set about of re-creating the queue circuit in the study with PDQ-R as an exercise. ...
The output of my code yields:
[1] "Manual response time for class 1 is 0.864179 seconds"
[1] "PDQ-R response time for class 1 is 0.313637 seconds"
[1] "Manual response time for class 2 is 6.105397 seconds"
[1] "PDQ-R response time for class 2 is 3.552873 seconds"
[1] "Manual response time for class 3 is 4.535833 seconds"
[1] "PDQ-R response time for class 3 is 4.535833 seconds"
If you could give my code a look over and give me some hints I would really appreciate it.

Friday, January 30, 2009

PDQ From SourceForge

Thoughly fed up doing mind-numbing company income taxes for 2008 (Yes, I have to do them earlier than most to get my 1099s out to sub-contractors), I decided to take a break and see if I could compile PDQ (Pretty Damn Quick) by downloading it from our SourceForge project onto my new Macbook.

Wednesday, August 29, 2007

PDQ Gets Tickled

I recently stumbled across this reference to PDQ in Tcl. The author (Todd Coram) correctly notes that we use SWIG to generate the Perl and Python wrappers and this also facilitates Tcl, apparently. I don't know if he has completed the Tcl port or plans to offer it to us for release to the world at large. Maybe he'll let me know. Surely, The Father of Tcl (a big fan of scripting tools) would approve.

Postscript: Todd Coram responded via email and stated that his attempt had gone into limbo some time ago. So, it looks like open season for anyone interested in doing a Tcl port of PDQ (or any other language for that matter).

Friday, April 20, 2007

PyDQ (PDQ in Python) Web Pages Get Updated

For all you Python fans, I've updated the PyDQ web page with more online examples to get you started. For example, the communications network model has been revised to use NumPy inline to solve the traffic equations for the internal flows. Previously, I had solved those simultaneous equations separately using Mathematica.

The online PDQ Manual is also being revised to include PyDQ functions and code examples.

Wednesday, April 18, 2007

How Long Should My Queue Be?

A simple question; there should be a simple answer, right? Guerrilla alumus Sudarsan Kannan asked me if a rule-of-thumb could be constructed for quantitatively assessing the load average on both dual-core and multicore platforms. He had seen various remarks, from time to time, alluding to optimal load averages.