When we are working using Subversion, we can expose the Subversion repository using svnserve (open the default port 3690 and svn:// protocol) or leverage the Apache WebDav to expose your Subversion service in HTTP (the web protocol -- I've always tempted to write it as HTTP Protocol which is incorrect as the last P letter stands for 'protocol').
And of course if you are just as lazy as I, you will use the CollabNet Subversion or Edgewall Trac.
Mercurial Server from Lshift is one way to achieve similar thing. Though it is named Mercurial Server, it is not a server in traditional client/server perspective. It leverages the SSH authentication to make it like a central repository where multiple user can access and serves the same purpose.
Surprisingly, it is very easy to install in an Ubuntu box.
[sourcecode lang="shell"]
$ sudo apt-get install mercurial-server
[/sourcecode]
Gotcha! You have it now.
With this Mercurial Server, you can access the server using:
hg clone ssh://<ssh-user>@<host-name-or-ip-address>[:<ssh-port-num>]/<folder>
[sourcecode lang="shell"]
$ hg clone ssh://mercurial@192.168.0.1/projects
[/sourcecode]
Showing posts with label http. Show all posts
Showing posts with label http. Show all posts
Monday, June 14, 2010
Tuesday, March 27, 2007
Ill Behaviored HTTP/1.1 Client
Today I've been message by my campus friend, asking an advice for tuning a SJAS. How many threads should he have for servlets, how many MDBs, and how many database connection in the pool.
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
He set the number for 1024, 128. Hmm. Very big. I asked him, how much memory and processor resources and app server instances do you have. The answer was shocking:
1 processor, 1 gigabyte, 1 instance
As far as I can remember, on a WebLogic they recommend to use less than that number of threads for best practices on each instances. Wow, and we were talking about WebLogic 8.1 instance in a UltraSPARC-IIIi Solaris 9 boxes with 8 gigs of memory!
I thought there must be something else happening. For just 1 processor, processing many threads is actually a waste of time in the context switching. I think it should not be like that. There something wrong when the system. It is already out of resource and the queue piles up. It must be some kind of resource starvation. Some resource may not be released during the process. Some resources are held for longer than it should be.
Then I remembered that I have had encountered some problems here.
The HTTP/1.1 Protocol has been there for such a long time. But there are some behavior most programmers still don't know.
The HTTP/1.1 differs from HTTP/1.0 that it implements persistent connection by default. The HTTP/1.1 will not be closing its connection after your client application exits. Your browser or client application by default will maintain HTTP connection until time out period elapsed. Before time out period, the connection is still up, and whenever you need to make more requests your browser or your HTTP client application will reuse the HTTP connection when possible, thus eliminating the overhead needed to setup such connections. The browser application makers have been doing their job very well it is transparent for us to such happenings in the protocol.
Remember I said 'by default', because you can explicitly asks the server (by adding a header field) to close the connection once the request has been fulfilled.
This is the thing that you need in your HTTP header.
Connection-Close: close
Subscribe to:
Posts (Atom)