Search engine friendly URLs slowing up site

[moondaddy]

I've made the decision to use search engine friendly URLs in my site which
means translating stripping all parameters our of the URL and converting it
to a hierarchical URL like this:
Change:
/mysite/default.aspx?MenuID=contactus
To:
/mysite/ContactUs.aspx?

The problem I'm having is that its really slowed things up by at least 0.5
seconds to 1 second longer just to pull up a light weight static page. The
then when navigating using the browser's back button, when I used the normal
(parameter urls) it navigates back instantly, but not its got that long
delay to translate the url. In short here's my code:

'Get the incoming hierarchical URL here.
Dim oldpath As String = context.Request.Path.ToLower()

'more code here to....
'Parse the page name out of the url and pass it to the default page as a
parameter.
'The default page will then run logic against this, query the db and
populate a user control in the content section of the default page with
dynamic content from the db.

context.RewritePath("default.aspx?MenuID=" & sPage)

This is the slow way to do it.

The fast way was just to pass url like this:
default.aspx?MenuID=123

Evidently the holdup is in the context.RewritePath.

This line of code is many times slower than executing 100s of lines of
normal code including hitting the db several times. Is there a way to speed
this up. Also, what considerations do I need to take into account when I'm
caching pages on the client, and/or caching pages on the server?

Thanks.

 

[George Ter-Saakov]

Are you sure that it's context.RewritePath that runs slowly.
And not the (excerpt from you post)
"'Parse the page name out of the url and pass it to the default page as a
parameter.
The default page will then run logic against this, query the db and
populate a user control in the content section of the default page with
dynamic content from the db."


George.

 

[moondaddy]

I haven't done any benchmarking to test each line but this is what I do
know:
1) I've been running the site for about a month using the method of passing
parameters into the url (from the client browser) and that ran fast.
2) The only difference between that (old) way and the way I'm doing it now
is the "context.RewritePath " part. I use the context.RewritePath to
capture a fake page name being passed into the url (instead of a paramter),
change the url back to the original url (of a month ago) where I pass the
parameter into the url (/default.aspx?MenuID=123). then all the same
original code executes to populate the products grid or call up static pages
like "AboutUs.aspx". In other words, the difference between the 2 ways is
the context.RewritePath because after doing this, the same original code
executes as before. I also have a copy of the old site running in a test
domain where I can run them side by side and the new way is much slower.

--
(e-mail address removed)

Are you sure that it's context.RewritePath that runs slowly.
And not the (excerpt from you post)
"'Parse the page name out of the url and pass it to the default page as a
parameter.
The default page will then run logic against this, query the db and
populate a user control in the content section of the default page with
dynamic content from the db."


George.

 

[Steven Cheng[MSFT]]

Hi Moondaddy,

As for the performance(speed) concerns when using context.RewritePath to
provide Url Rewrite, here are some of my suggestions:

When we use the context.RewritePath to perform Url Rewrite , it is only
used for those Search Engine friendly or human readable/hackable urls ,and
the rewrite occurrs in our Custom HttpModule. At runtime when the original
request come and go into the custom module, it'll check the raw url and
replace it with the actual dynamic url (with requerystring params rather
than a static url). All these steps will cost some additional time and its
unvoidable since we want to make those readable/hackable url to the actual
url. However, in most scenario, we can still use the actual dyniamic url in
our code or page's links such as http://severname/appname/page.aspx?a=a&b=b

Also, I still think the process that we parse the orignial comming request
url and replace it with the acutal url is a very important step. And as
mentioned in my tech articles on UrlRewriting, they'll have a certain
rewrite engine for checking the raw url and replace with actual url, such
as using regex, and xml configure file so as to improve the performance. So
I think this is the key point of the whole ReWriting engine we need to take
care of. Do you think so.

In addition, as for the client or server side caching ,I think this is a
common approach no matter you're using Rewriting or not. And I think you
can first try performance test without using UrlRewrite and then consider
the step where you
"Parse the page name out of the url and pass it to the default page as a
parameter"
Improving this step will mostly imporve the whole rewrite mechanism. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

 

[Steven Cheng[MSFT]]

Hi Moondaddy,

Have you had a chance to check out the suggestions in my last reply or have
you got any further ideas on this issue? If you have anything unclear or if
there're anything else we can help, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx