Browsers render content after "enough" data has been received or once data stops flowing in (Content Length reached, for example).
I want to slowly stream data to the browser; to do this, I have to work around this data caching.
For example, instead of sending 40 bytes of JavaScript, I have to send the 40 bytes of JS followed by about 4 KB of spaces in order to get the browser to interpret the script.
This works fine. But I don't remember where I first heard the number "4 KB" and was wondering what the true required amount is per browser.
I could of course write a bunch of tests to find these numbers, but I was curious if anyone has already done this work for me. I am also at a loss for what to ask the Google regarding this.
If you want to know what response size browsers need before rendering content when you flush the response early, I found these numbers buried in a comment in a post about flushing the document early:
IE: 255 bytes
Safari: 1K
Chrome: 2K
If you're looking into this so that you can implement streaming, you might want to look into how various comet implementations handle this.
Related
From what I have understood, and been able to test, thus far Chrome (v 19 on Windows) "limits" local storage to 2.49 Mb, a figure I have verified for myself. However, the storage scenario I have to deal with is rather more complicted. I have an IDE like interface for which I am fetching context sensitive help from the server when the user hovers over something relevant. Once this is done I store that help text (HTML typically between 120 and 1024 chars) to localStorage. No problems thus far. However, the IDE is a very large and complex one and in due course the localStorage will contain 100s or even 1000s of keys. What is not clear to me is this - will the results of the rather rudimentary localStorage limits tests (my own and ones I ran into on the web) still be valid - the tests are done by storing a long char string under one key which is significantly different from what I have described above. I assume that at the very least there is an overhead associated with the space consumed by key storage itself.
I am working on a web application and I am using polling approach to check if there is any update needed. These polling requests occur in every 1 or 2 seconds. The size of the response is 240 bytes if there is no update needed(An empty response is returned in that case) and around 10 KBs which is the size of the content itself. My problem is, since it returns at least 240 B in every seconds approximately, is there a way to optimize this response by pushing the boundaries a bit more?
When I checked the contents of the response, I saw that the 50 bytes are essential for me(session id and status code). However, there are some information in the header such as connection type, timeout and content-type. These settings will be same for each request of this type(i.e. it always requires content type as: "text/html; carset=utf-8"). So, can I just assume these settings in client side and prevent the server from sending these header info?
I am using django on the server side and jQuery for sending ajax requests by the way. Also, any type of push technology is out of question for now.
It does add up, but not as much as you think. If you polled every sec for a full hour, you'd have only used 864K, less than a typical webpage would require with an unprimed cache. Even if you did it for a full day, you're talking about ~20M. Maybe if you're someone like Twitter, you might need to be concerned about this, but I doubt you'll be getting anywhere near the traffic it would take for this to actually be problematic.
Nevertheless, you can of course customize the headers of the request, but what if any impact this will have on the client will be a matter to testing. Some headers can probably be dropped, but others may surprise you, and it technically could vary browser to browser, as well.
One solution to this kind of problem is "long polling". The polling client will send a request, and the webserver checks to see if there is an update. If there is not, the webserver sleeps for a second or two and then checks again in a loop, without sending a response. As soon as this loop sees an update, it sends a response. To the client web browser, it will look like the server is congested and taking a long time to respond, but actually the relevant data is being transmitted promptly and the "no data" responses are simply being skipped.
I'd recommend adding a timeout to the loop -- say 30 or 60 seconds -- after which the webserver would reply with "no data" as usual. Even just a 30 second cycle would cut your empty response load by a factor of 15-30.
Caveat: I've read about this kind of implementation but I haven't tried it myself. You will need to test compatibility with various web browsers to ensure that this fairly nonstandard method doesn't cause issues on the client side.
I was building out a little project that made use of HTML localStorage. While I was nowhere close to the 5MB limit for localStorage, I decided to do a stress test anyway.
Essentially, I loaded up data objects into a single localStorage Object until it was just slightly under that limit and must requests to set and get various items.
I then timed the execution of setItem and getItem informally using the javascript Date object and event handlers (bound get and set to buttons in HTML and just clicked =P)
The performance was horrendous, with requests taking between 600ms to 5,000ms, and memory usage coming close to 200mb in the worser of the cases. This was in Google Chrome with a single extension (Google Speed Tracer), on MacOSX.
In Safari, it's basically >4,000ms all the time.
Firefox was a surprise, having pretty much nothing over 150ms.
These were all done with basically an idle state - No YouTube (Flash) getting in the way, not many tabs (nothing but Gmail), and with no applications open other than background process + the Browser. Once a memory-intensive task popped up, localStorage slowed down proportionately as well. FWIW, I'm running a late 2008 Mac -> 2.0Ghz Duo Core with 2GB DDR3 RAM.
===
So the questions:
Has anyone done a benchmarking of sorts against localStorage get and set for various different key and value sizes, and on different browsers?
I'm assuming the large variance in latency and memory usage between Firefox and the rest is a Gecko vs Webkit Issue. I know that the answer can be found by diving into those code bases, but I'd definitely like to know if anyone else can explain relevant details about the implementation of localStorage on these two engines to explain the massive difference in efficiency and latency across browsers?
Unfortunately, I doubt we'll be able to get to solving it, but the closer one can get is at least understanding the limitations of the browser in its current state.
Thanks!
Browser and version becomes a major issue here. The thing is, while there are so-called "Webkit-Based" browsers, they add their own patches as well. Sometimes they make it into the main Webkit repository, sometimes they do not. With regards to versions, browsers are always moving targets, so this benchmark could be completely different if you use a beta or nightly build.
Then there is overall use case. If your use case is not the norm, the issues will not be as apparent, and it's less likely to get noticed and adressed. Even if there are patches, browser vendors have a lot of issues to address, so there a chance it's set for another build (again, nightly builds might produce different results).
Honestly the best course of action would to be to discuss these results on the appropriate browser mailing list / forum if it hasn't been addressed already. People will be more likely to do testing and see if the results match.
In html, I know there is a chunked encoding. Anyone knows its advantage?
It's not part of HTML - it's part of HTTP.
It means that you can start writing the content to the output stream before you know exactly how large the output is going to be. This means you don't have to buffer the whole page (or whatever you're delivering) in memory or on disk before you start transmitting.
You need to be aware of its disadvantages, too. Some firewalls/antiviruses want to download the complete response so they can inspect it, and will therefore block any incomplete response chunks from reaching the client.
A lot of firewalls have chunked encoding set to block by default, especially on corporate networks. If you want people to be able to reach your web service from their work computers, you need to either https the whole website (since https traffic cannot be inspected), or avoid chunked transfers.
The only situation that I can think of where that downside is justified is https streaming. If you don't need streaming, it's not worth it, in my opinion.
Responding to comment below here because I think it's important.
Network problems with chunked responses are very common. In my current project (B2B so every customer is behind a corporate network) I estimate roughly 3/4 customers experience issues.
To prove/disprove, I set up a test that sends 2 identical responses, one regular and one chunked (streaming chunks of html in 1 sec intervals for 3 minutes). Chunked response was consistently blocked (customer observed blank page) or accumulated (customer observed blank page for 3 minutes followed by complete rendering of html). Same chunked response was fine over https (customer observed incremental rendering of html in 1 sec intervals). I ran this on different customers/firewalls.
This is a known issue. You can read up on websockets, part of their appeal is that they help overcome these very common firewall/proxy problems.
I am looking into plotting a very large data. I've tried with FLOT, FLOTR and PROTOVIS (and other JS based packages) but there is one constant problem I'm faced with. I've tested 1600, 3000, 5000, 8000 and 10k points on a 1000w 500h graph which are rendered all within a reasonable time on PC browsers (IE and FF). But when rendered on MACs FF/Safari, starting with 500 data points, the page becomes significantly slow and/or crashes.
Has anyone come across this issue?
Yes, don't do that. It seems pretty unlikely to me that 10k points are actually going to be visible/useful to the user all at once.
You should aggregate your data (server-side) and then if they want to zoom in on areas of the data, use AJAX requests to get that area and replot.
If you use flot, they have examples showing selection, i.e. here: http://people.iola.dk/olau/flot/examples/zooming.html
(I can't comment the Ryley answer yet, that's why I put some remarks here)
What about an offline use. Html is a great format for documents, set aside the server/client stuff.
JavaScript, Canvas and all those fancy client-side technologies could be used to build nice interactive files, like data reports containing graphs with zoom and pan features ...