[jbosstools-issues] [JBoss JIRA] (JBDS-2730) Faster download of updatesite content via akamai
Nick Boldt (JIRA)
issues at jboss.org
Wed Oct 8 16:35:12 EDT 2014
[ https://issues.jboss.org/browse/JBDS-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008661#comment-13008661 ]
Nick Boldt edited comment on JBDS-2730 at 10/8/14 4:34 PM:
-----------------------------------------------------------
Using the above script, results indicate that a 296M update can be done in under 2.5 mins the first time, then ~30 seconds for subsequent tests.
I believe this data is inconclusive since the downloaded artifacts appear to be cached somewhere on disk. Whether I was pulling from the actual server (209.132.182.70) or the staging edge server (23.35.182.29), the results were the same, suggesting that JBDS was simply copying local files rather than re-downloading them each time.
I later re-ran these tests on another machine to get a baseline for how long it takes to do the install when Akamai is not involved. It was basically the same results when I did the test in reverse (first install against 209.x.y.z, 2.5mins; subsequent installs against 23.y.z.x, 30s). So... I think Eclipse is caching content locally in /tmp or somewhere to save subsequent re-downloaded content.
But a 2.5min install is very fast IMHO for nearly 300M of downloaded & unpacked files.
{quote}
Before: Features + plugins folders: 547M, 613M for whole JBDS install folder
After update to CR1b: Features + plugins folders: 827M, 909M for whole JBDS install folder
Growth due to update: 280M - 296M
Test 01
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-target-platform/
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-updatesite-core/
1:55pm to 1:57:30pm = about 2.5mins
Test 02
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-target-platform/
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-updatesite-core/
2:01:38pm to 2:02pm = about 30 seconds
Test 03
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/updates/8.0-development/
2:05:28 to 2:06 = about 35 seconds
Test 04
Disable edge server in /etc/hosts, disable VPN, and pull from public server at 209.132.182.70 using:
https://devstudio.redhat.com/updates/8.0-development/
2:13:50 to 2:14:12 = about 25 seconds
Test 05
Remove ~/.eclipse folder, disable edge server in /etc/hosts, disable VPN, and pull from public server at 209.132.182.70 using:
https://devstudio.redhat.com/updates/8.0-development/
2:15:45 to 2:16:10 = about 25 seconds
{quote}
was (Author: nickboldt):
Using the above script, results indicate that a 296M update can be done in under 2.5 mins the first time, then ~30 seconds for subsequent tests.
I believe this data is inconclusive since the downloaded artifacts appear to be cached somewhere on disk. Whether I was pulling from the actual server (209.132.182.70) or the staging edge server (23.35.182.29), the results were the same, suggesting that JBDS was simply copying local files rather than re-downloading them each time.
I later re-ran these tests on another machine to get a baseline for how long it takes to do the install when Akamai is not involved. It was basically the same results when I did the test in reverse (first install against 209.*, 2.5mins; subsequent installs against 23.*, 30s). So... I think Eclipse is caching content locally in /tmp or somewhere to save subsequent re-downloaded content.
But a 2.5min install is very fast IMHO for nearly 300M of downloaded & unpacked files.
{quote}
Before: Features + plugins folders: 547M, 613M for whole JBDS install folder
After update to CR1b: Features + plugins folders: 827M, 909M for whole JBDS install folder
Growth due to update: 280M - 296M
Test 01
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-target-platform/
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-updatesite-core/
1:55pm to 1:57:30pm = about 2.5mins
Test 02
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-target-platform/
https://devstudio.redhat.com/static/updates/8.0.0/jboss-devstudio-8.0.0.CR1b-updatesite-core/
2:01:38pm to 2:02pm = about 30 seconds
Test 03
Update to CR1b using devstudio.redhat.com.edgekey-staging.net server at 23.35.182.29 from:
https://devstudio.redhat.com/updates/8.0-development/
2:05:28 to 2:06 = about 35 seconds
Test 04
Disable edge server in /etc/hosts, disable VPN, and pull from public server at 209.132.182.70 using:
https://devstudio.redhat.com/updates/8.0-development/
2:13:50 to 2:14:12 = about 25 seconds
Test 05
Remove ~/.eclipse folder, disable edge server in /etc/hosts, disable VPN, and pull from public server at 209.132.182.70 using:
https://devstudio.redhat.com/updates/8.0-development/
2:15:45 to 2:16:10 = about 25 seconds
{quote}
> Faster download of updatesite content via akamai
> ------------------------------------------------
>
> Key: JBDS-2730
> URL: https://issues.jboss.org/browse/JBDS-2730
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Components: requirements, updatesite
> Reporter: Burr Sutter
> Assignee: Nick Boldt
> Priority: Critical
> Labels: JBDS80_Approved_Scope
> Fix For: 8.0.0.GA
>
> Attachments: JBDS2730-test-script-JBDS-install-then-update-from-Akamai.txt
>
>
> The updatesite used by marketplace should be behind akamai for smoother/faster download.
> Investigate using akamai/download.jboss.org backed storage.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
More information about the jbosstools-issues
mailing list