Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ASP performance boost 1

Status
Not open for further replies.

bmper

Programmer
May 3, 2005
7
0
0
PT
Hello all

I have a very intense (database driven - mysql) application that is causing me some performance issues when i have more that 350 visitors online. The ASP Request Queue starts to get bigger and the response times get higher and higher. the cpu also goes to 90% or even higher! (the application is on a dual xeon 2.8GHz 1GB ram, and the database in on another server with the exact same specs. the database server never gets over than 20% CPU)

Now, here are some of the possible problems:
- The website is translated for several languages and uses a XML with all the keywords. there are 3 xml's with about 200kb each one.
- The site uses response.write everywhere. Even for a single <body>
- The connections to the database might be a problem also. I'm using rs.open SQL, connection_string (where rs = record set)
- All the pages are including a very big ASP file with a lot of global functions

Could someone point me what do u think that is causing the bottleneck here?

Thanks in advance!
 
Are you saying that the entire site is implemented through a single big ASP file???
 
It looks to me like you've already identified plenty of suspects.
 
No.

There are several files. But there is a very big include file with global functions of the website.
Like: Function getUserName(userId) (...) End Function
Function getCityName(cityId) (...) End Function
etc.

This functions are then called on some of the website pages.

Just a note: When I say that there is 3 XML files, I wanted to say that it's 3 xML files for each translation.

 
Yes Sheco

What I would like to know is where i should start first. And if this are really problems that can cause the website to run slower with a little more load.
 
Well yes I'd say you are on the right track.

It is good that you have the database on a separate machine ... otherwise that would be the top suspect and it looks like perhaps that is not the problem.

The big include file that has to get munged into every page might be an issue. Also in your IIS Admin MMC SnapIn there is a slider on the performance tab of the web site property sheet to adjust the for the number of expected hits per day... i think the choices are under 10k, 10k-100k, and 100k +

Try using the perfmon to take a look at not only the CPU but also disk I/O and memory...

Also make sure you don't have any session variables holding recordsets or other objects, that can be a real performance killer.
 
I have seen some huge performance gains from using the getRows() method. Also, as Sheco mentioned eliminating large session vars is always a good idea.

google "getRows example" and check it out if you arent already utilzing this method.

All hail the INTERWEB!
 

Thank you all for your answers!

RhythmAddict112 I will look for that.
The website only uses three session variables: for user id, password and language. I guess it might not be a problem here!
Besides that the available memory is always higher than 200MG.

I suspect that the problems might be related with disk I/O.
With that large XML's and the large ASP included in every page. Don't you guys think?

I will be monitoring this and starting to solve this large files problems.
 
I suspect that you already have a gut feeling about the solution... you just don't LIKE it and you hope that you are wrong...
 
yeah probably!
I know that there are serious problem with the points i've written. I'm just not quite sure what are the most and the less serious.

This kind of problems are sometimes really hard to solve... :(
 
dont forget to close all your recordsets and also set them to nothing.

-DNG
 
Try these tips..


Also, you could try storing the XML translation/resource files in memory.. i.e. the application variable.. loaded in the global.asa at application_Start

Though I think IIS tends to cache very popular files automatically (if configured to do so - in the IIS admin MMC), so this and the large ASP file should already be more efficient than straight disk reads. (not totally eradicated from the problem though)

If you don't use all of the functions/classes in the large ASP file in every page, then why not split them up into logical portions that fit with the different types of pages on your site... security functions, database functions, etc etc. That way you can reduce the actual processing of each request, by selectively including asp script.

GetRows has already been covered but may be worthwhile.

Stored procedures are a big plus for many reasons, though you probably have bigger fish to fry.

Also, why 3 XML files for EACH translation ? Isn't that a bit greedy ??? ;-) I'm sure there is a reason... maybe you could share it with us ? This may be one of your biggest issues.

And get rid of the unnecessary response.write's for lines of block html ....
Code:
<%
'some ASP stuff here..
%>
<html>
  <head>
    <title>Test</title>
  </head>
  <body>
    etc...
%>
'rather than this:
response.write("<html>")
response.write("<head>")
'etc..
%>
If you have a lot of iterative string concatenations, then use a fast string concatenation object - search on google, you will find loads. for a few thousand iterations the difference can be surprising.

If you come back with more info on the XML file usage it may make it clearer... do they contain field / button name translations only, or does it also contain content text - i.e., big paragraphs ? you may even benefit from using your database for retrieving the translated language.. though this would depend on a lot of things.. including the quality of the database server and database application as well as the network connection between it and the web server. 1 connection to the db per page could retrieve only the relevant translations for the page, then the lookup of data would reside on the database.. which is better at this than most other methods of storage retrieval, especially XML parsers.

A few thoughts there, hope some of them are of use to you.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
damber, first of all thanks for your tips! Let me coment them

Actually putting the XML in the application variable seems to me a pretty good idea! I would access then to the variable and the file access wouldn't be needed. I'll make a few tests on that!

I'm already splitting the large ASP page with functions! To tell you the truth, most of the pages doesn't even need that page included.

Stored procedures can't be done right now as we are still using 4.1.x version of mysql. :|

Sure, I will explain why I'm using 3 XML. But first how the XML is built:
<translation name="LANG_NAME">Name</translation>
We have a function that accepts the name of the translation tag and returns the innertext (by xpath)

Now, at the beggining i had a single XML file. But it was a 700kb file! With a lot of users on the website, the pages that had tags at the end of the file would take a long time to load. So I've divided it into 3 files and the pages start to load a little faster.
Now each file has about 200kb.

Putting the XML in a database seems also a good idea, but I guess i will try the application variable first.
Thanks a lot! :)
 
I know you said that you looked at the DB server's CPU utilization and it is consitantly around 20%.

Don't know much about MySQL, but adding indexes to PK's and FK's in SQL Server speeds up queries immensly. Also, it doesn't always translate to DB CPU spikes as just performing a query on a bunch of non-indexed fields will just be slow.

Does mySQL allow non-clustered indexes on Foreign Keys?

If so, add some.
 

20% or even less. The average is between 4%/5%

Yes I have indexes on every primary keys and on 98% of the fields that are used for the foreign keys (btw Mysql 4.x does not have yet relations between tables).

There aren't also non-clustered indexes on Mysql.

The connection roof for the website is 390 users (connections). Over that the ASP requests queue starts to grow!

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top