I recently starting diving into http programming in C and have a functioning server that can handle GET and POST. My question comes in to my site load times and how I should send the response headers and response message.
I notice in Chromes resource tracking tool that there is almost no (a few ms) connecting/sending/proxy/blocking/waiting time in most cases (on the same network as the server), but the receive time can vary wildly. I'm not entirely sure what the receive time is including. I mostly see a long receive (40 to 140ms or more) time on the png files and sometimes javascript files and rarely other files, but it's not really consistent.
Could anyone shed some light on this for me?
I haven't done much testing yet, but I was wondering if I changed the method which I use to send the header/message would help. I currently have every file for the site cached in server memory along with it's header (all in the same char*). When I send the file that was requested, I just do 1 send() call with the header/file combo (it does not involve any string operations b/c it is all done in advance on server start up).
Would it be better to break it into multiple small send() calls?
Just some stats that I get with Chrome dev tools (again, on local network through a wireless router connection), the site loads in from 120ms to 570ms. It's 19 files at a total of 139.85KB. The computer it's on is a Asus 901 netbook (atom 1.6ghz, 2gb ddr2) with TinyCore linux. I know there are some optimizations I could be doing with how threads start up and a few other things, but not sure that's affecting it to much atm.
If you're sending the entire response in one send(), you should set the TCP_NODELAY socket option.
If that doesn't help, you may want to try using a packet capturing tool like Wireshark to see if you can spot where the delay is introduced.
Related
I have a kind of a complex application, which uses heavy IO: it includes ffmpeg and doing video transcoding (by software, no HW-acceleration is available).
This might be unimportant, but I wanted to emphasize it.
All video transcoding functions are working on their own std::thread, and using libev for IO management.
Hardware details:
CPU architecture is ARM
OS is Debian.
Now, I'm trying to use ping to check if a particular server is available. I found ping's open source, and included in the application. This is running an a completely different std::thread.
Problem:
If there is no video-transcoding in progress, ping function works as intended.
However, when there is a CPU-intensive transcoding, ping function 99% returns with timeout.
I suspect there is some kind of IO starving, so I deep dived into pings source:
I found out that ping uses the old select function call to detect if there is an I/O available. I was almost sure this causing the problem, and I have refactored the code: dropped select, and put libev into action.
But unfortunately the starving still stays the same.
I have almost accepted this, as the video transcoding really puts a huge load onto the CPU (70-80%).
But, if I run my application from an SSH session #A, and run ping from another SSH session #B, my application can do the transcoding, and there is no singe lost packet from ping on session #B.
Conclusion:
The hardware seems capable of running my heavy application in parallel with ping.
Question:
I am really curious of:
Is there a limitation per process on Linux on how many IOs can the process use? (I guess, but how can I know this limitation? How can I raise this limitation? How can I check current usage?)
If there is not any problems with IO limitation, what else can cause this kind of "starving-like" problems between std::threads? (Anyway, pings thread seems not blocking, as it receives the timeout. It just does not receive a free IO operation) More accurate: ping actually CAN send out packets, but they just do not seem arriving back. And I am almost sure those ping packets replys are coming back, just my application is not getting a green light for READ operation.
We're working with a C++ webrtc data channels library and in our test application, upon sending a few small packets that would totally amount to about 256kB, the usrsctp_sendv() call returns -1 (with errno as EWOULDBLOCK/EAGAIN which means "Resource is temporarily unavailable"). We believe this is because we're hitting the usrsctp's send buffer limit, which is 256 kB by default. We've tried adding several sleep delays in between each send call hoping it clears that buffer, but nothing works.
The receiving side, (a JS web page) does indeed receive all the bytes that we've sent up until it errors out. It's also worth noting that this only happens when we try to send data from the C++ application to the JS and not the other way around. We tried looking around mozilla's datachannels implementation, but can't seem to draw any conclusions on what the issue could be about.
It is hard to answer such question straight away. I would start looking into wireshark traces in order to see if your remote side (JS page) actually acknowledges data you send (e.i. if SACK chunks are sent back) and what is the value of received buffer (a_rwnd) reported in these SACKs. It might be possible that it is not an issue on your side, but you are getting EWOULDBLOCKS just because sending side SCTP cannot flush the data from buffers because it is still awaiting for delivery confirmation from remote end.
Please provide more details about your case, also if this is possible provide sample code for your JS page.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have to make connections form one server to many PCs ( ~1000 PC). These PC are connected by a Wifi Network in the same Building.
Each PC have a dedicated connection with the server. Form its IP address, the server knows the specific data to generate to him.
I have to send a dedicated short strings over network to each PC. (~30 characters by a string)
The dedicated string is sent by a frequency of 30 strings by a second to each PC.
The problem is that these sent data are critical and should be sent in real time.
Which solution is the faster and the most robust in my case?
I assume you have two PC connected by some Ethernet or wifi, or good enough modern Internet connection (both on Earth; no interplanetary ...; no pigeon IP RFC1149 or 1200 baud analog modem from the 1970s).
Then 30 strings of about 30 chars per second is about a kilobyte per second, not a big deal, and certainly not high frequency as you claim.
My current fiber internet connection at home (near Paris, France) is able of a dozen of megabytes per second of download, and at least a megabyte per second of upload. A few years ago it was ADSL with about one megabyte per second download. I never had at home an Internet connection for which a kilobyte each second was a high load. (If you are in interplanetary space, or in the most remote and desolate places of Africa or Antarctica, then 1Kbyte/sec might be an issue in 2016, but then you are very unlucky regarding Internet connection).
Your HTTP setup might use websockets (so a bit like your second solution). You could use libonion (an HTTP server library) on the server side, and libcurl (an HTTP client library) on the client side. Periodically polling (e.g. issuing an HTTP request twenty times per second) would require more resources (but that is still manageable). An HTTP connection would be slower, because HTTP adds some overhead (the headers in HTTP requests & responses).
Notice that HTTP protocol is above TCP/IP, so will definitely use BSD sockets on operating systems providing them (Linux, Windows, MacOSX, ...). So a "web solution" is using sockets already.
If you use sockets, you'll need to define a protocol on them (or using some existing one, like HTTP or JSONRPC).
I'll go for a socket approach. Probably some JSON related thing like JSONRPC. Be aware, if you code on the socket API, that TCP/IP is a stream protocol without message boundaries. You'll need to buffer on both sides, and define some message boundary conventions. You might send JSON, terminated by a newline (the ending newline is JSON compatible, and facilitate delimiting messages).
You might be interested by messaging libraries such as 0mq.
addenda (after question edition)
Your new question is widely different (thousands of PCs, not only two of them; I guess they are in the same building, or at least the same continent.). You need about 1000 * 30 * 30 i.e. less than a megabyte per second of bandwidth.
I would still suggest using some sockets. Probably 0mq is even more relevant. You might make each message some JSON. You need to document very well the protocol you are using. Probably, you want the server to have several threads (e.g. a dozen, not many thousands of threads) to loop on emitting messages (on TCP). Perhaps you might want to have a server with several Ethernet connections (but a megabyte per second can go on one single Ethernet, even a slow 100Mbits/sec one).
30 bytes, 30 times per second, is 900 bytes per second. That's not fast at all; either method will work fine. And note that an HTTP connection uses a socket anyway.
It sounds like your "socket" option implies keeping a socket connection open all the time, as opposed to HTTP, where (typically) a separate connection is opened for each request. I think what you're really asking is:
Make the client periodically ask the server if there's new data, or
Have the server immediately send the new data as soon as it's available.
That depends entirely on what your program's requirements are, which we don't know.
A thousand biderectional TCP communications require 1000 sockets (unless you want to open and close connection for every string sent, but that would be a major performance drain).
That is dangerously close to the customary soft limit of maximum open file descriptors (which is 1024). And it is 25% of customary hard limit of 4096. Given that, I find that TCP is not well suited here.
Instead, I suggest going with UDP. With UDP, you'd need only handful of sockets (even one would do, but with multiple you could scale better). It would have a problem of reliability, but you can implement some sort of it on top of UDP.
Please make yourself familiar with the OSI model.
Sockets (UDP, TCP) are on layer 4, HTTP is on layer 5, thus using a layer 4 protocol already.
I'm really new to this whole socket and server development, I'm not yet familiar with how it all works.
I made a simple flash application that needs to communicate with a socket,
With that, I used a socket that supports AS3 and works on "Red Tamarin",
Well I'll get to the point:
I currently have a loop that always runs socket.receive()
It responds and even displays text that I send from my flash application.
My goal is to get a simple online flash game,
Probably use SQL / SQLite to save information and export it to players,
What I don't understand is how I can take it there..
What I thought I'll need to do is something like so:
On the server side:
Have a loop that runs as long as the server is alive, that loop should always check every connection it has with clients and wait for commands coming from them, such as log in, update player position, disconnect, request list of objects in given positions
Client side:
Send information to the server according to the action, like when a player moves, send the new position to the server in a similar way to this : "MovePlayer[name][x][y]"
Is my plan really how things should be?
And about the actual information being sent, I'm curious, will it be efficient to constantly send the server string data? (that's what I'm used to work with, not some weird bytes and stuff)
Thanks in advance!
You're on the right track. But I encourage you to first define a communication protocol. You can start by defining what a command looks like. For example:
COMMAND <space> PARAM1 <space> PARAM2 <line-break>
A few considerations on the protocol definition:
What if PARAM1 is a string and contains spaces? How can you tell the start and end of each parameter?
Your parameters could also contain a line-break.
If your client application is installed by your clients, they'll need to update it once in a while. To complicate even further, they may run an older version and expect it to work, even if you have changed your protocol. This imposes a need for protocol versioning. Keep that in mind if you require user interaction for updating the client part of your application.
These are the most fundamental considerations I can think for your scenario. There may be other important considerations, but most of them depend on how your game works. Feel free to amend my list if you think I forgot something OP should consider.
After defining what a command looks like, document all commands you believe your applications needs. Don't segregate definition of a command unless it becomes too complex or excessively long for some of your operations. Try to keep things simple.
Now back to your questions:
Is my plan really how things should be?
Yes. That's exactly how it should be.
And about the actual information being sent, I'm curious, will it be efficient to constantly send the server string data? (that's what I'm used to work with, not some weird bytes and stuff)
That depends on a number of factors:
Which protocol you're using (TCP, UDP, etc);
Number of concurrent clients;
Average time to process a command;
Do you broadcast updates to other players?
How you did implement your server application;
Physical contraints:
Hardware: CPU, memory, etc;
Network: bandwidth, latency, etc;
(source: it20.info)
look at this
https://code.google.com/p/spitfire-and-firedrop/
there you will see the basic of building a socket server with redtamarin
see in particular
https://code.google.com/p/spitfire-and-firedrop/source/browse/trunk/spitfire/src/spitfire/Server.as
the details is as follow, redtamarin basically use blocking sockets with select()
with a max hard coded FD_SETSIZE of 4096
see:
https://code.google.com/p/redtamarin/wiki/Socket#maxConcurrentConnection
so here what happen in your server loop
you basically have an array of sockets object
you loop every x milliseconds and for each socket
you ask if you can read it
if you can read on the socket, you then compare if this socket obj is the server
if it is the server that means you have a new connection
if not that means a client try to send you data and so you read this data
and then pass it to an "interpreter"
later in the same loop you check if the socket obj is still valid
and if you can write to it
if you can write and the socket object is not the server
then you can send data to the client
here the equivalent code in C for reference
http://martinbroadhurst.com/source/select-server.c.html
http://www.lowtek.com/sockets/select.html
for a very basic example look at socketpolicyd
https://code.google.com/p/spitfire-and-firedrop/wiki/socketpolicyd
https://code.google.com/p/spitfire-and-firedrop/source/browse/trunk/socketpolicyd/src/spitfire/SocketPolicyServer.as
and compare the implementation with Perl and PHP
http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
I have a Django view that does some pretty heavy processing and takes around 20-30 seconds to return a result.
Sometimes the user will end up closing the browser window (terminating the connection) before the request completes -- in that case, I'd like to be able to detect this and stop working. The work I do is read-only on the database so there isn't any issue with transactions.
In PHP the connection_aborted function does exactly this. Is this functionality available in Django?
Here's example code I'd like to write:
def myview(request):
while not connection_aborted():
# do another bit of work...
if work_complete:
return HttpResponse('results go here')
Thanks.
I don't think Django provides it because it basically can't. More than Django itself, this depends on the way Django interfaces with your web server. All this depends on your software stack (which you have not specified). I don't think it's even part of the FastCGI and WSGI protocols!
Edit: I'm also pretty sure that Django does not start sending any data to the client until your view finishes execution, so it can't possibly know if the connection is dead. The underlying socket won't trigger an error unless the server tries to send some data back to the user.
That connection_aborted method in PHP doesn't do what you think it does. It will tell you if the client disconnected but only if the buffer has been flushed, i.e. some sort of response is sent from the server back to the client. The PHP versions wouldn't even work as you've written if above. You'd have to add a call to something like flush within your loop to have the server attempt to send data.
HTTP is a stateless protocol. It's designed to not have either the client or the server dependent on each other. As a result the state of either is only known when there is a connection is created, and that only occurs when there's some data to send one way or another.
Your best bet is to do as #MattH suggested and do this through a bit of AJAX, and if you'd like you can integrate something like Node.js to make client "check-ins" during processing. How to set that up properly is beyond my area of expertise, though.
So you have an AJAX view that runs a query that takes 20-30 seconds to process requested in the background of a rendered page and you're concerned about wasted resources for when someone cancels the page load.
I see that you've got options in three broad categories:
Live with it. Improve the situation by caching the results in case the user comes back.
Make it faster. Throw more space at a time/space trade-off. Maintain intermediate tables. Precalculate the entire thing, etc.
Do something clever with the browser fast-polling a "is it ready yet?" query and the server cancelling the query if it doesn't receive a nag within interval * 2 or similar. If you're really clever, you could return progress / ETA to the nags. However, this might not have particularly useful behaviour when the system is under load or your site is being accessed over limited bandwidth.
I don't think you should go for option 3 because it's increasing complexity and resource usage for not much gain.