分模块构建cloud项目?_在The Cloud中缩放时捏几分钱

分模块构建cloud项目?

Running a site in the cloud and paying for CPU time with pennies and fractions of pennies is a fascinating way to profile your app. I mean, we all should be profiling our apps, right? Really paying attention to what the CPU does and how many database connections are main, what memory usage is like, but we don't. If that code doesn't affect your pocketbook directly, you're less likely to bother.

在云中运行网站并花几分钱和几分钱的钱花CPU时间是一种有趣的配置应用程序的方式。 我的意思是，我们所有人都应该对我们的应用进行性能分析，对吗？ 确实要注意CPU的功能以及主要的数据库连接数，内存使用情况，但是我们没有。 如果该代码不会直接影响您的皮夹，那么您就不太可能打扰。

Interestingly, I find myself performing optimizations driving my hybrid car or dealing with my smartphone's limited data plan. When resources are truly scarce and (most importantly) money is on the line, one finds ways - both clever and obvious - to optimize and cut costs.

有趣的是，我发现自己在驾驶混合动力汽车或处理智能手机的有限数据计划方面进行了优化。 当资源真正稀缺，并且(最重要的是)资金到位时，人们就会找到聪明和明显的方法来优化和削减成本。

云中的草率代码要花钱 (Sloppy Code in the Cloud Costs Money)

I have a MSDN Subscription which includes quite a bit of free Azure Cloud time. Make sure you've turned this on if you have MSDN yourself. This subscription is under my personal account and I pay if it goes over (I don't get a free pass just because I work for the cloud group) so I want to pay as little as possible if I can.

我有一个MSDN订阅，其中包括很多免费的Azure云时间。 如果您自己有MSDN，请确保已打开此功能。 该订阅在我的个人帐户下，如果付款到期，我将付款(我仅因为云小组工作而无法获得免费通行证)，所以我想尽可能少地付款。

One of the classic and obvious rules of scaling a system is "do less, and you can do more of it." When you apply this idea to the money you're paying to host your system in the cloud, you want to do as little as possible to stretch your dollar. You pay pennies for CPU time, pennies for bandwidth and pennies for database access - but it adds up. If you're opening database connection a loop, transferring more data than is necessary, you'll pay.

扩展系统的经典且显而易见的规则之一是“少做点事，而您可以做更多。” 当您将这种想法应用到为将系统托管在云中而付出的钱时，您希望尽可能少地花钱。 您为CPU时间支付了几分钱，为带宽支付了几分钱，为数据库访问支付了几分钱-但总和。 如果您要打开数据库连接循环，传输的数据量超出必要，则需要付费。

I recently worked with designer Jin Yang and redesigned this blog, made a new home page, and the Hanselminutes Podcast site. In the process we had the idea for a more personal archives page that makes the eponymous show less about me and visually more about the guests. I'm in the process of going through 360+ shows and getting pictures of the guests for each one.

最近，我与设计师Jin Yang合作，重新设计了该博客，制作了新的主页，以及Hanselminutes Podcast网站。 在此过程中，我们想到了一个更加个人化的存档页面，该页面使同名的内容更少地显示我，而在视觉上更多地显示客人。 我正在浏览360多个节目，并为每个人获取客人的照片。

I launched the site and I think it looks great. However, I noticed immediately that the Data Out was REALLY high compared to the old site. I host the MP3s elsewhere, but the images put out almost 500 megs in just hours after the new site was launched.

我启动了该网站，我认为它看起来很棒。 但是，我立即注意到与旧站点相比，Data Out确实很高。 我在其他地方托管了MP3，但是在新站点启动后短短几个小时内，这些映像就输出了将近500兆。

You can guess from the figure when I launched the new site.

当我启动新网站时，您可以从图中猜出。

I *rarely* have to pay for extra bandwidth, but this wasn't looking good. One of the nice things about Azure is that you can view your bill any day, not just at the end of the month. I could see that I was inching up on the outgoing bandwidth. At this rate, I was going to have to pay extra at the end of the month.

我*很少*必须支付额外的带宽，但这看起来并不好。 Azure的优点之一是您可以每天查看帐单，而不仅仅是在月底。 我可以看到我正在增加传出带宽。 按照这个速度，我本月底将不得不支付额外的费用。

I thought about it, then realized, duh, I'm loading 360+ images every time someone hits the archives page. It's obvious, of course, in retrospect. But remember that I moved my site into the cloud for two reasons.

我考虑了一下，然后意识到，,，每当有人点击存档页面时，我都会加载360幅图像。 当然，回想起来很明显。 但是请记住，出于两个原因，我将网站迁移到了云中。

• Save money
  存钱
• Scale quickly when I need to
  在需要时Swift扩展

I added caching for all the database calls, which was trivia, but thought about the images thing for a while. I could add paging, or I could make a "just in time" infinite scroll. I dislike paging in this instance as I think folks like to CTRL-F on a large page when the dataset isn't overwhelmingly large.

我为所有数据库调用添加了缓存，这很琐碎，但有一阵子考虑了图像问题。 我可以添加分页，也可以进行“及时”无限滚动。 我不喜欢这种情况下的分页，因为我认为人们喜欢在数据集不是很大的时候在大页面上按CTRL-F。

ASIDE: It's on my list to add "topic tagging" and client-side sorting and filtering for the shows on Hanselminutes. I think this will be a nice addition to the back catalog. I'm also looking at better ways to utilize the growing transcript library. Any thoughts on that?

ASIDE ：我要为Hanselminutes上的节目添加“主题标签”以及客户端的排序和过滤功能。 我认为这将是对后部目录的不错补充。 我也在寻找更好的方法来利用不断增长的成绩单库。 有什么想法吗？

The easy solution was to lazy load the images as the user scrolls, thereby only using bandwidth for the images you see. I looked at Mike Tupola's jQuery LazyLoad plugin as well as a number of other similar scripts. There's also Luis Almeida's lightweight Unveil if you want fewer bells and whistles. I ended up using the standard Lazy Load.

一种简单的解决方案是在用户滚动时延迟加载图像，从而仅对看到的图像使用带宽。 我看了Mike Tupola的jQuery LazyLoad插件以及许多其他类似的脚本。 如果您想要更少的钟声，还有Luis Almeida的轻巧Unveil 。 我最终使用了标准的惰性加载。

Implementation was trivial. Add the script:

实施是微不足道的。 添加脚本：

<script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js" type="text/javascript"></script>
<script src="/jquery.lazyload.min.js" type="text/javascript"></script>

Then, give the lazy load plugin a selector. You can say "just images in this div" or "just images with this class" however you like. I chose to do this:

然后，为延迟加载插件提供选择器。 您可以根据自己的喜好说“仅此div中的图像”或“仅此类中的图像”。 我选择这样做：

<script>
     $(function() {
      $("img.lazy").lazyload({effect: "fadeIn"});
  });
</script>

The most important part is that the img element that you generate should include a TINY image for the src. That src= will always be loaded, no matter what, since that's what browsers do. Don't believe any lazy loading solution that says otherwise. I use the 1px gray image from the github repo. Also, if you can, set the final height and width of the image  you're loading to ease layout.

最重要的部分是您生成的img元素应包括src的TINY图像。 不管什么，那个src =都会被加载，因为那是浏览器的作用。 不要相信任何其他说明的延迟加载解决方案。 我使用了来自github repo的1px灰色图像。 另外，如果可以，请设置要加载的图像的最终高度和宽度，以简化布局。

<a href="/363/html5-javascript-chrome-and-the-web-platform-with-paul-irish" class="showCard">
    <img data-original="/images/shows/363.jpg" class="lazy" src="/images/grey.gif" width="212" height="212" alt="HTML5, JavaScript, Chrome and the Web Platform with Paul Irish" />
    <span class="shownumber">363</span>                
    <div class="overlay">HTML5, JavaScript, Chrome and the Web Platform with Paul Irish</div>
</a>

The image you're going to ultimately load is in the data-original attribute. It will be loaded when the area when the image is supposed to be enters the current viewport. You can set the threshold and cause the images to load a littler earlier if you prefer, like perhaps 200 pixels before it's visible.

您最终要加载的图像位于data-original属性中。 当应该图像的区域进入当前视口时，它将被加载。 您可以设置阈值，并根据需要使图像更早加载，例如在可见之前200像素。

$("img.lazy").lazyload({ threshold : 200 });

After I added this change, I let it run for a day and it chilled out my server completely. There isn't that intense burst of 300+ requests for images and bandwidth is way down.

添加此更改后，我让它运行一天，它使服务器完全瘫痪。 并没有300多个图像请求的激增和带宽下降的趋势。

1个VM中的10个网站与共享模式下的10个网站 (10 Websites in 1 VM vs 10 Websites in Shared Mode)

I'm running 10 websites on Azure, currently. One of the things that isn't obvious (unless you read) in the pricing calculator is that when you switch to a Reserved Instances on one of your Azure Websites, all of your other shared sites within that datacenter will jump into that reserved VM. You can actually run up to 100 (!) websites in that VM instance and this ends up saving you money.

目前，我正在Azure上运行10个网站。 定价计算器中不明显(除非您阅读)的一件事是，当您切换到其中一个Azure网站上的预留实例时，该数据中心内的所有其他共享站点都将跳入该预留VM。 实际上，您可以在该VM实例中最多运行100个(！)网站，这最终为您省钱。

Aside: It's nice also that these websites are 'in' that one VM, but I don't need to manage or ever think about that VM. Azure Websites sits on top of the VM and it's automatically updated and managed for me. I deploy to some of these websites with Git, some with Web Deploy, and some I update via FTP. I can also scale the VM dynamically and all the Websites get the benefit.

顺便说一句：这些网站位于一个VM中也很好，但是我不需要管理或考虑该VM。 Azure网站位于VM之上，并且会自动为我更新和管理。 我使用Git部署到其中一些网站，使用Web Deploy部署到其中一些网站，以及通过FTP更新的网站。 我还可以动态扩展虚拟机，所有网站都能从中受益。

Think about it this way, running 1 Small VM on Azure with up to 100 websites (again, I have 10 today)...

想一想，在Azure上运行1个小型VM，最多可容纳100个网站(同样，我今天有10个)...

...is cheaper than running those same 10 websites in Shared Mode.

...比在共享模式下运行相同的10个网站便宜。

This pricing is as of March 30, 2013 for those of you in the future.

此价格自2013年3月30日起适用于您将来的定价。

The point here being, you can squeeze a LOT out of a small VM, and I plan to keep squeezing, caching, and optimizing as much as I can so I can pay as little as possible in the Cloud. If I can get this VM to do less, then I will be able to run more sites on it and save money.

这里的要点是，您可以从小型VM中挤出很多，而我计划尽我所能继续进行榨取，缓存和优化，以便在Cloud中花最少的钱。 如果我可以让该VM减少工作量，那么我将能够在其上运行更多站点并节省资金。

The result of all this is that I'm starting to code differently now that I can see the pennies add up based on a specific changes.

所有这些的结果是，我现在开始看到不同的代码，因为我可以看到便士是基于特定的更改而增加的。

翻译自: https://www.hanselman.com/blog/pinching-pennies-when-scaling-in-the-cloud

分模块构建cloud项目?