December 10, 2010 at 9:04 am
Christoph D (12/10/2010)
Prakash-205770 (12/9/2010)
From the view of database architect, sending emails is a business functionality and need to be hosted in a separate server as separate application! The application needs to read sqlserver!This seems like an interesting idea to me. If things get worse or if the performance-impact of sending newsletters (Steve said there is a little bit of slowdown at the beginning of the sending-process) is not accepted you can set up a replication of the newsletter-data to another server with SSDs. This one does not have to be clustered or as secure as any other server because it will only be there for the data-gathering so it will be easier to get the budget for it. So you would get the workload away from the productive system, disk as well as bandwidth. The response to these emails like bounce code and so on could be written directly back into the live system so it is not necessary to take too much care if this server runs all the time as long as it is up for the newsletters (a little bit before to synchronize the subscription) and the subscription does not time out.
If the application runs on a standalone-server without any other applications you may even set up an SQL Server there as a subscriber to reduce the high bandwidth-usage if this seems to get worse and may have a big impact on the site in the future.
Maybe this would be a relatively cheap solution to possible problems without too much reengineering of the applications and only with a short downtime if any at all (Locks while creating the snapshot for the replication if you start with a snapshot).
Another benefit could be that if the bottleneck is the SQL Server and not network or mailserver that with this architecture the sending could be splittet up more than one server. But maybe you don't want to put that much workload on the mailserver as well as the network.
Good thoughts. However, every server costs money, and in the short term, we don't want to add more. We lease space in a co-lo, and rent servers, and adding another is a significant cost over time. If it becomes a bigger problem, this is something to consider.
December 14, 2010 at 12:45 am
perhaps first look if your I/O is fine
Benchmarking SQL Server IO with SQLIO
December 14, 2010 at 1:59 am
In this case it might not be such a big deal, but surely a counter like Page Life Expectancy is a better way of monitoring Memory pressure??
December 14, 2010 at 1:50 pm
rabartels (12/14/2010)
perhaps first look if your I/O is fineBenchmarking SQL Server IO with SQLIO
Good idea, though we're already in production. Hard to stop things and bang on the disks with SQL IO right now. We might setup a test for a weekend, and see what we get for results v what the specs are.
December 14, 2010 at 1:53 pm
Not much of a guess for those that have been around for a while. :-D:-D:-D
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
December 14, 2010 at 2:01 pm
grahamc (12/14/2010)
In this case it might not be such a big deal, but surely a counter like Page Life Expectancy is a better way of monitoring Memory pressure??
This is typically measured in hours for us.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply