You know the feeling?

Every vinyl junkie dreams of discovering their own little cave full of rare jams that no one’s ever heard before, like DJ Shadow’s vinyl wonderland in ‘Scratch’. Once your mind switches into digging mode there’s no return…all you’re focusing on is finding out what kind of crazy sounds are out there, anything to take home & sample?

The first record shop I got hooked on was a place called ‘Lost&Found’. It would only be open on weekends and there were posters and sleeves all over the walls. You’ll come across some cool cover art every time. I’d spent hours going through the albums and singles, sometimes bizarre spoken word records. One of my favourite vinyls I got from there was the soudtrack to the film ‘Babylon’. Classic stuff. The shop was run by two mid-aged hippies who were always smoking in there, listening to tunes and clowning around. A lot o’ the records were stacked in old shopping trolleys and there was a back room full of rare vinyl that only one customer at a time was allowed to go in…probably their way of making the crate-digging lemmings feel a bit special.

Enough of that. The Every Day is Record Store Day campaign that’s been started in the US is a step in the right direction. It’s trying to motivate people to shop at smaller independent outlets on 17th April every year.

Abstract Rude is one of the artists who supports it. “For me, my family’s record collection was my gateway drug to the record store,” he says.

“Also my older sister’s rap tape collection that made me want to own my own music – she was stingy with loaning me tapes! The local record stores became like my gateways for expanding my knowledge of hip hop culture in various neighborhoods and cities worldwide. I know we got the internet today, but honestly, it sucks even trying to buy music online sometimes.”

As far as Beat Bungalow is concerned, there’s no doubt: all day every day should be record store day. Best thing to do is get your fingers dusty and support your local vinyl dealer!

Putting firewalls between application servers and database servers seems to be becoming more popular.

One negative side effect of this is when the firewall decides to end a connection due to inactivity.  Some networking devices have a timeout period so idle connections are cut off.  This can have unpleasant results for the users of an application.

I first came across this problem while working for a new customer a long time ago.  I was frequently asked to kill database sessions that held row level locks and were blocking other transactions.  After a while, I noticed a pattern.  The locking problems always started after the blocking session had held the lock and been idle for at least 900 seconds.  When this was described to the users, they added that they have to log in again after lunch, or coffee breaks, etc.  I referred this issue to the network administrator, (who sat next to me and so couldn’t ignore me), who soon realised that the cause was a NAT’ing router.  The router cut off the (fat client) application’s session after the user had been idle for 15min.  The timeout was increased and users were asked to log out of the application when finished for the day.  Problem solved.

The SQLNET.LOG on a database server can show a DBA that idle connections are being cut off, eg a recent example I saw on Solaris:

***********************************************************************
Fatal NI connect error 12170.

 VERSION INFORMATION:
 TNS for Solaris: Version 10.2.0.3.0 - Production
 Oracle Bequeath NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
 TCP/IP NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
 Time: 01-JUL-2009 03:31:04
 Tracing not turned on.
 Tns error struct:
 ns main err code: 12535
 TNS-12535: TNS:operation timed out
 ns secondary err code: 12560
 nt main err code: 505
 TNS-00505: Operation timed out
 nt secondary err code: 145
 nt OS err code: 0
 Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=nn.nn.nn.nn)(PORT=57922))

In this example, the Solaris error 145 shows that the disconnection was not due to an Oracle setting or database problem, (as some parties were insisting), but was actually from a connection timeout at the OS level.  (Look up error number 145 in /usr/include/sys/errno.h ).
In this case I needed more evidence to prove my explanation to others, so I recorded the connected database sessions and their idle times, then matched these errors to idle sessions that had disappeared at the same time.  Recording this data for a while showed that only sessions that were idle for a certain amount of time were cut off.  Later, the network support staff were able to confirm the idle connection timeout setting.

Over the years, my attempts to persuade network administrators to increase the timeout period have often met resistance, because the timeout exists to free up resources.  An alternative is to use some sort of keep alive packets.  There are various places keep alives can be enabled, eg at the Windows OS level or in PuTTy.  For Oracle databases, SQLNET.EXPIRE_TIME can be used.  Although SQLNET.EXPIRE_TIME was intended as a dead connection detection (DCD) method, a side effect of sending probe packets between the database server and client/application server is that the connection remains active.  Set the SQLNET.EXPIRE_TIME to less than the firewall timeout and the problem is solved.

Another work around for applications that use connection pools is to keep each connection active by checking running a simple SQL statement at regular intervals.

HTTP (Hyper Text Transfer Protocol) does not maintain a state. For every request that is made to the server, the server sends a response back. When a request is being made, a NEW socket connection is opened on the server from which the response is sent back.

The biggest disadvantage of http is its”slow” response. “Keep-alive” connections phase out this problem for HTTP.

Http keep-alive is also known as “persistent connections”.

In HTTP/1.0 specification, the browser sends the request with the header tag “Connection: Keep-Alive” to which the server responded back with “Connection: Keep-Alive”. For this to happen, it is essential that the browser should support keep-alive. When the next request is sent, the connection is NOT CLOSED and is still alive for further requests until either client or server decides that the connection is over and closes the connection.

In HTTP/1.1 specification, ALL connections to the server are treated to be having “keep-alive” connection unless explicitly stated with “Connection: close” in the headers from the browsers. Some browsers misbehave by hanging the connection. To over come this problem, there is a Keep Alive TimeOut option available in Servers and in Apache it defaults to 15 seconds.

Keep-alive is active with files whose size are known before hand. So dynamic programs stay aside on these cases.

HTTP indicates the end of the previous response and the beggining of the new request thus enabling the reuse of the connection.

Refer:

RFC 2616: http://tools.ietf.org/html/rfc2616#section-8.1

This product from Xepient looks interesting.  And only 5 Euros!  Whatever that is in USD, it feels cheap.

This technet article says that I should

1. Open IIS Manager and navigate to the level you want to manage.
2. In Features View, double-click HTTP Response Headers.
3. On the HTTP Response Headers page, in the Actions pane, click Set Common Headers.
4. In the Set Common HTTP Response Headers dialog box, select the Enable HTTP keep-alive check box and then click OK.

But I don’t see the “HTTP Response Headers” option in my web application configuration (see image below). What am I doing wrong?

KALAMI (n.)
The ancient Eastern art of being able to fold road-maps properly.

I remembered this quote from the Meaning of Liff while thinking about my latest and recent involvement in tuning a web sites that are complex and have high volumes of traffic.

Complex websites have many components interacting horizontally (in sequence) and vertically (on top of each other like a stack). Sequential components such as firewalls, load balancers, web servers, application servers, databases, content management servers and third party applications. Throughput is determined by the weakest link in the chain. So remove one bottleneck and you end up searching in many places for the next bottle neck. A strategy often used is by offloading traffic from one complex component to a more simple component. Caching in front-end servers is a classic example of this strategy.

A website integrates vertically, meaning one components uses another component to function. Examples are the HTTP and TCP/IP protocol, application servers, Java, databases, Operating system and hardware. An improvement in one component can and most likely will influence the performance of the other, often in ways you do not expect it. Change something in HTTP for the better, can have a downside on the TCP/IP level.

As an example one discussion that came up was about honoring Keep-Alive on http requests. My wisdom and experience has learned me that Keep-Alive’s are bad things for servers with a lot of traffic. Some colleagues agreed, others disagreed. Who is right? Most likely it depends… on many factors. So no one can tell. A quick scan over some high volume sites (CCN, Amazon, Yahoo, Google, AOL) shows that opinions on this topic vary. Some use keep-alive’s others instruct the client to close the connection.

In high volume websites there are many components each having many options to tune the performance. You need to look at them individually, but at the same time honor their role in the greater whole. As a result there is no clear cut recipe how to set up a high volume website. What works in situation A might or might not work in situation B. So it all depends on the specific situation and experience of the team.

I have some knowledge on this subject but I am by no means an expert or authority on this subject. A good starting point this the Yahoo website about Exceptional Performance.

What most online resources fail to point out is that no matter how many testing and preparation you do, the proof is in eating the pudding. And while you are watching your site slow down due to increased traffic, you need a good structure and set of rules to let the technical people do their work, make sure they progress in the right direction and keep the customer informed and involved what you are doing.

Für die Leute die schon mal mit dem Gedanken gespielt haben, sich einen eigenen Teamspeak-Server zu leisten hier ein paar Infos zu den technischen Hintergründen. Also was ist Teamspeak, was brauch Teamspeak und was kann es.

Recht oft höre ich “Teamspeak ist wie Skype nur mit mehr Leuten”. Teamspeak kann man nicht mit Skype vergleichen – das sind zwei grundlegend verschiedene Dinge. Einfach gesagt ist Teamspeak eine Art Sprachchat – Voice IRC so gesehen.

Jeder spricht mit jedem, man kann die Gespräche aber in Räume aufteilen. Ein Raum (Channel) z.B. für die Admins, einen für User, einen für Off-Topic-Gespräche. Im Gegensatz zu Skype gibt es keine Zweiergespräche – nur die Möglichkeit sich in ein Separee zurück zu ziehen.

Die kostenlose Version ist auf 1000 anwesende User beschränkt und darf nicht für kommerzielle Zwecke genutzt werden.

Auch die Sprachqualität ist eine Andere. Bei Skype kann ich je nach Einstellung und Bandbreite CD-Qualität erreichen, Teamspeak ist irgendwo zwischen analogem Telefon und ISDN angesiedelt, könnte allerdings aufgebohrt werden.

Die Qualität reicht aber locker aus – schließlich soll ja kein Konzert von Kraftwerk in Dolby Digital übertragen werden.

Nutzer die kein Mikro haben können einen Teamspeak-Channel betreten und einfach nur zuhören.

Die Channels lassen sich auch mit Passwörtern sichern – interessant für interne Bereiche. Genauso wie in einem Forum und im Chat können unterschiedlichen Nutzern unterschiedliche Rechte eingeräumt werden.

Hinsichtlich der CPU-Belastung brauch man sich keine Sorgen zu machen. Im Normalfall läuft Teamspeak auf einem Linuxserver. Folgende Anforderungen werden gestellt:

• ohne ein laufendes X-Window-System:
  • 100 MHz CPU
  • 32 MB Ram
• mit X-Window-Sytem:
  • 166 MHz CPU
  • 64 MB Ram
• 6 MB Ram + Platz für Server-Logfiles, falls aktiviert

Der erzeugte Traffic bzw. die benötigte Bandbreite hängt vom Codec und der Anzahl der User ab.

Die Bandbreite berechnet sich wie folgt:

• Down-Stream: Anzahl der Nutzer die gerade sprechen * Codec-Datenrate
• Up-Stream: Anzahl der Nutzer die gerade sprechen * (Anzahl der Nutzer im Raum – 1) * Codec-Datenrate.

Die Datenrate der einzelnen Räume einfach addieren. Die Codec-Datenrate erkennt man am Namen des Codecs. Speex 9.3 braucht 9,3 kbit/s, GSM 14.8 14,8 kbit/s.

Bei 10 usern, 3 reden gleichzeitig, würden also 3 * 9,3 kbit/s = 27,9 kbit/s bzw. 3,4 kb/s an downstream und 3 * (10-1) * 9,3 kbit/s = 251,1 kbit/s bzw. 30,7 kb/s upstream anfallen.
Da braucht Skype einiges mehr. Wie man sieht, ist das ganze immer abhängig davon, wieviele Labertaschen gerade da sind

Welcher Codec genutzt wird ist geschmackssache und auch wieviel Lei(s)tung man hat. Es wird meist was zwischen Speex 9.3 und Speex 16.3 eingesetzt.

Nutzer die die Klappe halten und nur den geistigen Ergüssen der Anderen lauschen erzeugen auf dem Server kein Downtraffic. Es wird nur das übertragen, was durch das Mikro aufgenommen wird. Nimmt das Mikro nix auf, werden nur einzelne “keep-alive”-Packete gesendet.

Der Status, die Anzahl der Anwesenden im Channel und noch viele mehr Informationen kann man z.b. mittels PHP auf der eigenen Homepage oder dem eigenen Blog anzeigen lassen.