Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Pack200 problem?


yes.  the same JAR processor used to recursively pack JARs is used to recursively unpack them.  Update Manager should just take care of this.

Jeff



"Xiaoying Gu" <xgu@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

12/09/2006 09:30 AM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
[cross-project-issues-dev] Pack200 problem?





I'm using pack200 to optimizerize the update site with following ant script:
<java jar="d:/eclipse/startup.jar"
     fork="true"
  timeout="10800000"
  jvm="${java15-home}/bin/java"
  failonerror="true"
  maxmemory="512m"
  dir="d:/">
  <arg line="-application org.eclipse.update.core.siteOptimizer"/>
  <arg line="-jarProcessor -outputDir d:/test -processAll -pack -repack d:/updates"/>
 </java>

After execute the script, I found those plugins (.jar file) which need to be unpacked after updating are changed also. Those jar file included in the update jar (.jar file) were changed to .pack.gz.  
Is this normal? I thought these jar file should remain the same as original jar file. This cause the problem on our update site using these jars.
Does it need more steps on these plugins which need to be unpacked after updating.



Thanks,
Xiaoying Gu


________________________________

From: cross-project-issues-dev-bounces@xxxxxxxxxxx 代表 Denis Roy
Sent: 12/8/2006 (星期五) 7:26 上午
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Degraded respons times from eclipse.org


Performance issues?  We're listening.

Here's what we're doing to look into the problems:

- Wiki: We found two issues, one of which has been solved. The other: wiki is *not* in the QoS [1], so its performance will vary as our bandwidth saturation varies. There's a technological limitation blocking us from putting the Wiki in QoS, but we'll work on it if performance problems persist. https://bugs.eclipse.org/bugs/show_bug.cgi?id=166401

- download.eclipse.org: if you download from our servers during busy times, it'll be slow. This is by design, as most other services (except wiki!) get top-priority access to bandwidth. Under heavy saturation, it is not uncommon to only get 70KB/sec from an http download from download.eclipse.org.

- Bugzilla: I've been repeating this for decades.  Bugzilla has database table locking issues in its design. This is discussed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=153818  We're working on solutions, but it's not easy.

- SSH/CVS: Although these services are in QoS, they are slow when we're heavily saturated, likely because they must perform DNS lookups before allowing the connection, which will introduce lag. Once connected, everything flies due to the service being in QoS. Because we use our ISP's servers for DNS, we're investigating installing a caching DNS server within our network to avoid DNS lookups contending with bandwidth saturation.

- Overall, we're negociating an additional 10 Mbps of bandwidth.  This would increase our committed rate to 70 Mbps.  If this doesn't last us for a while, then someone somewhere is wasting.

- More CPUs: although it's not (yet) a bottleneck, our CPU usage has slowly been increasing. Our systems were designed with scalability in mind, so we have purchased another front-end processing server for the cluster. This fifth node will decrease our CPU load considerably. You can see the details here: http://eclipsewebmaster.blogspot.com/2006/12/node5-has-arrived.html

- Overall, I'm encouraging committers to clean up their disk space usage. More files take up more space and cause longer replication and tape backup times, stressing the disk systems during peak hours.

[1] http://en.wikipedia.org/wiki/QoS

Denis


John Arthorne wrote:


                I've been doing a lot of wiki editing this morning so I can throw in another data point (from Ottawa). I found the performance to be highly variable.  At first it was taking 5-10 seconds to load a page, and 30+ seconds to commit a modification. After awhile (perhaps coincidentally) it became positively snappy.  Towards the end I was getting 1-2 seconds to load a page, and 2-5 seconds for a commit, depending on page size.  I don't know if this is because of caching, or because external factors were affecting QoS.  Denis, if you have created a bug, can you post the link here?  We could all provide further data in the bug to help narrow down the problem.
               
               
               
               
               
Jeff McAffer/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

01/12/2006 10:35 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>


To
henrik.lindberg@xxxxxxxxxxxxxx, Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>                  
cc

               
Subject
RE: [cross-project-issues-dev] Degraded respons times from ecipse.org                


               
               




               
                Here is my 2c for addressing wiki performance if possible.  Editiing is a bit scary and reading is slow enough that I now hesitate to put frequently used info there because it takes too long to access.  This sort of defeats the purpose of having a wiki.
               
                Jeff
               
               
               
"Henrik Lindberg" <henrik.lindberg@xxxxxxxxxxxxxx> <mailto:henrik.lindberg@xxxxxxxxxxxxxx>  
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

12/01/2006 07:21 AM

Please respond to
henrik.lindberg@xxxxxxxxxxxxxx; Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>

To
<cross-project-issues-dev@xxxxxxxxxxx> <mailto:cross-project-issues-dev@xxxxxxxxxxx>                  
cc

               
Subject
RE: [cross-project-issues-dev] Degraded respons times from ecipse.org                



               
               


               
               
               
                Hi,
                I don’t have a problem with login taking long time per se (it is just once in a while you have to wait), but wiki is intermittently very slow �C esp. when saving edits. I can’t say I have found a pattern in its behavior (hour of day, day of week etc.) except that it has gotten worse. The speed is so bad, and it is quite scary when saves take long time (you start to distrust the system, and feel you need to make a copy before saving if it crashes etc.). For me it has gone as far as I am editing at another wiki first. Naturally a lot of time is wasted. It would be very good if something could be done about the wiki performance.
                 
                Also have problem with Bugzilla being incredibly slow.
                 
                - henrik
                 
                >Mike Milinkovich wrote:
                >>That being said, the Wiki has, for some unknown reason, started to lag by about 30 seconds when you access it for the first
                >>time... There's a caching issue that I don't yet understand, but I'll open a bug for it as it's annoying.
               
               
               
               
               
                >Can Thomas and Doug comment on this? Are *your* wiki usage problems just on
                >first access or all the time?
               
                _______________________________________________
                cross-project-issues-dev mailing list
                cross-project-issues-dev@xxxxxxxxxxx
                https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>  
                _______________________________________________
                cross-project-issues-dev mailing list
                cross-project-issues-dev@xxxxxxxxxxx
                https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
                _______________________________________________
                cross-project-issues-dev mailing list
                cross-project-issues-dev@xxxxxxxxxxx
                https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
               
               
               
________________________________


                _______________________________________________
                cross-project-issues-dev mailing list
                cross-project-issues-dev@xxxxxxxxxxx
                https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
                 


--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc.  --  http://www.eclipse.org/
Office: 613.224.9461 x224
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Attachment: winmail.dat
Description: Binary data


Back to the top