Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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"
   <arg line="-application org.eclipse.update.core.siteOptimizer"/>
   <arg line="-jarProcessor -outputDir d:/test -processAll -pack -repack d:/updates"/>
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.
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

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.

- 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

- Bugzilla: I've been repeating this for decades.  Bugzilla has database table locking issues in its design. This is discussed here  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:

- 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.



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> 

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

RE: [cross-project-issues-dev] Degraded respons times from	


	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. 
"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> 

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

RE: [cross-project-issues-dev] Degraded respons times from	


	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 <>  
	cross-project-issues-dev mailing list
	cross-project-issues-dev mailing list

	cross-project-issues-dev mailing list

Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc.  --
Office: 613.224.9461 x224
Cell: 819.210.6481


Back to the top