All,
Last week we upgraded the line that RubyForge is on, and in the beginning
had pretty dismal performance. Last Thursday our ISP tweaked the link and
performance *seems to be* really good. I was wondering if folks that have
used RubyForge over the weekend (for Web, downloads, CVS, etc) can give me
their thoughts...direct emails to me would be fine if we want to keep this
traffic off-list.
Thanks!
-rich
Team RubyForge
I found CVS performance acceptable. The website, however, is typically
slow. The problem, I think, is not so much the actual speed of the
server or the line, but that it looks like the pages are highly
complex and not cached (and neither are the images?) in any way. It's
bad when I can see Firefox rendering each element individually.
On Mon, 9 Aug 2004 22:18:42 +0900, Richard Kilmer <rich@infoether.com> wrote:
Last week we upgraded the line that RubyForge is on, and in the beginning
had pretty dismal performance. Last Thursday our ISP tweaked the link and
performance *seems to be* really good. I was wondering if folks that have
used RubyForge over the weekend (for Web, downloads, CVS, etc) can give me
their thoughts...direct emails to me would be fine if we want to keep this
traffic off-list.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
individually.
Now, from my high bandwidth, high latency access (satellite internet), the
web site's performance has been quite acceptable every time I have tried it
over the weekend and so far this week. Seems to be working well.
Kirk Haines
On Tue, 10 Aug 2004 00:05:33 +0900, Austin Ziegler wrote
I found CVS performance acceptable. The website, however, is
typically slow. The problem, I think, is not so much the actual
speed of the server or the line, but that it looks like the pages
are highly complex and not cached (and neither are the images?) in
any way. It's bad when I can see Firefox rendering each element
Hm. There's a bit of caching involved - we run mod_php (vs PHP as a
CGI), and GForge has a i18n cache thingy that serializes all the strings
to a BLOB rather than parsing the i18n file for each request.
Eventually I might set up one of those PHP accelerator cache gizmos
(like Turck MMCache) which keeps the compiled scripts in memory rather
than reloading them for each request. Which would be nice.
Yours,
tom
On Mon, 2004-08-09 at 11:05, Austin Ziegler wrote:
On Mon, 9 Aug 2004 22:18:42 +0900, Richard Kilmer <rich@infoether.com> wrote:
> Last week we upgraded the line that RubyForge is on, and in the beginning
> had pretty dismal performance. Last Thursday our ISP tweaked the link and
> performance *seems to be* really good. I was wondering if folks that have
> used RubyForge over the weekend (for Web, downloads, CVS, etc) can give me
> their thoughts...direct emails to me would be fine if we want to keep this
> traffic off-list.I found CVS performance acceptable. The website, however, is typically
slow. The problem, I think, is not so much the actual speed of the
server or the line, but that it looks like the pages are highly
complex and not cached (and neither are the images?) in any way.
Austin Ziegler wrote:
I found CVS performance acceptable. The website, however, is typically
slow. The problem, I think, is not so much the actual speed of the
server or the line, but that it looks like the pages are highly
complex and not cached (and neither are the images?) in any way. It's
bad when I can see Firefox rendering each element individually.
From peeking at the HTTP headers, the images are normal I think (E-Tag and Last-Modified are present) so they should be cache-able as any other static files.
And I guess the major bandwidth sucker would be file downloads, anyway.
--
dave
Austin Ziegler wrote:
> I found CVS performance acceptable. The website, however, is typically
> slow. The problem, I think, is not so much the actual speed of the
> server or the line, but that it looks like the pages are highly
> complex and not cached (and neither are the images?) in any way. It's
> bad when I can see Firefox rendering each element individually.From peeking at the HTTP headers, the images are normal I think (E-Tag
and Last-Modified are present) so they should be cache-able as any other
static files.
Yup, the only dynamic images are the project stat PNG charts.
And I guess the major bandwidth sucker would be file downloads, anyway.
Right on. 50 GB last month, whew!
Yours,
tom
On Tue, 2004-08-10 at 14:53, David Garamond wrote: