After reading the question on how to build a complex web_ui application, I'm wondering if it will be performant enough.
I'm building a fairly large web application and am wondering if I should split up the main parts or if I can safely serve everything on one page (assuming that I don't mind that the user has to download a pretty big junk of .dart code).
It is usually considered best practice to split up your code once it reaches a certain size (that size depends on your target audience, your servers etc.).
Dart2js supports lazy loading of libraries so that you load an initial app chunk on page load and then load separate chunks through AJAX requests as they are needed. This will save you bandwidth and speed up page load time.
You can start with serving a single file, but if you expect that will not be performant enough, I would build lazy loading into the app from the start.
Note: at this time there are limitations on how many files can be lazy loaded: https://code.google.com/p/dart/issues/detail?id=3940
Related
I wonder if it is ok (apart from the fact it is done million times daily...) to feed ImageMagic's convert command with user-uploaded files?
Obviously, ImageMagic has a large attack front, as it is capable of loading tons of formats and thus using vast amounts of code processing input data.
Excessive CPU or memory consumption do no harm, as this can be kept under control by simple means (for example by ulimit). Abitrary file access or runing injected code with network access however must be prevented by convert. Can we expect this?
Are there procedures to follow for the ImageMagic authors that would provide a feasable amount of security against such exploits?
I'm building an Asp.Net MVC4 Application with product pages. I have come by the ImageResizer Library for handling and serving the images. My page has jpg thumbnails 160x160px in dimensions and 3~5KB size each.
To my understanding using the ImageResizer library i could just upload the original large product image 600 x 600px & 10~20KB and resize it on the fly to the thumbnail size when the visitor requests the page. Something like:
<img src="#Url.Content("~/images/imagename?width=160&height=160")" alt="">
Which i understand is fine for a couple of images but my product page consists of 20 to 100 product jpg unique thumbnails (depending on pagesize).
Should performance hurt with processing on-the-fly 20-100 pics each time? Has anyone faced a similar scenario? I could always go back back and generate 2 different images (thumbnail and large) during the upload process but i'm very curius if i could get away with just one image per product and dynamic resizing.
When i say performance i mean that anything above 0.5 - 1s extra response time is a no-no for me.
In documentation it is mentioned, that there's caching plugin, which improves performance by 100-10000X:
Every public-facing website needs disk caching for their dynamically resized images (no, ASP.NET's output cache won't work). This module is extremely fast, but decoding the original image requires a large amount of contiguous RAM (usually 50-100MB) to be available. Since it requires contiguous, non-paged, non-fragmented RAM, it can't be used a (D)DOS attack vector, but it does mean that there is a RAM-based limit on how many concurrent image processing requests can be handled. The DiskCache plugin improves the throughput 100-10,000X by delegating the serving of the cached files back to IIS and by utilizing a hash-tree disk structure. It easily scales to 100,000 variants and can be used with as many as a million images. It is part of the Performance edition, which costs $249. The DiskCache plugin requires you to use the URL API (read why).
http://imageresizing.net/plugins/diskcache
http://imageresizing.net/docs/basics
When it comes to websites, every operation that can be cached should be. This allows the server to deal with more visitors rather than more processing.
You could either use the caching plugin for ImageResizer, or manually write to file using a certain filename, e.g.: product_154_180x180.jpg where 154 is product id, and 180 is the width and height, then check for whether it exists when you want to display it.
If you do the latter, you may be able to use the server to manage this for you, by linking to the expected filename in the page source, and if it doesn't exist, the server then calls a script that resizes and writes the resized image to disk using imageresizer.
This last method will also avoid the call to ImageResizer saving you some processing power.
To get around an iOS limitation with static libraries I'm embedding some binary resources (a few small images, primarily) in a static library as byte arrays.
Functionally - this works well.
My question is - what are the drawbacks of such an approach?
Specifically, if someone were to go overboard with this and embed tons of large resources in the binary - would this cause any problems?
Because I'm not 100% sure about how iOS loads binaries/etc I'm not sure if this data is all loaded into memory at the point the app is loaded, or is it kept in the DATA section and loaded from disk on demand?
It depends on how you're generating the byte array. Is it PNG/JPEg data or raw pixels? The latter will be much larger in terms of storage space and memory than if you are storing JPEG/PNG data.
And the data in the byte array is always going to be in memory, and it will probably need to be copied again to actually load the image so you're using twice the memory as if you'd loaded it from a file.
Also you are missing out on some of the built-in behaviours that iOS has for managing images. For example if you load an image using [UIImage imagedNamed:#"foo.png"] the image is cached so it's quicker to load next time, and loading multiple copies doesn't result in duplicate memory usage, and the cache is automatically cleared if the memory runs low. If you load the image from data, you're missing out on those features.
The conventional approach is to supply a resources bundle along with your library and then load assets from the resources bundle using the NSBundle methods (you can load additional bundles and then use the pathForFile:... methods just like you do with the mainBundle).
I was wondering, which way of managing thumbnail images make less impact to web server performance.
This is the scenario:
1) each order can have maximum of 10 images.
2) images does not need to store after order has completed (max period is 2 weeks).
3) potentially, there may have a few thousands of active orders at anytime.
4) orders with images will frequently visit by customers.
IMO, pre-generate thumbnail in hard disk is a better solution as hard disk are cheaper even with RAID.
But what about disk I/O speed, and resource it need to load images? will it take more resource than generate thumbnails at real-time?
It would be most appreciate if you could share your opinion.
I suggest a combination of both - dynamic generation with disk caching. This prevents wasted space from unused images, yet adds absolutely no overhead for repeatedly requested images. SQL and mem caching are not good choices, both require too much RAM. IIS can serve large images from disk while only using 100k of RAM.
While creating http://imageresizing.net, I discovered 29 image resizing pitfalls, and few of them are obvious. I strongly suggest reading the list, even if it's a bit boring. You'll need an HttpModule to be able to pass cached requests off to IIS.
Although - why re-invent the wheel? The ImageResizer library is widely used and well tested.
If the orders are visited frequently by customers, it is better to create the thumbnails ones and store on disk. this way the webserver doesn't need to process the page that long. It will speed up the loading time of your webpages.
It depends on your load. If the resource is being requested multiple times then it makes sense to cache it.
Will there always have to be an image? If not, you can create it on the first request and then cache it either in memory, or more likely a database, for subsequent requests.
However, if you always need the n images to exists per order, and/or you have multiple orders being created regularly, you will be better off passing the thumbnail creation off to a worker thread or some kind of asynchronous page. That way, multiple request's can be stacked up, reducing load on the server.
In my current project (Rails 2.3) we have a collection of 1.2 million keywords, and each of them is associated with a landing page, which is effectively a search results page for a given keywords. Each of those pages is pretty complicated, so it can take a long time to generate (up to 2 seconds with a moderate load, even longer during traffic spikes, with current hardware). The problem is that 99.9% of visits to those pages are new visits (via search engines), so it doesn't help a lot to cache it on the first visit: it will still be slow for that visit, and the next visit could be in several weeks.
I'd really like to make those pages faster, but I don't have too many ideas on how to do it. A couple of things that come to mind:
build a cache for all keywords beforehand (with a very long TTL, a month or so). However, building and maintaing this cache can be a real pain, and the search results on the page might be outdated, or even no longer accessible;
given the volatile nature of this data, don't try to cache anything at all, and just try to scale out to keep up with traffic.
I'd really appreciate any feedback on this problem.
Something isn't quite adding up from your description. When you say 99.9% being new visits, that is actually pretty unimportant. When you cache a page you're not just caching it for one visitor. But perhaps you're saying that for 99.9% of those pages, there is only 1 hit every few weeks. Or maybe you mean that 99.9% of visits are to a page that only gets hit rarely?
In any case, the first thing I would be interested in knowing is whether there is a sizable percentage of pages that could benefit from full page caching? What defines a page as benefitting from caching? Well, the ratio of hits to updates is the most important metric there. For instance, even a page that only gets hit once a day could benefit significantly from caching if it only needs to be updated once a year.
In many cases page caching can't do much, so then you need to dig into more specifics. First, profile the pages... what are the slowest parts to generate? What parts have the most frequent updates? Are there any parts that are dependent on logged-in state of the user (doesn't sound like you have users though?)?
The lowest-hanging fruit (and what will propagate throughout the system) is good old fashioned optimization. Why does it take 2-seconds to generate a page? Optimize the hell out of your code and data store. But don't go doing things willy-nilly like removing all Rails helpers. Always profile first (NewRelic Silver and Gold are tremendously useful for getting traces from the actual production environment. Definitely worth the cost) Optimize your data store. This could be through denormalization or in extreme cases by switching to different DB technology.
Once you've done all reasonable direct optimization strategy, look at fragment caching. Can the most expensive part of the most commonly accessed pages be cached with a good hit-update ratio? Be wary of solutions that are complicated or require expensive maintenance.
If there is any cardinal rule to optimizing scalability cost it is that you want enough RAM to fit everything you need to serve on a regular basis, because this will always get you more throughput than disk access no matter how clever you try to be about it. How much needs to be in RAM? Well, I don't have a lot of experience at extreme scales, but if you have any disk IO contention then you definitely need more RAM. The last thing you want is IO contention for something that should be fast (ie. logging) because you are waiting for a bunch of stuff that could be in RAM (page data).
One final note. All scalability is really about caching (CPU registers > L1 cache > L2 cache > RAM > SSD Drives > Disc Drives > Network Storage). It's just a question of grain. Page caching is extremely coarse-grained, dead simple, and trivially scalable if you can do it. However for huge data sets (Google) or highly personalized content (Facebook), caching must happen at a much finer-grained level. In Facebook's case, they have to optimize down to the invidual asset. In essence they need to make it so that any piece of data can be accessed in just a few milliseconds from anywhere in their data center. Every page is constructed individually for a single user with a customized list of assets. This all has to be put together in < 500ms.