I am currently uploading files in ActionScript 3 using the upload() method of the FileReference class.
I built an uploader than can do simultaneous or parallel uploads, having a variable set the number of maximum uploads at a time.
I noticed that for Internet Explorer I could be uploading 10 or more files simultaneously, but FireFox and Safari seems to cap the number of uploads to 2. That is, when I call the upload method on per say, 3 files, only 2 will get events back (such as ProgressEvent.PROGRESS). Only when one of the 2 uploads finishes, then the 3rd one will start. This behavior does not happen for Internet Explorer. I have tried with a large number of files, and some big files, to make sure this behavior was consistent.
I was wondering if anyone noticed this behavior please, and if so, what is the reason for this behavior please?
I appreciate your help,
Thank you very much,
Rudy
There's a limited number of simultaneous connections to each host, which varies from browser to browser. This limit is generally discussed in the context of downloading many things (e.g. images) simultaneously from the server, but it seems to apply to uploads as well (this makes sense because connections are two-way).
Check out this related question, especially this answer that expands on what I've said here. It links to some useful articles.
Related
Adding BackgroundTransferRequest's to the BackgroundTransferService once the app is in the background is successful, but the new requests don't actually run until the app comes back to the foreground. Not so great for my scenario of downloading lots of small files that may take a fair amount of time to complete.
I imagine Microsoft has probably implemented this behavior by design(?), but does anyone know a way around this or an alternative approach?
A bit of background to the problem:
I'm developing a Windows Phone 8 map app that allows sections of maps to be downloaded and cached for offline use. This process can lead to 1,000's of map tiles needing to be downloaded.
I've created a process that spawns the full limit of 25 BackgroundTransferRequest's, then adds more to the BackgroundTransferService as requests complete. This all works fine until the app actually goes in to the background.
I have considered doing some web server side processing to allow tiles to be bundled in to a zip and downloaded as a single request, but this is extra complication and will result in twice the space being required on the phone to complete the download and then extract the files before deleting the original package. But, ideally I'd like to find a way to force new BackgroundTransferRequest's to start running in the background.
It's not clear what your actual question is but I'd definitely recommend bundling them into a zip file and then downloading that. It's almost always easier to work with a single file than thousands.
If disk space is really a genuine issue (not just a theoretical one - I've put thousands of map tiles in under 20mb before, but it will depend on image complexity & quality) then you could make a few zip files. then you'd avoid the BTR issue and not take up as much disk space (even temporarily).
I've used background transfer service (BTS) API for Windows Phone in two apps and experienced very bad problems. It became one of the main source of bug in the two apps as for some reasons, download are often refusing to start, whatever I set in the flags (Connected to wifi, not connected, connected to a power outlet, etc.), and it was random from a user to another. This and bad response from the servers.
Is there a more customized way to achieve it? Which threads or loop remains alive in my app when I'm navigating to the external:// world? I should probably check with counters.
My main question remains: appart from the BTS, is there something to allow a 3-4 megs file to upload even if I navigate out from my app to play an mp3 from an external:// app?
Once you exit your app, you are pretty much shut down. You can masquerade as a location tracking background agent to remain in the background when you get deactivated, though you'll suck battery and I believe there can only be one of these active at a time. Generally, highly not recommended (and you'll probably fail certification).
A better way to do this if BTS is not to your liking is to use a ResourceIntensiveTask. This will only be triggered when the user is plugged in and has WiFi but will allow you to run whatever you want for as long as the conditions are met (for example, at night) which should be plenty of time to upload a 3-4 MB file.
so I load large amounts of data from services. I just updated our project to the latest 4.7 FB with Flex 4.9 SDK and AIR 3.4. Implemented workers. They seem to work great for one-off tasks EXCEPT when it comes to internet data loading. I haven't found the magic limit yet, but it seems as though if you load an internet request (Loader, URLLoader, HttpService... whatever) that is receiving a large replay, the worker just locks up and quits. The main thread can do this just fine in all cases (but with UI being unresponsive until the load is done). This is why I was so excited about workers is to offload the sometimes large data loads to the background workers.
Has anyone else run into this? I saw comments on the Worker class docs online where a few other people have seen similar problems and suggest putting data loading from the internet back on the main thread. Seems like "what's the point of a worker then"?
Can they only do local calculations? Math is cool... but HTTP Gets are not?
I tried giving the worker app privileges.. no help there. Is there a magic worker.canloadlargefiles = true? (rhetorical).
Any direction or help here would be greatly appreciated.
Well not a solution, but a workaround. Instead of digging internals of VM, use KISS (Keep It Simple and Stupid) principle, divide your data into managable chunks. You do not need to divide the files or data but can tell the server do it by a request format so it sends you manageable portions of data that will not timeout the VM. Retrieve and join the chunks on the client side to form the big file back.
Thats my two cents.
I am trying to find the bottle neck in this site here. Granted, there is not much on the page now, but I will be uploading nearly 300 images to this site in the coming week which I expect to take a toll on speed and performance. Therefore, I want to cut down on everything other than image loading as much as possible.
I've attached an image which shows what I'm seeing in SpeedTracer, but the data makes no sense to me. The page loaded in around 4 seconds, yet each of these blue bars is claiming to have taken ~ 3.5 seconds to load. How can this be?
Could someone try to provide me with some explanation as to what I'm looking at here?
Thanks,
Evan
What you're looking at is a waterfall of the page and it's resources loading...
Each row represents an individual resource, and show's when it started loading and how long it took.
Browsers can download resources in parallel - Chrome can download up to six resources from the same hostname e.g. www.nanisolutions.com, at the same time. It can also download up to six resources from every other hostname at the same time (up to maximum of 40 connections)
Quite why you screen grab shows the request for the root HTML document starting after some of the items I'm not sure but I'm wondering if you are on the same network as the webserver?
I'd be tempted to run the same test using webpagetest.org
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.