Have found several SO Q&A's related to OpenShift's concept of application idling when there is no inbound traffic for 24 hours. Apart from the fact that there could be hacks to work around it, I was wondering, as to what is the effect since OpenShift claims that the application is brought back to full live state when an incoming request is encountered. In that case, apart from the fact that the HTTP request that causes application to go back from idle state to live/running state would run trifle slower, but is there any other inconvenience that I am missing here ?
In my experience, the first call after idling consistently fails. Subsequent calls do work then. This is probably due to a timeout, since it takes a while to spin up the gears. It may also depend on the time your application takes to activate, meaning this could be specific for my kind of application.
However I switched from the FREE plan to BRONZE a while ago and did not experience any problems since then.
Related
I have never heard of the heartbeat until the heartbleed bug. I wonder what is the difference between this and a ping, and if there are other signals to manage the connection (also, which are not data packages).
Strictly speaking, ping refers to using an ICMP ECHO request to see if the destination computer is reachable. It tests the network, but not whether the target computer is able to usefully respond to any other particular service request (I've seen computers which were ping-able but which were functionally down; the OS kernel — which is what responds to pings — was up, but all user processes were dead).
However, the term has been extended to cover any sort of client-initiated check of whether the other end is up, often done inside the protocol of interest so that you can find out whether the target machine is able to do useful work.
With heartbeats, I've typically thought of them as being where the service regularly pushes the notification to somewhere else (as opposed to being prompted by a client). The idea is that the heartbeat monitor detects if it hasn't had a heartbeat signal for a while and applies “emergency CPR” (i.e., restarts the service) if that happens. It's similar to a watchdog timer in hardware.
I view a ping and a heartbeat as being complementary: one is for the client to learn whether the service is up, and the other is for the service provider to learn whether the service is up. (The provider could use a ping, and probably does via their Nagios setup, but a heartbeat monitors something slightly different — internal timers, in particular — and is pretty cheap to implement so there's no reason not to use one.)
Ironically, the Heartbleed bug was in what I'd consider to be a ping-ing mechanism. But it's called that because it's based on a (mis-)implementation of the SSL Heartbeat Extension. Terminology's all too often just there to be abused…
I've been writing an extension that allows the user to issue voice commands to control their browser, and things were going great until I hit a catastrophic problem. It goes like this:
The speech recognition object is in continuous mode, and whenever the onerror: 'no-speech' or onend events fire, it restarts. This way, the extension is constantly waiting to accept input and reacts whenever a command is issued, even after 5 minutes of silence.
After a few days of of development, today I reached the point where I was testing it in practical use, and I found that after a little while (and with no change to anything on my part), my onend event started firing constantly. As in, looking at the console, I would see 18,000 requests being made in the space of three seconds, all being instantly denied, thus triggering onend and restarting the request.
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
Are my suspicions correct? Am I getting request limited?
Are my suspicions correct? Am I getting request limited?
Yes
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
To hide the IP source of your request you can use anonymizer networks like Tor, though it will not be fast.
It's naive to assume Google will spend resources to process all audio being recorded on your system. In your application development it is better to rely on API which provides at least some guarantees. It could be either commercial API or open source implementation like CMUSphinx.
With CMUSphinx, you can also properly implement command keyword detection and increase accuracy by specifying the grammar of the commands.
You could also use a Voice Activity Detection (VAD) algorithm to detect when a user is talking. This can be done by either setting a volume threshold or a frequency threshold (Human speech is usually less than 400hz for example). This way, you won't send useless requests to Google unless those conditions are meant. I would not recommend using Tor as this would significantly increase latency. CMUSphinx is probably the best local system option, but if still want to use a web-based service, I would recommend either using a Voice Activity Detection algorithm or finding a different web-based software.
Suppose I've got the following parts in my system: Storage (S) and a number of Clients (C). The clients are separate Web Workers and I'm actually trying to emulate something like shared memory for them.
Right now I've got just one Client and it's communicating with the Storage pretty intensively. For the sake of testing it is spinning in a for-loop, requesting some information from the Storage and processing it (processing is really cheap).
It turns out that this is slow. I've checked the process list and noticed chrome --type=renderer eating lots of CPU, so I thought that it might be redrawing the page or doing some kind of DOM processing after each message, since the Storage is running in the page context. Ok, I've decided to try to move the Storage to a separate Worker so that the page is totally idle now and… ended up getting even worse performance—exactly twice slower (I've tried a Shared Worker and a Dedicated Worker with explicit MessageChannels with the same results).
So, here is my question: why sending a message from a Worker to another Worker is exactly twice slower than sending a message from a Worker to the page? Are they sending messages through the page? Is it “by design” or a bug? I was going to check the source code, but I'm afraid it's a bit too complex and, probably, someone is already familiar with this part of Chromium internals…
P.S. I'm testing in Chrome 27.0.1453.93 on Linux and Chrome 28.0.1500.20 on Windows.
Is there a way to register code to be run when Flash is about to close (e.g., when the user closes the browser or when DOM manipulation causes the embedded player to be removed)?
In particular, I'd like for my application to send a closing packet to a remote service so the user's peers know that the user has no chance of coming back without having to wait for a timeout. I'm using URLLoader and URLRequest to maintain a BOSH connection, so I welcome solutions applicable to this specific case. However, if there are NetConnection-specific solutions, I'm sure I can learn from them too.
I'm happy to accept that this callback won't be run on a kill -9 but it would be nice to have the more graceful exit paths allow for some code execution.
It seems like the better solution would be to do this via the server side no? The server should be able to detect the disconnection, where you could then invalidate the session.
However, you could go with a client/socket based solution, albeit much more overhead. Using FMS or some other rtm real time server you could dispatch events to your web server that a connection has dropped, (though you might have issues in the case of low network connectivity, or an internet drop). I would suggest going against this though, as in my experience, FMS sucks :)
Is setting extremely low timeouts not a possibility? (i.e. < 10 seconds)
As far as I know, at the current moment, late 2011 the max-connections-per-server limit remains 6. Please correct me if I am wrong. This is bad that we cannot fix this easily as in Firefox. As far as I know this value is hardcoded.
One of the solutions is to download the Chromium's sources and rebuild them. Is there a more easy solution?
Is there any tricky way to hack this without creating a dozen of mirror-domains?
Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The javascript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the javascript app will take days.
Offtopic: do you know any other things that can be tweaked in my concrete situation?
IE is even worse with 2 connection per domain limit. But I wouldn't rely on fixing client browsers. Even if you have control over them, browsers like chrome will auto update and a future release might behave differently than you expect. I'd focus on solving the problem within your system design.
Your choices are to:
Load the images in sequence so that only 1 or 2 XHR calls are active at a time (use the success event from the previous image to check if there are more images to download and start the next request).
Use sub-domains like serverA.myphotoserver.com and serverB.myphotoserver.com. Each sub domain will have its own pool for connection limits. This means you could have 2 requests going to 5 different sub-domains if you wanted to. The downfall is that the photos will be cached according to these sub-domains. BTW, these don't need to be "mirror" domains, you can just make additional DNS pointers to the exact same website/server. This means you don't have the headache of administrating many servers, just one server with many DNS records.
I don't know that you can do it in Chrome outside of Windows -- some Googling shows that Chrome (and therefore possibly Chromium) might respond well to a certain registry hack.
However, if you're just looking for a simple solution without modifying your code base, have you considered Firefox? In the about:config you can search for "network.http.max" and there are a few values in there that are definitely worth looking at.
Also, for a device that will not be moving (i.e. it is mounted in a fixed location) you should consider not using Wi-Fi (even a Home-Plug would be a step up as far as latency / stability / dropped connections go).
BTW, HTTP 1/1 specification (RFC2616) suggests no more than 2 connections per server.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
There doesn't appear to be an external way to hack the behaviour of the executables.
You could modify the Chrome(ium) executables as this information is obviously compiled in. That approach brings a lot of problems with support and automatic upgrades so you probably want to avoid doing that. You also need to understand how to make the changes to the binaries which is not something most people can pick up in a few days.
If you compile your own browser you are creating a support issue for yourself as you are stuck with a specific revision. If you want to get new features and bug fixes you will have to recompile. All of this involves tracking Chrome development for bugs and build breakages - not something that a web developer should have to do.
I'd follow #BenSwayne's advice for now, but it might be worth thinking about doing some of the work outside of the client (the web browser) and putting it in a background process running on the same or different machines. This process can handle many more connections and you are just responsible for getting the data back from it. Since it is local(ish) you'll get results back quickly even with minimal connections.