RSS .92| RSS 2.0| ATOM 0.3
  • Home
  • About me
  • Imprint & Legal Stuff
  • Recommended
  •  

    Profiling PHP Code with XDebug and CacheGrind

    July 6th, 2010

    In my posting about installing a PHP development environment using Ubuntu 10.04 I mentioned the possibility to debug PHP code using XDebug and CacheGrind. Here is a little tutorial on howto use profiling with some free open source tools.

    Installation / Configuration

    XDebug is a debugging component which can be added as a module to PHP. To install XDebug (if you havent’t used my tutorial yet) simply use the following code:

    1
    
    apt-get install php5-xdebug

    Now you need to configure XDebug. As a default configuration you should put the following into /etc/php5/conf.d/xdebug.ini:

    1
    2
    3
    
    xdebug.profiler_enable_trigger = 1
    xdebug.profiler_enable=0
    xdebug.profiler_output_dir = /tmp

    The first line enables the profiler by using a trigger. The trigger is a GET/POST parameter called XDEBUG_PROFILE=1 you can use whenever you start a local page via your webbrowser.

    The second line enables the profiler by default and would create a profiler output file without a trigger parameter. We don’t want to do that all the time, so the value here is 0. If you want to enable your profiler the whole time, just put a 1 in there.

    The third parameter is the path of the directory you want to write your profiler output files to. I’ve inserted /tmp as a default here, but you can change it to any other directory your webserver has write access to.

    So an example URL to access a local webpage and create a profile output would be something like this:
    http://localhost/index.php?XDEBUG_PROFILE=1

    There should be a cachegrind file in your output dir, e.g. cachegrind.out.12345

    The number at the end of the filename is the apache pid. The name of the cachegrind file can be configured using another parameter, xdebug.profiler_output_name. A complete documentation of all possibilities can be found here.

    Displaying the profile data

    There are several tools to analyze the data created by the XDebug profiler. One of these tools is KCachegrind. KCachegrind visualizes traces generated by profiling, including a tree map and a call graph visualization of the calls happening.

    As an example: you can analyze how often certain heavy-load methods are called within your application; that way you can find ways to minimize those calls, reduce them to a pure minimum and increase the performance of the application or website.

    Alternative visualization tools for different platforms and operating systems are also available, e.g. MacCallGrind für MacOS. A web based solution would be Webgrind, hosted on Google Code.


    Installing Ubuntu 10.04 Lucid Lynx for PHP development

    June 15th, 2010

    Lucid-LynxLast year I have written a small how-to for installing an Ubuntu 9.04 work environment as virtualbox environment (though it also works for native systems). Recently I have updated this guide to 10.04 as kind of check list to get a working environment to develop PHP/MySQL applications.

    Read the rest of this entry »


    Ubuntu 10.04 LTS (Lucid Lynx)

    April 26th, 2010

    On April 29th the new Release of Ubuntu, named Lucid Lynx, will be available to download from the official Ubuntu site. Currently the release candidate is already available, so if you want to try out, you can get it now and upgrade to the full version later.

    One of the biggest changes is the new default style in Gnome, which puts the menu buttons to the upper left part of the window instead of the upper right. This is a little bit confusing, but you can change back to a more traditional layout.

    Only problem so far was installing apc but I guess I will solve that one soon :)


    My 10 most important things about Scrum and being a ScrumMaster

    September 12th, 2009

    As I have already written, I have attended a ScrumMaster certification in Munich on thursday and friday, done by Boris Gloger at TNG Technology Consulting. At this point I want to thank Boris and Andreas for the great Scrum session, it really gave me a much clearer impression of what Scrum is and should be. I also want to thank TNG for hosting the event, you have a great office, the food was good, I liked it very much!

    So for me what are the most important things I learned about Scrum and being a (now certified) ScrumMaster? Here is a quick review about that:

    1. “there is no truth” – every Scrum Trainer may tell you something different about implementing Scrum (or parts of it). That may be as it is, but you need to remember, there is no single true only valid method of Scrum. Do what works for you and your company – but stick to it (and improve it over time)! But the basic Scrum elements should be there, otherwise don’t call it Scrum.
    2. Skill No. 1 the ScrumMaster has to learn: to say “NO” to the boss! You can’t protect your team, you can’t even try to change your organisation (especially the bad parts in it) if you can’t say “NO” to the boss at some level. A ScrumMaster is like a fish swimming against the river, he goes against the rules in the organisation preventing the team to be successful in delivering quality (potentially shippable) software.
    3. don’t try to use electronic tools too much – a task board, product backlog and impediment backlog can easily be managed with sticky notes and a movable board/flipchart. It makes handling the information (especially when estimating and in daily scrum meetings) much easier.
    4. never ever ever ever estimate the effort – only estimate the functionalities and their relation to each other. Velocity changes with the constraints and technical details but the functionalty stays the same – and so does the estimation. I believe that’s the hardest part to make clear to Management guys who still want to think in men days and currency. So give it to them but don’t estimate the implementation, estimate the functionalities and you can give them a release plan that (should) work(s).
    5. work with your Product Owner and make sure he presents the Vision and big picture behind the product to the team – make him repeat that as often as possible so it doesn’t get lost.
    6. keep the roles separated – a ScrumMaster should never be a Product Owner or be part of the team. You ask why? Because he could not fulfil his role to protect the team or create a safe environment for them.
    7. the ScrumMaster helps the team, but he doesn’t do the work for them! Be sure to let the team handle stuff like Burn Down Chart or running the daily scrum.
    8. Be there for them and help them if they need it, and be sure to remove all impediments they might have. Try to find out if there are any impediuments the team might not know about (e.g. when a task isn’t done after like 2 days, ask why it isn’t and find out what the possible impediment could be.
    9. get a clear “definition of done” from the team. Make sure the team includes possible constraints set by company rules e.g. documentation.
    10. make everybody stick to the time box. Expect them to be there on time and don’t use more time than being specified!

    Ok thing those are the most important items I got from the last 2 days. There was a lot more information (naturally) but if you need (or want) to know more about Scrum and the techniques, I recommend Boris’ book Scrum: Produkte zuverlässig und schnell entwickeln and Your Scrum Checklist: Scrum Hard Facts: Roles. Artefacts. All Meetings.


    Scrum & Agile Development

    September 6th, 2009

    Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development.

    Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach.

    Scrum is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:

    1. the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager);
    2. the “Product Owner”, who represents the stakeholders;
    3. the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

    Here is my collection of Scrum resources in the world wide web:

    Here are some articles I find very interesting:

    Next week I will attend the Certified ScrumMaster training in Munich, done by Boris Gloger. So more posts about Scrum are about the follow this one.