[
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