Gilles <nos...@nospam.com> writes: > I notice that Python-based solutions are usually built as long-running > processes with their own web server (or can run in the back with eg. > Nginx and be reached through eg. FastCGI/WSGI ) while PHP is simply a > language to write scripts and requires a web server (short running > processes).
It's an artefact of the server infrastructure, there is no rule here. Any solution used with one language could be used with the other. > Since web scripts are usually very short anyway (user sends query, > server handles request, sends response, and closes the port) because > the user is waiting and browsers usually give up after 30 seconds > anyway... why did Python solutions go for long-running processes while > PHP was built from the start as short-running processes? You misunderstand the problem here. It's not about the duration of the actions, it's about the latency it takes to read/parse/execute the script. HTTP is stateless anyway, so if the same "interpreter" handles several requests, what you save by keeping the interpreter alive is the load/parse phase. If you relaunch an interpreter for every HTTP request, you pay the same price again and again for something which is not even related to your scripts' execution. -- Alain. -- http://mail.python.org/mailman/listinfo/python-list
