Fixed it for me. Thank you

> Oxide is way more flexiable than this

This is not true. In-fact the opposite is true.

An Oxide bundle is up to 10MB.

A uMod bundle would be 25MB.

If we change a single thing, say (for example) we tweak something that changes 2KB of one file, then we have to update the bundle and everyone has to download 10MB in Oxide and 25MB in uMod.

Taking your example: with 50-100 servers with Oxide bundle..
50 servers: 500MB
100 servers: 1GB

And with the hypothetical uMod bundle...
50 servers: 1.25GB
100 servers: 2.5GB

Then, consider that 50 to 100 servers is a very conservative estimate and we expect to support thousands of servers.
5000 servers: 125GB

Keep in mind, that's per update, assuming we have 10 updates in a week (which is about our current average)...
5000 servers x 10: 1.25TB

1.25TB per week is nearly 5TB per month (assuming every month is 4 weeks).

Now, let's assume our deployment scenario isn't perfect and even a 2KB change results in a 2MB download for the one component that changed.

50 servers: 100MB
100 servers: 200MB
5000 servers: 10GB
5000 servers monthly (10 updates per week): 300GB.

Given this example, bundling uMod would represent 4.7TB (94%) of wasted bandwidth per month. It's also important to remember that these wasted terabytes would not only be costly to us, but also to the GSPs and servers who have to download them.

There is not a lot of agreement on what the average cost of a GB of bandwidth, so we will look at several estimates.

"Netflix, for example, has claimed the cost is about 1¢ per GB. Other analysts told the Financial Post the rough average is closer to 10¢ per GB. Incumbents contend it’s much more than that. The truth likely lies somewhere in the middle."
https://financialpost.com/technology/how-much-does-bandwidth-actually-cost

According to Netflix: 0.01¢ x 4700 GB = 47$ of wasted cost per month
According to other analysts: 0.10¢ x 4700GB = 470$ of wasted cost per month
According to incumbents: 0.15¢ x 4700GB = 750$ of wasted cost per month
According to incumbents: 0.25¢ x 4700GB = 1175$ of wasted cost per month

Keep in mind, the average cost of bandwidth varies per country, per ISP, and we're not counting overage fees, nor are we considering the time cost to actually download the thing. That Netflix estimate is clearly not representative of the market as a whole, and only represents what it costs them. Given that they have considerable leverage with ISPs and massive resources, they can push the cost down where others cannot.

If you told me I have to spend between 470$-1175$ per month on absolutely nothing, I would not be too happy about that.

Calytic

> Oxide is way more flexiable than this

This is not true. In-fact the opposite is true.

An Oxide bundle is up to 10MB.

A uMod bundle would be 25MB.

If we change a single thing, say (for example) we tweak something that changes 2KB of one file, then we have to update the bundle and everyone has to download 10MB in Oxide and 25MB in uMod.

Taking your example: with 50-100 servers with Oxide bundle..
50 servers: 500MB
100 servers: 1GB

And with the hypothetical uMod bundle...
50 servers: 1.25GB
100 servers: 2.5GB

Then, consider that 50 to 100 servers is a very conservative estimate and we expect to support thousands of servers.
5000 servers: 125GB

Keep in mind, that's per update, assuming we have 10 updates in a week (which is about our current average)...
5000 servers x 10: 1.25TB

1.25TB per week is nearly 5TB per month (assuming every month is 4 weeks).

Now, let's assume our deployment scenario isn't perfect and even a 2KB change results in a 2MB download for the one component that changed.

50 servers: 100MB
100 servers: 200MB
5000 servers: 10GB
5000 servers monthly (10 updates per week): 300GB.

Given this example, bundling uMod would represent 4.7TB (94%) of wasted bandwidth per month. It's also important to remember that these wasted terabytes would not only be costly to us, but also to the GSPs and servers who have to download them.

There is not a lot of agreement on what the average cost of a GB of bandwidth, so we will look at several estimates.

According to Netflix: 0.01¢ x 4700 GB = 47$ of wasted cost per month
According to other analysts: 0.10¢ x 4700GB = 470$ of wasted cost per month
According to incumbents: 0.15¢ x 4700GB = 750$ of wasted cost per month
According to incumbents: 0.25¢ x 4700GB = 1175$ of wasted cost per month

Keep in mind, the average cost of bandwidth varies per country, per ISP, and we're not counting overage fees, nor are we considering the time cost to actually download the thing. That Netflix estimate is clearly not representative of the market as a whole, and only represents what it costs them. Given that they have considerable leverage with ISPs and massive resources, they can push the cost down where others cannot.

If you told me I have to spend between 470$-1175$ per month on absolutely nothing, I would not be too happy about that.

Yes, I can see what you mean here perfectly, and knowing this I wouldn't change a thing now, although as a GSP this was not the case with us. We have the latest version on our servers so anyone who installed Oxide, would not be downloading the file, however, with uMod they will download it each time they run the script and that's per user. So if 50 of my clients wanted Oxide installed, nothing has been downloaded, however, with uMod each client would be downloading the files.

Regardless of this, I've started developing a watcher system, that will detect changes on a clean install and add them to a patch, so if a user updates, they are just installing our latest patch. Not sure if this will work yet, but in theory seems fine.

Thanks for your reply though, it was an eye-opener.

Edit: Just a quick update, checking with a couple of other GSP, they do it same way I do, they wouldn't download the file each time, they store latest version on a file server on the same network, or on the machine its self. They would not download each time. So when you think about it for GSPs this is a waste of bandwidth.

Typical application deployment is on a per-application or per-server basis. The Agent really brings our ecosystem in line with modern standards for application deployment which allows for versioning, validation, and a number of other goodies. Bundles are usually not how applications are deployed, and I can't think of any example of any application that's deployed solely as a ZIP file.

In most cases, with the exception of the one edge-case you mentioned, this will result in bandwidth savings for us and our users. I can't ignore that.

However, that said, you do bring up a good point.

The umod.lock file is necessary to track the current server installation on a per-server basis, but, like NuGet, we could download all packages to a central location and deploy them from that location, allowing them to be cached and downloaded only once per update and deployed to multiple servers on the same machine. Doing this will preserve the value of the umod.lock file, as well as provide both the aforementioned bandwidth savings and additional bandwidth savings in your scenario. I will take this as feature request and consider it a high priority.

I can probably have those done within a week or two (at most). And given that's the direction we'll go with it, I wouldn't recommend setting up an alternative system to create a central location for distributions if you can avoid it.

Merged post

I added a global cache of all package updates/installs for multi-server deployments, no more need for implementing a custom centralized system.

Calytic

Typical application deployment is on a per-application or per-server basis. The Agent really brings our ecosystem in line with modern standards for application deployment which allows for versioning, validation, and a number of other goodies. Bundles are usually not how applications are deployed, and I can't think of any example of any application that's deployed solely as a ZIP file.

In most cases, with the exception of the one edge-case you mentioned, this will result in bandwidth savings for us and our users. I can't ignore that.

However, that said, you do bring up a good point.

The umod.lock file is necessary to track the current server installation on a per-server basis, but, like NuGet, we could download all packages to a central location and deploy them from that location, allowing them to be cached and downloaded only once per update and deployed to multiple servers on the same machine. Doing this will preserve the value of the umod.lock file, as well as provide both the aforementioned bandwidth savings and additional bandwidth savings in your scenario. I will take this as feature request and consider it a high priority.

I can probably have those done within a week or two (at most). And given that's the direction we'll go with it, I wouldn't recommend setting up an alternative system to create a central location for distributions if you can avoid it.

Merged post

I added a global cache of all package updates/installs for multi-server deployments, no more need for implementing a custom centralized system.

This is amazing, thank you for the update.