1

I have this online store built with the following language/technologies C#,MVC3,StructureMap for DI,SignalR for real-time notifications, and FBConnect for member login.

I am running this site on a dedicated server with Core2 Quad CPU @ 2.40GHz and 8GB of RAM but the CPU usage still reaches 60-80% when many users are accessing the site. The site is loading photos from the database but I don't think this is the problem because I've already implemented caching of these photos which you could see on my older post @ MVC3 + Streaming images from the Database is causing very high CPU usage on my server . I've even modified my pages to initially load 20 photos, and to only load more photos when the user scrolls to the bottom of the page.

I've discussed this to a friend who's also a .net developer and he said that I should probably research with the Session-State modes coz it might help. I haven't changed anything with regards to Session-State on my site so it's still using the default InProc.

My Question is: What's the best Session-State mode to use that could handle large traffic? And will it improve my site's performance?

Just to give you a picture of how the site get's a lot of users, here's how it works: 1.Photos of items for sale are posted by the seller in albums (max photos/album is 200 and they are loaded by 20's). 2.First customer to comment/reserve the item will be the winning buyer. 3.Seller then confirms the comments/reservations to the first buyer.

The site has more than 1000 users and at least 80% of this users are accessing the site at the same time.

Is it okay that I'm using the default InProc? Or should I Use StateServer or SQLServer mode?

Thanks

Community
  • 1
  • 1
dmc
  • 807
  • 2
  • 10
  • 25
  • `` is my favorite mode and the one I use in each of my applications. Since I have switched to this mode I no longer have any problems and design my applications in a RESTful manner. – Darin Dimitrov Jun 19 '12 at 15:10
  • @DarinDimitrov what happens if i turn it Off? – dmc Jun 19 '12 at 16:05
  • Session is no longer used at all :-) Obviously for this to work you will have to modify your application and remove all `Session` access from the code. – Darin Dimitrov Jun 19 '12 at 16:13
  • Would that affect the CustomIdentity/Principal I'm using when users login? – dmc Jun 19 '12 at 16:16
  • I don't know what you are using. If you are using Session, then, yes it will affect. If you are using the built-in Forms Authentication there is no session at all. A Forms Authentication cookie is used to track users. – Darin Dimitrov Jun 19 '12 at 16:22
  • Yes I am using the built-in Forms Authentication. But do you think this would solve the CPU usage issue? – dmc Jun 19 '12 at 16:25

3 Answers3

2

I don't think this is the problem because[...]

You are guessing. As long as you are guessing you will fail to handle the performance issue (assuming it is an issue: see below).

You need to measure. Use something like mini-profiler to determine exactly what is taking the time.

But:

the CPU usage still reaches 60-80%

Does the site slow down? Are requests queuing up? Do the users perceive the site as slow?

That level of CPU usage might be quite normal for the rate of requests you are getting.

Richard
  • 106,783
  • 21
  • 203
  • 265
  • images are cached for 7days and each image is at least 30-50kb. Every week there are at least 3 new albums created with 200 photos as the maximum in each album...So every week there are at least 600 photos of 30-50kb each in cache, do you think this could possibly be the one causing the problem? – dmc Jun 19 '12 at 16:08
  • @DuncanMcIntyre: Have you measured? What do the measures tell you? You can apply engineering approaches and get it right, or guess and waste a lot of effort on the wrong things. – Richard Jun 19 '12 at 16:44
  • @DuncanMcIntyre: 600 times 50kB is less than 30MB. If that is significant on the hardware you describe then you have bigger problems. – Richard Jun 19 '12 at 16:44
  • Yeah you're right, I should measure and not guess. Maybe the caching of photos that are steamed in memory didn't fix my previous CPU issues. But I know it's just between two things, the streaming of photos in MemoryStream or SignalR because this are the two main functions that would get the most requests when users are opening and commenting on albums. I'll run the miniprofiler today and come back with results. Thanks – dmc Jun 20 '12 at 00:33
  • by the way, i forgot to mention that the images are saved in the database, not in a directory. would that matter? – dmc Jun 20 '12 at 08:44
  • @DuncanMcIntyre: I would expect image data location to affect latency, but not CPU (unless the database is using excessive CPU which it shouldn't be: direct grab of BLOB by PK id shouldn't require significant CPU). – Richard Jun 20 '12 at 10:33
  • yeah I agree, and the fact that they are cached like Fabio (above) said - it won't matter. But can you please tell me if something is wrong with this code when pulling the image? [OutputCache(Duration = 604800, VaryByParam = "GUID")]public FileStreamResult GetFile(string guid) { Guid id = new Guid(guid); Thumbnail thumbnail = thumbService.GetThumbnailByGUID(id); Stream stream = new MemoryStream(thumbnail.FileContent.ToArray()); var fsr = new FileStreamResult(stream, "image"); return fsr; } – dmc Jun 20 '12 at 10:41
  • if nothing's wrong with that code then I might have to ask if SignalR could possibly be causing the high cpu usage? i am using signalr for realtime notifications like how it is in facebook, the seller is notified everytime a user comments on an item, and also notifies the customers who also commented on that item. – dmc Jun 20 '12 at 10:43
  • @DuncanMcIntyre That code has too many places issues could be (what's `thumbService`? etc.). Stop guessing and ***MEASURE***, anything else is wasting our time. – Richard Jun 20 '12 at 10:52
  • thumbService is a repository. Yeah I'll try the miniprofiler later. I'm still at work, sorry about that. Thanks – dmc Jun 20 '12 at 10:54
1

If you use a separate server to store your sessions, that will ease the session management load on your primary server, but you'll gain network overhead when reading/writing to sessions on the other server.

Using SQLServer mode I believe is the best option in your case, especially since it gives you the benefit of having a "hard" copy of your sessions, in case there is any kind of dispute over who commented/reserved the item first.

You're already using SQL to load your images, so why not just give it one more thing to do?

If I'm overlooking something, I'll let the community point it out.

Robert Iver
  • 711
  • 2
  • 9
  • 14
1

In my opinion, 800 users hitting the same server is not that light.

Sessionstate has nothing to do with it.

You're loading images from a database and holding them in cache. How many images do you have in cache? 100KB per image? 50K images or more?

If you get to a point that you have too many things in cache (not just images!), ASP.NET will automatically discard things in cache (depending on their importance). When you come to that point, your application will be constantly putting new things in cache that are being erased almost immediately after being inserted which is the same as not having the images in cache.

Anyway, I still think this might not be the case because if you really have 800 users hitting the same server at the same time, that's a lot.

I agree with @Richard. Use something like mini-profiler.

Fabio Milheiro
  • 8,100
  • 17
  • 57
  • 96
  • images are cached for 7days and each image is at least 30-50kb. Every week there are at least 3 new albums created with 200 photos as the maximum in each album...So every week there are at least 600 photos of 30-50kb each in cache. – dmc Jun 19 '12 at 16:04
  • So it's not a lot. If you have time, run miniprofiler. As you might have to do something if you end up having more than a 1000 users at the same time (like increasing the number of front-end servers and centering your session and cache and have the database on a separate server) – Fabio Milheiro Jun 19 '12 at 16:10
  • Yeah it's not a lot. And not all 200 photos are even loaded at once, I just initially load 20 on each album then add another 20 each time the user scrolls down the page. Yes I should probably try running mini profiler, haven't tried it yet so I still have to read how it should be setup. Unfortunately, additional servers is not an option for me because that would be very expensive for a small business like ours :) – dmc Jun 19 '12 at 16:14
  • Cool @DuncanMcIntyre! It might be a good time to provide feedback about the answers. – Fabio Milheiro Jun 19 '12 at 22:32
  • Thanks @Fabio Milheiro, I'll try running the mini profiler tonight and will come back with the results. Sorry for the late reply, I am in the Philippines (time difference). – dmc Jun 20 '12 at 00:28
  • by the way, i forgot to mention that the images are saved in the database, not in a directory. would that matter? – dmc Jun 20 '12 at 08:45
  • They're cached so no, it doesn't. – Fabio Milheiro Jun 20 '12 at 09:17
  • how about signalR? could it possibly be causing it? sorry i haven't ran the profiler yet cause i'm still working. i'll try it tonight. – dmc Jun 20 '12 at 09:47
  • I don't know what that is but from the description in nuget, I find it difficult for that to be the problem. – Fabio Milheiro Jun 20 '12 at 13:40