Nginx can have workers, but the default number is one. nginx doesn't need a separate worker per time to handle each request. Anything that happens on a given connection is an event (connected, received some data, finished receiving data, got a response from the backend, closed the connection), and nginx just responds to events in the order received across all connections. It doesn't have to hang out and wait for the client to finish sending it's request, doesn't have to wait for PHP to process the request, just goes about handling the next event until those time-consuming things finish.

If you've looked at using PHP with nginx, you might be thinking of the fastcgi workers. Rather than including PHP in the web server process, fastcgi keeps a pool of PHP processes around, and whenever you get a PHP request, nginx passes it off to the fastcgi backend (then goes about other business until the backend responds). I don't know of any reason that PHP run this way should be faster than as an apache module, but the whole system ends up faster because the web server part is using a lot less memory and CPU. And depending on your site, there are some really low hanging optimizations you can do with nginx. E.g., just need a couple of configuration lines to cache all PHP GET requests for 5 min (unless you have cookie X, if you want). Since nginx seriously will not bat an eye over serving a redditing worth of static files, that means even your unoptimized word press site can stand up to the front page no problem. (Not verified from actually attempting it. But I did setup a simple PHP site on a 512 Linode that served 250k page views per day without excessive disk activity or the CPU usage crossing 10%.)