Любые советы по архитектуре для отправки ежедневных, еженедельных обновлений по электронной почте, которые требуют расчета - PullRequest
0 голосов
/ 29 июля 2010

У меня есть веб-приложение, которое будет отправлять ежедневные еженедельные обновления по электронной почте в зависимости от разрешений пользователей и настроек оповещений (ежедневно, еженедельно, ежемесячно или вообще без них).

Каждое электронное письмо на учетную запись (которая будет иметь несколько пользователей) требует нескольких вызовов БД и расчетов.Таким образом, делая эти ежедневные / еженедельные электронные письма довольно дорогими, поскольку количество пользователей увеличивается.

Есть ли общие советы по написанию этих сервисов?Я ищу некоторые советы по архитектуре или шаблоны, а не такие темы, как доставка электронной почты.

Ответы [ 2 ]

0 голосов
/ 29 июля 2010

Возможно, вы захотите воспользоваться службами отчетности sql.

Возможно, вам придется перевести текущую настройку в формат отчетов sql, но взамен вы получите целый административный интерфейс для планирования генерации отчетов, позволяющий пользователям изменять входные данные отчетов, кэшировать исторические / текущие отчеты и возможность для пользователей, чтобы управлять своими собственными почтовыми подписками.

http://msdn.microsoft.com/en-us/library/ms160334.aspx

0 голосов
/ 29 июля 2010

Я бы кэшировал данные до времени обработки, если вам приходится обрабатывать очень большие наборы информации, чтобы «вычисления» БД можно было исключить из цикла обработки в определенное время. Эффективно разбить обработку так, чтобы интенсивная работа с БД выполнялась немного раньше запланированной обработки информации. Когда приходит время отправлять эти электронные письма, я думаю, что вы можете быстро обработать очень большой объем, не тратя много времени на предварительную настройку. Конечно, я также не знаю, о каком томе мы говорим.

Вы также можете организовать потоковую обработку приложения, чтобы ваши данные обработки были дополнительно разбиты на логические порции, чтобы уменьшить общий объем данных, которые должны обрабатываться одновременно, в зависимости от вашей ситуации это может упростить задачу, как обычно, я обычно не Не рекомендую переходить к многопоточности, если для этого нет веских причин, и у вас может быть такая причина. По крайней мере, используйте фоновый рабочий тип многопоточного процесса и запускайте несколько в зависимости от того, как вы сегментируете свои данные.

При обработке исключений не забывайте позволять тем, кто останавливает вашу обработку, обрабатывать их посредством каких-либо журналов или уведомлений, а затем двигаться дальше, вы не хотели бы, чтобы ошибка приводила к ошибкам для дальнейшей обработки, я уверен Вы, вероятно, планировали это, хотя.

Кроме того, отправляйте свои электронные письма асинхронно, чтобы они не блокировали обработку, это, вероятно, очевидное соблюдение, но иногда такие мелочи упускаются из виду и могут создавать узкое место при отправке большого количества электронных писем.

И, наконец, протестируйте его с достаточной нагрузкой заранее и стреляйте на предмет большой емкости.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...