Announcement

Collapse
No announcement yet.

What is causing - PHP has encountered an Access Violation at 7C8224B2?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pgowder
    replied
    Originally posted by Computer Guru View Post
    phplens version is rather buggy on Windows 2003 SP2 in our testing (around 15 million hits a month, one server, latest PHP).

    The MS implementation may not be final, but it certainly is reliable (and yes, it is beta... afaik).

    CGI and FastCGI both create new processes for requests - but you must be mistaken - FastCGI does not create a new process for each request - it reuses the same process. It creates multiple process for multiple simultaneous requests (up till a point where it "queues" them in a line to use existing processes). CGI on the other hand, creates and kills a new process for each connection, making it a billion times less efficient than FastCGI and a million times less than ISAPI.

    Of course this isn't ideal and that's why ISAPI is great - but PHP doesn't give a damn about Windows' users and have labeled this as a "low priority" "known issue" with regards to "poor stability/reliability on Windows"

    It's up to you. You can boost performance for 10 minutes by using ISAPI - until your server is brought crashing down to its heels by un-threadsafe extensions (basically everything that ships with PHP) or you can use FastCGI and sacrifice a bit of performance for a ton of stability.
    Watching the process list, FastCGI created so many processes that there wasn't a sacrifice of a "bit of performance" the server was unusable.

    Yes, ISAPI is not very stable for me right now. But at least people can get to the pages.

    Leave a comment:


  • Computer Guru
    replied
    phplens version is rather buggy on Windows 2003 SP2 in our testing (around 15 million hits a month, one server, latest PHP).

    The MS implementation may not be final, but it certainly is reliable (and yes, it is beta... afaik).

    CGI and FastCGI both create new processes for requests - but you must be mistaken - FastCGI does not create a new process for each request - it reuses the same process. It creates multiple process for multiple simultaneous requests (up till a point where it "queues" them in a line to use existing processes). CGI on the other hand, creates and kills a new process for each connection, making it a billion times less efficient than FastCGI and a million times less than ISAPI.

    Of course this isn't ideal and that's why ISAPI is great - but PHP doesn't give a damn about Windows' users and have labeled this as a "low priority" "known issue" with regards to "poor stability/reliability on Windows"

    It's up to you. You can boost performance for 10 minutes by using ISAPI - until your server is brought crashing down to its heels by un-threadsafe extensions (basically everything that ships with PHP) or you can use FastCGI and sacrifice a bit of performance for a ton of stability.

    Leave a comment:


  • Wayne Luke
    replied
    FastCGI is simply an architecture just like CGI is an architecture. This is simply a third-party (meaning not Microsoft or PHP) implementation of it.

    Leave a comment:


  • todd222222
    replied
    Ok another question?

    What is this? http://phplens.com/phpeverywhere/fastcgi-php

    It's also called FastCGI but is it different than the one at www.iis.net?

    Leave a comment:


  • pgowder
    replied
    FastCGI was terrible for me! It opens a new process for each PHP session. I have a very busy server and that killed all available memory.

    Leave a comment:


  • TommyBALL
    replied
    Originally posted by Wayne Luke View Post
    That is still in beta correct? With a final version due with IIS7.
    It hasn't even reached beta stage yet.
    http://www.vbulletin.com/forum/showp...03&postcount=7

    Leave a comment:


  • Wayne Luke
    replied
    That is still in beta correct? With a final version due with IIS7.

    Leave a comment:


  • Computer Guru
    replied
    For what it's worth - for anyone having this bug, we managed to solve it on our servers by switching to Microsoft's own proprietary (and free) FastCGI implementation: http://www.iis.net/default.aspx?tabid=1000053

    Leave a comment:


  • TommyBALL
    replied
    For whatever it's worth: I have not had a single access violation with 5.2.2. A few others have reported that they've not had any access violation either, with such a setup, since 5.2.2.

    My setup is in my signature below. The server is a VMWare virtual machine. I only run vBulletin on it. Five instances of vBulletin. 3 are my own. 2 hosted for others. All 5 forums run in the same Application Pool with 3 worker processes in a Web Garden setup.

    My PHP extensions are:
    extension=php_xcache.dll
    extension=php_gd2.dll
    extension=php_mbstring.dll
    extension=php_mysqli.dll
    extension=php_memcache.dll

    I use IIS for http-compression (instead of PHP/vBulletin)... with a few tweaks in the metabase.

    Regards
    - Tommy
    Last edited by TommyBALL; Mon 18 Jun '07, 10:23am.

    Leave a comment:


  • todd222222
    replied
    Tommy,
    Several months ago I switch to apache on windows 2003 because of these problems. I was running php 5.2.1 and only have these extenstion installed: php_gd2.dll and php_mysql.dll

    I would love to go back to IIS. I'm not running xcache or memcached, do you think running php 5.2.2 and these two apps would stop the errors?

    thanks

    Leave a comment:


  • TommyBALL
    replied
    Nope. It's still in Technical Preview 2.
    http://mvolo.com/blogs/serverside/ar...rt-on-IIS.aspx
    While we are still working on the Beta release for the IIS5/IIS6 version of FastCGI, we didn’t want to leave you hanging – so, if you are having any trouble with TP2, you can download the latest developer release of out-of-band FastCGI that fixes a few problems reported by the community since TP2’s release.

    Leave a comment:


  • 007
    replied
    Actually FastCGI is in Beta now and has been for a while.

    Go to the link below for the official donwload. It comes with a readme file that should help you get everything set up properly.

    http://www.iis.net/default.aspx?tabid=1000051

    Leave a comment:


  • pgowder
    replied
    Originally posted by TommyBALL View Post
    It depends on what PHP applications you are running, what PHP extensions they require, and how thread-safe those extensions are.
    FastCGI is not even in Beta yet.

    Regards
    - Tommy
    Thanks, I'll give 5.2 a try. Cross my fingers and hope it improves it!

    Leave a comment:


  • TommyBALL
    replied
    Originally posted by pgowder View Post
    So moving to PHP 5.2.x will solve it or I still need to implement FastCGI also? Is that stable for use?
    It depends on what PHP applications you are running, what PHP extensions they require, and how thread-safe those extensions are.
    FastCGI is not even in Beta yet.

    Regards
    - Tommy

    Leave a comment:


  • pgowder
    replied
    Originally posted by TommyBALL View Post
    It's caused by parts of PHP that where not written with the treaded process model of windows in mind. The PHP core itself works fine in a threaded environment like Windows, but many (most?) extensions where written by Linux/*nix coders that find coding in a thread-safe manner too complicated to handle (or they just don't care ).

    I notice that you are running an old and insecure version of PHP. You should upgrade ASAP (http://www.php.net)
    Also, disable all extensions you do not really need.
    Some more info in the following thread:
    http://www.vbulletin.com/forum/showthread.php?t=212192

    So how can you really resolve this in a good manner? There is not really any perfect solution to it till MicroSoft and Zend finish their FastCGI implementation. This will let non-thread-safe stuff run on IIS in a more stable manner, while keeping performance up to (or even surpass) ISAPI levels (as opposed to slooow regular CGI).

    More on the FastCGI project can be read on MicroSoft's official IIS website:
    http://www.iis.net

    FastCGI is being made for IIS 5/6/7. It will be included as a natural part of Longhorn (the next windows server version).

    I'm running vBulletin quite successfully with absolutely no Access Violations on the setup in my signature below.

    Regards
    - Tommy
    So moving to PHP 5.2.x will solve it or I still need to implement FastCGI also? Is that stable for use?

    Leave a comment:

widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...
X