On 2015-12-24 14:39, Aaron Christensen wrote: > I am not sure if this is the correct venue for my question, but I'd > like to submit my question just in case. I am not a programmer but > I do have an incredible interest in it, so please excuse my lack of > understanding if my question isn't very thorough.
First, to do web development, you do need to be a programmer. Well, at least for anything of any complexity/novelty. But come on in, it's a fun place to be! > As an example, a website backend is developed using Python. Users > can submit their input through the website and PHP (or some other > language) transfers the user input from the website fields to a > database such as MySQL. There is a main script called > main_script.py which extracts the user data from MySQL, processes > it, stores output in MySQL and sends output to the user (via > webpage and email). A website backend can either static (just a pile of files that get served up by your web-server such as Apache or nginx, fast, but usually read-only such as a blog) or dynamic[1]. With a dynamic website, you have some language running on the server. Germane to this list, that's Python for many of us. But could be PHP, Perl, Ruby, C#, Java, Erlang, bash, or even sed/awk or Postscript. Pretty much any programming language can do the trick here. The web application then parses input from the *request*. This is usually made by the web-browser, but can also be made by other applications. The application then processes those inputs and determines the correct output. This might involve consulting a database such as PostgreSQL or MySQL to save data or gather the requested data, or it might farm that out to some other service. It might check that you're logged in. It might be purely read-only but pull information from a database or random set of files. The main thing to understand is that a request comes in, gets processed, and a response goes back. [1] or a hybrid of a dynamic site where certain assets such as images, CSS, and JavaScript are static and served outside the web application. - > # main_script.py extracts user input from MySQL, processes it, > stores output in MySQL and send output to user (via webpage and > email). # Inputs: User personal information such as age, dob, > nationality, hobbies, and 20 or 30 other fields So here it sounds like you think that the input comes from *MySQL* but it will actually come from the request. Now you can have some other (non-web) process access the same database that the web-server uses, so your inputs *can* be the database, but that doesn't sound like what you're intending to describe. > My question: I am curious to know how Python handles something > like this. Let's say that there are 10, 20, 50, or even 1000 users > accessing the website. They all put in their 20 to 30 pieces of > input and are waiting on some fancy magic output. How exactly does > that work? Can multiple users access the same script? Does the > Python programmer need to code in a manner that supports this? Are > requests to the script handled serially or in parallel? As Chris W mentions, there are lots of high-profile sites that handle hundreds of thousands of visitors. Usually they do this by splitting the load across multiple servers using a load-balancer, and with careful architecture that can accommodate characteristics of that load. Yes, multiple users can make use of the same script (it's usually run by a web-server which spawns multiple copies and farms out each request to a different sub-process). And yes, the programmer has to code to support this non-trivial aspect. It's as parallel as your architecture allows (you *can* make a single-threaded server that will only serve one request at a time which can be useful in development or if you want to just share with one other user). -tkc -- https://mail.python.org/mailman/listinfo/python-list
