Today, Mark Pilgrim described how to create atom IDs. I wish I'd seen this back in November. I remember looking at the tag: URI scheme and deciding urn: was easier. I guess I missed the part about registering a scheme. Right now, I use a format urn:www-eighty-twenty-net:post id for a permalink, where post-id is a counter. Yep, a small integer, though the integer itself isn't the ID, the urn: is. Except that I didn't register my urn: scheme, so I need to change my ways. Using Mark's first alternate method, my IDs would become something like tag:www.eighty-twenty.net,2004-05-24:1216, for my Notes from DALUG meeting entry.
One characteristic of my permalink is that it contains only the atom ID for the entry, and the id alone is enough to select a specific entry. Using the previous example, http://www.eighty-twenty.net/blog/urn:www-eighty-twenty-net:1216.html is the permalink, where everything following blog/ is the entry ID. I've considered munging the title into the permalink for a friendlier permalink, but then I have to be more careful about picking titles. Or do like Mark does, and add the date to the permalink, so then I only have to worry about making a title unique for a single day. The nice thing about that is that I could lose the hokey counter code in atom-create-entry, which I've always hated.
One thing that can really bite you when writing high-volume web applications for ASP.NET is the thread pool and specifically how your application handles long running requests. The problem is that you have a fixed limit on the number of requests you can handle (the worker thread limit in the thread pool), and running out of threads results in queueing and possibly 503 errors. In my experience, once you get to the point where IIS is issuing 503 - Service Unavailable, ASP.NET is so swamped that simply issuing a 503 can take tens of seconds. The presence of long running requests can escalate the problem, it's a simple traffic analysis problem: you can handle more requests if they execute more quickly, and if you have long running requests, you can handle fewer requests, even if they execute quickly. You can handle long-running requests on a non-thread pool thread, which won't place a drain on the thread pool and can improve performance. There's a couple of good articles on handling ASP.NET requests asynchronously;
Fritz Onion's Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code and Brian Noyes' Handle Requests Asynchronously. Fritz goes into great detail describing the thread pool limitations and the effect of slow pages on overall response time. One problem with these articles is that they take a coarse grained approach to dispatching; you know in advance which pages are slow and which are fast. However, in the case of a web service, certain methods may be slower than others, and certain parameters to methods may cause that method to run slower. The problem with this is that the HTTP handler would need a way to determine the dispatching policy by looking at the payload, because by the time you get into the web method, or even a SOAP handler, it's too late to change your mind.
Comments
You should take a look at Tim Bray's reply:
http://www.tbray.org/ongoing/When/200x/2004/05/28/LinksAndGuids
Lawrence Oluyede at
comments are now closed on this post