Оповещения по электронной почте о сохраненных поисках, процедурах и рекомендациях по безопасности / производительности? - PullRequest
0 голосов
/ 19 сентября 2010

Я создал оповещение по электронной почте для моих пользователей (сейчас их всего 2000) поэтому каждую ночь crontab выполняет скрипт php, который запрашивает mysql для поиска совпадений с сохраненным поиском пользователя в моем случае это секретный сайт, но я бы хотел узнать, нужно ли что-то создавать для крупных клиентов

мои проблемы:

  1. что произойдет, если мой пользователь вырастет в 10 раз или х100 раз? сервер собирается врезаться? есть ли совет, который вы можете предложить на что-нибудь подобное?

  2. есть ли способ защитить мой файл cron / nightly_script.php будет заполненная форма вне вызова его в URL браузера? рассматривать я использую строку в crontab как:

    lynx [absolute url / script.php]

  3. как насчет взрыва электронной почты? для каждого запрос, если запрос имеет результаты Скрипт отправляет электронное письмо, поэтому оно означает Взрыв электронной почты ... это будет считается спамом автоматически и тогда я мог бы в черный список?

спасибо !!!

Ответы [ 4 ]

1 голос
/ 20 сентября 2010

что произойдет, если мой пользователь вырастет в x10 или х100 раз? сервер собирается врезаться? есть ли совет, который вы можете предложить на что-нибудь подобное?

Ваш сервер может аварийно завершить работу / работать медленно из-за большого использования памяти / процессоров. Вам следует использовать очередь сообщений, такую ​​как redis / beanstalkd / gearmand, чтобы регулировать оповещения по электронной почте. Мои предпочтения выходят на Redis. используйте блокировку pop / push с библиотекой predis , которая поддерживает блокировку pop / push.

есть способ защитить мой файл cron / nightly_script.php будет выполнен Форма вне вызова его в URL браузер? рассмотреть их с помощью строка в crontab вроде:

Не используйте cron, если вы хотите масштабировать. Вместо этого создайте пару демонов.

  • 1 для планирования отправки сообщений (эта часть также может быть cron) в очередь сообщений,
  • 1 для обработки сообщений, отправляемых в очередь сообщений.

Демоны не нужно порождать каждый раз, а процессы порождения ((относительно) дороги. Во-вторых, ваш сценарий не должен больше вызывать URL, а вместо этого вызывать сценарии PHP напрямую (CLI).

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

При использовании очереди сообщений вы можете задушить себя!

1 голос
/ 19 сентября 2010

Номер 1: Контролируйте сервер, следите за загрузкой и временем, которое требуется для запуска.Это не должно приводить к сбою, но вы можете обнаружить, что достигли точки, когда нагрузка слишком высока, и запросы на веб-страницы начинают замедляться.

Но одна вещь, на которую стоит обратить внимание, это то, что мусор в памяти PHP иногда может быть страннымтак что следите за использованием памяти заданием cron.Если он достигнет высокого уровня, PHP рухнет.

Если он начнет слишком много, есть много решений;например, нет необходимости иметь веб-сервер и отправлять электронную почту на одном компьютере.Пока они могут получить доступ к одной и той же базе данных, настройте второй сервер только для отправки электронной почты.Для этого идеально подходят облачные вычисления: нанимайте 2-й сервер 4 часа в сутки (или что-то в этом роде) и отключайте его в остальное время.

Это всего лишь одно предложение ... Есть много решений, и это действительно зависит от вашей ситуации.

1 голос
/ 19 сентября 2010
  1. Что ж, вам, вероятно, следует изменить свой скрипт, чтобы можно было распределить нагрузку. Например, вы можете запускать cron 4+ раза в день, и каждый раз, когда он делает процент от пользовательской базы, вместо того, чтобы делать их все раз в день.

  2. Вы можете удалить его из целевого пути веб-сервера и поместить cron туда, где я не доступен извне. Это может быть выполнено так: php /location/of/script.php

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

0 голосов
/ 19 сентября 2010

Что касается номера 2, лучшим решением было бы переместить скрипт за пределы корня документа, чтобы он не был доступен из браузера, и вызвать его напрямую

php [location/script.php]

Если вы не можете этого сделать, ябудет выполнять проверку IP и разрешать вызов только с локального IP-адреса.

Вы также можете встроить безопасные проверки: сохранить, когда в последний раз вы отправляли электронное письмо конкретному пользователю, и проверить это перед отправкой другого,Это защитит от проблем crontab, а также от хакеров.

...