Friday, July 11, 2008

Should I Use the sp_ Prefix for Procedure Names?

A little gem: SQL Server gives name-resolution preference to the master database for procedures that have the sp_ prefix. SQL Server looks for a compiled plan for the procedure associated with the master database and doesn't find it because, in this case, the sp_Select1 procedure exists in tempdb. SQL Server assumes the procedure isn't in cache (and thus must be recompiled) and acquires an exclusive compile lock on the stored procedure for a short time. However, the short time that the lock exists is enough to cause performance problems...

Should I Use the sp_ Prefix for Procedure Names?

Using a prefix like usp_ should circumvent this quite nicely. Apart from that, having a naming convention (or nomenclature) in place is a great big ol' must have!

Labels: ,


Tuesday, July 08, 2008

Antratek is selling .NET Micro Framework products

It's good to see that Antratek, a Dutch company, is now also selling a hardware platform with support for the .NET Micro Framework, the Embedded Master modules. The web site is in Dutch, translation is here. They're the first  in the Benelux!

One of the nice key features (pdf) of the platform is a FAT file system using USB memory devices such as hard drives, as well as SD/MMC cards. Near unlimited data recording and storage, anyone?

It comes complete with Ethernet with full TCP/IP stack, 2 USB ports and the obligatory features like analog in/outputs, Serial Interfaces, Pulse Width Modulation (PWM) and so on. Prices start at EUR 199,96 for the Development Platform and EUR 63,96 for the Master Module.

I've bought stuff from Antratek before and it was a pleasure doing business with them.

Personal note: I am not affiliated with Antratek in any way.

Labels: ,


Tuesday, June 24, 2008

Troubleshooting SPSite/SPWeb leaks and the Importance of Loadtesting

Stefan has a good article on troubleshooting leaks in your WSS and MOSS applications. One of the very nice features is that whenever a certain threshold is crossed, an entry will be written in the ULS logs:

"Potentially excessive number of SPRequest objects (<NUMBER>) currently unreleased on thread <NUMBER>"

This is a very convenient way for a Sharepoint Administrator to keep track of sites with an excessive amount of memory consumption through SPRequest objects.

He also talks about issues surrounding the potential number of site objects generated with a site navigation control:

"That means if you have a navigation control configured to enumerate 3 levels of sites and on each level you have 20 sites that you will end up with more than 400 SPRequest objects. So you need to be very careful with how to configure your navigation controls and also how many sites to create on each level!"

Now consider that each site object will use approximately 2-4 MB of memory on the server. Combine this with the scenario above and you will end up with a huge amount of allocated IIS memory. I don't know if this is per individual user session or not, but either way, this is not something you will want to have on your environment without some consideration beforehand.

There are roughly two ways to gauge what your application will do:

Theory::Estimation

Based on the site architecture, software architecture, usage forecasts, amount of change permitted on the webpart architecture and so on, you can get an estimate on how your solution will behave. How many objects will there be any given time? What is the variance?
But -sadly- hardly anyone does this, let alone completely.

So, what's the second option?

Practice::Loadtesting

This should come as no surprise. (If it does, shame on you!) Yes you can do unit testing. Yes you can do TDD. Yes you can test against coding guidelines. And yes you all will do functional testing. That's all good.

But only, and only if you test your whole A-Z architecture against real life usage and benchmark it, stress it, stress it hard, you will be able to get information how everything will hold up. How is that pesky CrossList webpart doing? And what about that navigation control? If it looks like it is generating a whole lot of memory pressure, you might want to consider other options and go back to the drawing board.

Loadtesting also includes talking to the client to get the testing requirements. What will be their expected usage patterns? Okay, you want the application to react fast? What do you mean by fast? Can you put that in numbers? Let's talk about your Application SLA. What can you tell me about it? How can we translate this into something meaningful for the project?

I can not stress this enough: if you do not incorporate loadtesting as a core requirement in the process, you will be introducing One. Huge. Unmanaged. Risk. Factor. Period.

I have seen too many deployments go down in flames because of this. You might have created a stunning application which leaves the customer absolutely breathless with tears in their eyes, but if he finds out that it will only scale to 6 concurrent users with no more that 5 pages per second before another Web Frontend (WFE) is needed, which, by the way, is definitely NOT the solution to your problem, you will have a serious problem. And this will not be easy to solve if you have come this far in the project.

This is what Microsoft has to say about it: "Load testing should be part and parcel of every Web development effort, and it should be performed early in the process. However, if you think you can load test using your development environment, you're going to have some surprises when you go live..."

So, to sum it all up: "if you do not loadtest, you fail".

Links

Stefan Goßner : Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007
MSDN: Real-World Load Testing Tips to Avoid Bottlenecks When Your Web App Goes Live
Modeling the Real World for Load Testing Web Sites

Labels: , ,


Thursday, April 03, 2008

Access Fileserver Data via SharePoint

René Hézser has created a nice webpart to access fileservers from Sharepoint: "I guess everybody knows this scenario. You are with a customer or at home, and need a file from your company's fileserver very badly. What can you do? VPN is not possible, and you can't phone a colleague who can then send you the file via email because nobody is in the office. <SNIP> With [this] Webpart you can access files from e.g. your fileserver via SharePoint / Browser."

Haven't tried it out yet, but this looks very nice. I'm just wondering if you might need Service Principal Names (SPN) with AD delegation implemented if you're using Kerberos authentication.

Labels: ,


Wednesday, March 26, 2008

It's Always Your Fault

Jeff Atwood has a great article, called: The First Rule of Programming: It's Always Your Fault.

An excerpt: "You know the feeling. It's happened to all of us at some point: you've pored over the code a dozen times and still can't find a problem with it. But there's some bug or error you can't seem to get rid of. There just has to be something wrong with the machine you're coding on, with the operating system you're running under, with the tools and libraries you're using. There just has to be!"

It is far more likely that something you built is causing the error than, say, the OS, hardware or Network: "of total errors reported, roughly 95% are caused by programmers"

I can't count the number of times I had to deal with resistance to take ownership or cooperate. No, it wasn't the codebase, there has to be something wrong with the system or the network. Even when faced with cold, hard data to prove otherwise. Or, the other way around: no, our network and systems are sized just fine, the application is causing all the issues! They are at fault, not us.

The way I usually deal with these kind of issues is to get everybody together in one room and break down the boundary. This is an issue we have to solve together. After all, what are we really talking about here? This is not about who's at fault here, this is not about personal abilities. This is about a technical issue. Heck, it might even be because of some weird interaction between the network configuration and the code for all we know. Who knows? Hmm... couldn't that be the case?

Once the defenses are down, people are focusing on the issue and willing to work together to solve it, we can really get down to business. And call for pizza of course!

Labels: , , ,


This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]