I understand that WSGI allows the Python web app or framework to be a long-running process. Which is equivalent to FastCGI.
Then came ASGI where requests are processed asynchronously. The documentation says:
WSGI applications are a single, synchronous callable that takes a
request and returns a response; this doesn’t allow for long-lived
connections, like you get with long-poll HTTP or WebSocket
connections.
Even if we made this callable asynchronous, it still only has a single
path to provide a request, so protocols that have multiple incoming
events (like receiving WebSocket frames) can’t trigger this.
ASGI support WebSockets as well.
The HTTP+WebSocket ASGI sub-specification outlines how to transport
HTTP/1.1, HTTP/2 and WebSocket connections within ASGI.
What is the CGI successor that is equivalent to ASGI in case the program is written in some other language, for example rust.
Related
In porting mbedtls to an OS without threading context (but with TCP/IP), do you need a thread context (such as blocking I/O - with or without timeout)?
My OS does not provide a thread context. I can create network endpoints, and am notified (via call-back) when data becomes available.
I noticed that the initial SSL negotiation required the ability to read/write SSL records in a synchronous fashion.
I saw that the client programs drove the SSL engine in a loop (WANT_READ/WANT_WRITE). Is this type of polling sufficient to drive the SSL engine?
You don't need threads for mbed TLS. The SSL engine only requires the read/write calls to function (after set-up of the connection of course), but both blocking and non-blocking options are available.
I have a synchronous legacy WCF service with a potentially long running operation. For some clients, this operation seems to cause network timeouts - not at the client or service end, but somewhere in the middle at some proxy server in a network topology that is opaque to me.
The question is: Could I solve this problem by using the event based asynchronous pattern on the service side (using IAsyncResult / BeginXXX(), EndXXX())?
I am puzzled about how the callback mechanism of async services actually works on the network level. Does the client do periodic polling, or some kind of long polling, or something completely different? Unless I am simply bad at using Google (I believe I am not), the MSDN documentation seems to be completely lacking in that respect.
In only keeps going on about how async programming helps you to build responsive GUIs and whatnot.
The question is: Will it prevent proxies from timing out requests that they believe to be taking too long?
EDIT: To clarify: The service in question uses basicHttpBinding.
There are no callbacks at the network level. Async IO is all about not blocking threads on a single machine. Both communication parties can independently decide to use sync or async IO as they please. Neither party can even detect what the other chose.
You are using the SOAP-based basicHttpBinding. SOAP has no notion of asynchronous invocation. Neither does any of the other bindings.
Async IO can do nothing to resolve your timeout problem. Those timeouts are caused by something on the network (as you said). The network has nothing to do with how a service is implemented. It cannot even find out and respond to it.
The timeout things are at the http stack, and have nothing to do with the async things in programming. Google "windows http stack" you may find out why.
"In only keeps going on about how async programming helps you to build responsive GUIs and whatnot." this helps you not to block the UI thread with a long running operation like a http request/response.
A WCF service is by default multi-threading -- upon one request, a new thread is created.
On the client side if you are using .NET 4.5, you may find the client proxy classes generated support async operations, however, this has nothing to do with http timeout. These functions make asynchronous/parallel programming easier on the client side.
In short, the timeout is determined by the http stacks on both server and client. If you have controls over both server and client, you may increase timeout values on both side, as quick and dirty solution.
I don't think it prevent the timeout as the asynchronous development is on the client side independent of the protocol and the network configuration. For HTTP this is likely a registry setting.
My understanding is that windows I/O is by nature asynchronous so I don't think there will be any polling, rather once the IO is complete some sort OS level interrupt will occur. You may find this article by Stephen Cleary helpful. Also the books Windows Internals might be a good reference as well.
I keep coming across certain terms used in the Apache settings. While trying to understand the various discussions and Apache's docs, I need some help figuring out what some of these terms mean:
What is a Client?
What is the difference between a client and a child process? Are they the same?
If MaxClient = 255, does it mean that Apache will process up to 255 page loads in parallel and the rest are queued?
When is a KeepAlive request used?
What is the relationship between a child process and the request of this child process?
First, note that these answers apply either to Apache 1.x, or Apache 2.x only when using the prefork mode.
The machine that opens an HTTP connection and sends a request.
No, they are not the same. An Apache child can handle one request/client at a time, but when that one is finished, the same child can handle a new one.
Yes.
It is used to keep the HTTP connection open in case the client wants to issue another request. A client can remain connected, for example, to download images and such that are associated with a web page. Having KeepAlive On improves performance for the client (user), but having it off reduces memory usage by the server. It is a trade-off.
The Apache process launches a bunch of children. When a request comes in, the parent (root) process picks an idle child to handle that request. When that request is finished, the child is now idle and can handle a new request.
First, I hope you understand that apache 1.3 is very very old, and therefore the documentation will generally be somewhat harder to understand than the newer documentation (i.e. maybe you should upgrade if you have the choice).
I'm not sure where "Client" is referred to by itself in the apache docs by I would assume it refers to anything connecting to an open port and communicating.
Again, not sure where "child" is referred to by itself, so I can't help you there.
MaxClient is the number of processes apache will start to handle requests. It sounds like for Apache 1.3 that what you said is accurate, apache will only handle MaxClient requests in parallel (queuing the rest up to some other maximum for the queue).
KeepAlive is not really a request. It is sent in the request header to tell the server that the browser supports KeepAlive. It has to do with a feature of HTTP that allow one connection to be used for more than one access. If you allow KeepAlive your server will probably get less TCP connections.
I'm not even sure what you're asking here so you'll need to be more specific.
I am working on a website that displays some data from DB that changes frequently (Status of a queue and a chat conversation). My current setup is Apache/PHP/MySQL. Naturally I would like to avoid polling the server every x seconds since this does not scale well. I would like to do reverse ajax long polling, however, I've read that Apache does not work well with this since it quickly runs out of worker threads. There are many other web servers out there that get around this problem: nginx, tornado, etc. However, my problem is, PHP is the ONLY server-side scripting language I know. Also I've already written some PHP scripts so I'd like to keep them if I can. I am ok with switching server so long as I can still use PHP.
But after doing some more research, I've read that people say PHP (PHP-FPM?) also creates a process for every request made, which means if I have hundreds/thousands of open connections, there will be hundreds/thousands of processes, which will be problem as well.
Can I conclude that there's no good scalable ways to make long polling websites using PHP? Should I abandon PHP and learn another server scripting language? I can continue developing long polling using my current setup (Apache/PHP) for now but I don't want the choice of scripting language to pose any limitation on the scalability of my system when I deploy. So what should I do? I am not very experienced with web programming, so if any gurus out there can give me some pointers I'd appreciate it! Thank you!
PHP runned in php-fpm mode will still have limitations, especially if your code is eating a lot of memory. You won't be able to run thousands of parallel processes without some available memory. But it usually perform faster than mod_php, and at least HTTP request that do not need PHP are handled by the webserver, and if that webserver is nginx you'll get a lot more HTTP requests available in parallel.
With php-fpm you will also have a queue of waiting requests, that may be usefull in case a temporary big traffic, as at least requests are queued, not rejected.
Now the long polling operations are OK with nginx (or others, that's an example), but not with PHP. PHP is not built to be a long-running server, each request is a new process, it's really not the right choice for a KeepAlive thing. But "Divide ut regnes" (divide and rule). Your long polling tasks could run near your PHP application, but without your PHP application.
As an example look at the jappix project, this is a PHP project. But you need to put somewhere an XMPP server (like ejabberd), and a BOSH server with nginx as a proxy on port 80 to that BOSH server (so you have the xmpp chat protocol on port 80, via nginx and ejabberd, and nothing on the PHP side for that). The problem is then to connect your application authentification, identification, and such, and this will have to be done by extending the XMPP server configuration (so that it use the same LDAP server as your PHP app for example).
Your second long polling problem is the status of a queue. You may find some XMPP extensions for that, maybe. Or you may perform regular ajax queries on the queue. One of the useful technique to avoid the big number of ajax requests on your PHP application is to reschedule the next ajax check on the ajax callback of the check, based on the Fibonacci numbers (it's an example). So the first time the next ajax call will be scheduled 1 minutes after, next time 2 minutes, then 3m, 5m, 8m, 13m, 21m, 34m, 55m, 89m, 144m, etc. The idea is that it's maybe important to check new messages incoming 1 minute after a page load. As the user is still reading the same page (or drinking a coffee, talking to a friend, going to holidays without switching off his computer, etc), we can delay more and more the next checks. Is a way of assuming the user is not really active. Note that you could detect user activity by other means and alter the rescheduling.
PHP is nor right for long polling, Comet and reverse ajax technologies. You should use Node.js
I'm in the middle of performance testing a critical section of my project, when I notice a whole lot of extra threads being used to to perform WaitOrTimerCallback operations.
alt text http://lh4.ggpht.com/_p7-jVU64mGg/SZuWgUvTD7I/AAAAAAAAAEk/PUFrXrYvZh0/threads_thumb%5B1%5D.jpg?imgmax=800
On closer inspection I can see that these are being spawned by my ASMX client proxy class for operations on a remote server.
I was under the impression that these were using IO completion ports like all of my other asynchronous IO Calls.
Is it possible to get a ASMX or WCF proxy client to use IO Completion ports? If not - really what is the point?
[UPDATE]
The project was using ASMX proxy client(s). It appears that they are using the normal thread pool inorder to register a WaitOrTimerCallback. I'm now working with WCF Proxy clients. These are not spawning extra threads so i can only assume they are using the desired IO completion ports.
The ASMX Proxy class was created using Visual Studio 2008. I had added the following line to the the project file: "WebReference_EnableLegacyEventingModel>true" As the current flavour of ASMX clients do not have Asynchronous enabled by default.
I can't speak for ASMX, but WCF definitely does (and like you I'd be surprised if ASMX doesn't). Can you get the call stacks to ensure that they really are blocked on network calls (and not some other user code)?