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