Nein - das dürfte hauptsächlich applikationsspezifisch sein.
Das Problem ist - dass in manchen Fällen php einfach "abschmiert" (z.B. manchmal bei "memory exhausted" o.ä. ) der Server hat dann keine Möglichkeit mehr festzustellen was passiert ist mit dem php - prozess und da die fastcgi Verbindung abgerissen ist schmeisst er einen 500er.
Es liegt aber in der Natur der Sache, die Php.ini entsprechend den Bedürfnissen anzupassen - Speicher wird ja nur soweit alloziiert wie er auch gebraucht wird.
Überlicherweise sind heutzutage Werte je nach dem zwischen 8-64Mb Mem Limit normal. Bei niedrigpreisigen Angeboten halt eher 8 bei besseren eher 64.
Es versteht sich von selbst, dass anspruchsvolle Anwendungen wie z.B. typo3 etc. eher mehr Ram als weniger brauchen. Damit kommen wir aber zu einem Vor - bzw. auch Nachteil der Fastcgi Sache - man kann eben für jeden Host eigene Werte festlegen - das könnte man natürlich auch mal irgendwie im Panel integrieren, dann lassen sich solche Werte dann z.B. auch im Hostingplan hinterlegen.
Jedoch würde ich sagen - die meisten Fehler basieren einfach auf zu wenigen "Request-Slots" bzw. zu wenigen FCGI_CHILDREN 's .
mod_fcgid hat im übrigen ähnliche Probleme mit dem töten überflüssiger php-prozesse wie mod_fastcgi weil es einfach ein php Problem ist und kein fastcgi Problem.
der Umstieg zwischen mod_fcgid und mod_fastcgi ist recht einfach.
Zu Aussagen zur Performance zwischen den beiden Varianten lasse ich mich nicht so einfach hinreissen - wenns um Fastcgi geht bevorzuge ich im größeren Stil eher lighttpd / nginx.
Deren Fastcgi Implementierungen sind wirklich gut gelungen - und schnell
.
Apache hat schon immer einen etwas anders gearteten multi-purpose Ansatz gehabt - den solche Spezialisten nicht erfüllen können.