Коллеги, всем привет!
Писал у себя в дневнике марафона, но дублирую сюда.
Проблема такая:
Mail периодически долго отдает ответ, причин может быть множество, но суть одна - при запросе нашего парсера к mail при определенном количестве запросов, происходит пауза от Mail.
Боты поисковых систем генерируют запросы к Mail, также как и обычные пользователи.
Следовательно, растет количество процессов на сервере. При этих "Паузах" от mail переполняется оперативная память, сколько бы ее не было. И процессы падают, в том числе и база данных.
Говорю не по наслышке, а сам испытываю ежедневные падения базы данных по 5-7 раз в день.
На мой взгляд, решение здесь очень простое:
1) При обращении к mail, если ожидание ответа в N количество времени дольше обычного, то прерывать ожидание ответа от mail и генерировать статическую страницу с "Такого трека не найдено" и не кэшировать полученную страницу.
2) После того, как "пауза" от mail пройдет, робот снова зайдет на эту страницу (когда-то все же зайдет) и она сгенерируется заново с нормальным списком треков, и тогда уже будет закеширована.
Тем самым мы избавляемся от простоев сайта, а также избавимся от некорректных ответов сервера при обходе бота. Ну и сайт будет работать шустрее.
Эта доработка, на мой взгляд, несложная, и очень важная. Прошу помощи.
Для понимания - у меня сейчас сервер с 2 Гб оперативы, а сайт один, всего 400 хостов. При нормальной работе Mail даже 400 МБ оперативки достаточно, но при "паузах" оперативки не хватит никаких объемов, хоть 10 ГБ поставить. Тут даже дело не в хостах, а в том, что роботы заходят и обращаются к Mail. Я всех ненужных роботов заблочил, в вебмастерах ограничил скорость обхода ботами ПС. Поэтому это вопрос рентабельности вообще этого парсера!
Что скажете? @MSE @Seopirat
Писал у себя в дневнике марафона, но дублирую сюда.
Проблема такая:
Mail периодически долго отдает ответ, причин может быть множество, но суть одна - при запросе нашего парсера к mail при определенном количестве запросов, происходит пауза от Mail.
Боты поисковых систем генерируют запросы к Mail, также как и обычные пользователи.
Следовательно, растет количество процессов на сервере. При этих "Паузах" от mail переполняется оперативная память, сколько бы ее не было. И процессы падают, в том числе и база данных.
Говорю не по наслышке, а сам испытываю ежедневные падения базы данных по 5-7 раз в день.
На мой взгляд, решение здесь очень простое:
1) При обращении к mail, если ожидание ответа в N количество времени дольше обычного, то прерывать ожидание ответа от mail и генерировать статическую страницу с "Такого трека не найдено" и не кэшировать полученную страницу.
2) После того, как "пауза" от mail пройдет, робот снова зайдет на эту страницу (когда-то все же зайдет) и она сгенерируется заново с нормальным списком треков, и тогда уже будет закеширована.
Тем самым мы избавляемся от простоев сайта, а также избавимся от некорректных ответов сервера при обходе бота. Ну и сайт будет работать шустрее.
Эта доработка, на мой взгляд, несложная, и очень важная. Прошу помощи.
Для понимания - у меня сейчас сервер с 2 Гб оперативы, а сайт один, всего 400 хостов. При нормальной работе Mail даже 400 МБ оперативки достаточно, но при "паузах" оперативки не хватит никаких объемов, хоть 10 ГБ поставить. Тут даже дело не в хостах, а в том, что роботы заходят и обращаются к Mail. Я всех ненужных роботов заблочил, в вебмастерах ограничил скорость обхода ботами ПС. Поэтому это вопрос рентабельности вообще этого парсера!
Что скажете? @MSE @Seopirat