Eu realmente acho que este é um dos melhores argumentos para usar o apache e mod_php em vez de fastcgi. É extremamente importante quando você tem uma crise de desempenho em andamento. Eu ocasionalmente pensei em investigar o que seria necessário para implementar isso em php_fpm, mas não encontrei tempo para isso.
Infelizmente, minha resposta é baseada em Linux, o que pode não ser útil para você (já que você faz referência ao IIS). Vou colocar a resposta de qualquer maneira, e talvez haja janelas equivalentes às ferramentas que menciono)
Você pode configurar algum recurso ad-hoc colocando algo certo no início do processamento do seu php, que registra a URL recebida, o ID do processo do PHP e talvez alguns outros detalhes, como o tempo. Você também pode registrar o término do processamento, e isso seria particularmente importante se você não pudesse confiar no registro sendo feito para todas as solicitações do PHP.
Eu não encontrei uma boa maneira de conectar essa URL e a frente da pilha ao processo PHP, mas tive sucesso no rastreamento de um processo Postgresql de volta ao processo PHP, seguindo os IDs de soquete em lsof. Isso é facilitado por cada sessão postgresql sendo manipulada por um processo separado. Eu não sei como fazer o mesmo para o mysql, mas também não me esforço muito para isso. Além de rastrear IDs de soquete, você também pode progredir procurando consultas nos dados de pacote e, em seguida, procurando quais processos contêm as IDs de porta associadas ao tráfego que lhe interessa.
Outra abordagem (a mais útil que eu conheço no linux) é olhar para o que está acontecendo dentro do processo de php que está usando todo o seu processador. Suas principais ferramentas aqui são strace e ltrace. Esteja ciente de que você imporá cpu e IO extra ao fazer isso, mas poderá anexar um processo para registrar as chamadas de sistema (strace) ou as chamadas de função de biblioteca (ltrace) associadas ao processo de seu interesse. Nem sempre trabalhar porque você pode ter um processo preso em um loop apertado que não chama o sistema ou outras bibliotecas, mas mais frequentemente do que não isso vai te dar o que você precisa.
Eu realmente não me dediquei a isso, mas eu presumo que também é possível se você usar o php-dev para anexar algo como o gdb ao seu processo, o que poderia parar, e você pode olhar para a pilha. você obteria uma pilha de linguagem C em vez de uma pilha PHP, mas presumivelmente você poderia encontrar os nomes das funções php lá e descobrir quais funções estão envolvidas. Como eu disse, você teria que pausar a execução, mas se você escrever algo para anexar gdb, imprimir uma listagem de pilha e desconectar, você não teria que interromper muito as coisas. Eu suspeito que existem ferramentas de depuração de janelas usadas por linguagens de programa em linguagens como C, C ++ e talvez C # que podem fazer isso?
Vale a pena dar uma olhada no que você pode obter dos vários depuradores do PHP.
Então, isso não é exatamente o que você pediu, mas talvez você agora tenha algumas idéias sobre outras maneiras de atacar seu problema de descobrir o que está acontecendo no processo ativo.
Talvez alguém possa apontar alguns equivalentes do Windows para as ferramentas do Linux que eu uso?