ware: Это считается от даты создания компании, а не смены владельца.
Это как-то интересно считается.
Когда удобно - нам 9 лет.
А когда "не очень" - мы за прошлые косяки не отвечаем:
Игорь Белов:
По ситуации 2010 года здесь задают вопросы, в основном, не для получения ответа, а для разведения флуда и провокации. Пожалуйста, задавайте вопросы по действующим услугам компании и я обязательно Вам отвечу.
upd Название компании форум звёздочками заменил.. при вставке цитата была полной.
Оптимизайка: В БД изображения хранить удобно лишь в случае, когда имеется кластер из нескольких web-серверов.
когда имеется кластер из нескольких web-серверов, можно и в распределённой FS хранить... понимаю, что web-сервер употреблён в значении "железяка", но тем не менее
Ayavryk: Назвать этих программистов лохами не смогу. Реально большие высоконагруженные проекты (400.000 хитов)
не-не.. речь не о "лох-нелох".
Я бы на статистику/бенчмарки (если с пояснениями - вообще круть) посмотрел... ну т.е. если БД "делает" FS (по производительности и/или безопасности и/или удобству использования), то за счёт чего...
права на файлы настраиваются, отдача "после проверки" - легко;
под кэш ФС можно место выделить;
по поводу удобства - не хватает знаний+фантазии представить...;
Ayavryk: Из плюсов - решаются проблемы о которых здесь говорили: проще хранить, манипулировать большими объемами, бэкапить. Проще обеспечить безопасность/приватность - напрямую картинку не вытащишь.
Ayavryk, а есть реальный опыт использования такого? Может не у самого.. у знакомых "фанов" (с)?
- Проще хранить = ? гигантская таблица о_О чем проще-то?
- манипулировать большими объемами.. можно на уровне fs "манипулировать"
- бэкапить - тот же инкрементальный архив.. или rsync.. аккуратно всё положит вместо дампа на гигабайты
- обеспечить безопасность/приватность nginx + x-accel-redirect - имхо, вполне приемлемая безопасность в сочетании со скоростью отдачи. Если речь о безопасности на уровне сервера - с правами "поиграться"...
Den73: я не понимаю как увеличение интервала может повлиять на исп. ресурсов в целом.
Запустить у себя на не слишком громадных мощностях ab (или что-нибудь более "разнобойное" - loadimpact пользовался) с разными параметрами (per second) и посмотреть... Когда куча запросов к apache и к mysql будут в очереди висеть - думаю, понимание придёт. Даже после завершения "атаки бота"...
p.s. у меня ощущение, что я как-то не совсем понятно изъясняюсь.. Эт я могу..
Den73: а толку, это же просто интервал запросов, сколько им нужно сделать request - столько они и сделают все равно просто с другим интервалом.
Робот может и сделает то же количество обращений, но он не будет одномоментно (с короткими промежутками, пока сервер не успел обработать, добавлять ему ещё пару) грузить сервер кучей запросов. Всплесков не будет.
Den73: используемые ресурсы пользователем будут такие же в итоге.
Используемые ресурсы в единицу времени уменьшатся при уменьшении request per second (или увеличении таймаута между запросами, что по сути одно и то же)
Также мы даём возможность прикрепить свой домен к контейнеру в хранилище, который можно использовать для раздачи статичных данных, например: static.domain.ru/img.png
Den73: а во вторых если заблокирует то вызов apache все равно проходит.
Ну.. зато загрузка WP со всеми плагинами не проходит..
На шареде не так много вариантов ведь:
- Поинтересоваться у хостера, можно ли ограничить количество обращений в секунду. (mod_limitconn.. если nginx фронтендом стоит - про limit_req спросить)
- в RewriteCond по %{USER_AGENT} проверять... так, например:
Зачем? Компания существует 9 лет. На кой шут им отсчитывать время с момента смены владельца, если не менялась компания?
Пруф будет?
http://mchost.ru/about/
Вбиваем сюда: http://egrul.nalog.ru/
Это считается от даты создания компании, а не смены владельца.
Это как-то интересно считается.
Когда удобно - нам 9 лет.
А когда "не очень" - мы за прошлые косяки не отвечаем:
По ситуации 2010 года здесь задают вопросы, в основном, не для получения ответа, а для разведения флуда и провокации.
Пожалуйста, задавайте вопросы по действующим услугам компании и я обязательно Вам отвечу.
upd Название компании форум звёздочками заменил.. при вставке цитата была полной.
В БД изображения хранить удобно лишь в случае, когда имеется кластер из нескольких web-серверов.
когда имеется кластер из нескольких web-серверов, можно и в распределённой FS хранить... понимаю, что web-сервер употреблён в значении "железяка", но тем не менее
Назвать этих программистов лохами не смогу. Реально большие высоконагруженные проекты (400.000 хитов)
не-не.. речь не о "лох-нелох".
Я бы на статистику/бенчмарки (если с пояснениями - вообще круть) посмотрел... ну т.е. если БД "делает" FS (по производительности и/или безопасности и/или удобству использования), то за счёт чего...
права на файлы настраиваются, отдача "после проверки" - легко;
под кэш ФС можно место выделить;
по поводу удобства - не хватает знаний+фантазии представить...;
Из плюсов - решаются проблемы о которых здесь говорили: проще хранить, манипулировать большими объемами, бэкапить. Проще обеспечить безопасность/приватность - напрямую картинку не вытащишь.
Ayavryk, а есть реальный опыт использования такого? Может не у самого.. у знакомых "фанов" (с)?
- Проще хранить = ? гигантская таблица о_О чем проще-то?
- манипулировать большими объемами.. можно на уровне fs "манипулировать"
- бэкапить - тот же инкрементальный архив.. или rsync.. аккуратно всё положит вместо дампа на гигабайты
- обеспечить безопасность/приватность nginx + x-accel-redirect - имхо, вполне приемлемая безопасность в сочетании со скоростью отдачи. Если речь о безопасности на уровне сервера - с правами "поиграться"...
я не понимаю как увеличение интервала может повлиять на исп. ресурсов в целом.
Запустить у себя на не слишком громадных мощностях ab (или что-нибудь более "разнобойное" - loadimpact пользовался) с разными параметрами (per second) и посмотреть... Когда куча запросов к apache и к mysql будут в очереди висеть - думаю, понимание придёт. Даже после завершения "атаки бота"...
p.s. у меня ощущение, что я как-то не совсем понятно изъясняюсь.. Эт я могу..
Я же уже писал что большую часть времени занимает запись в базу
- Писать в memory таблицу, а потом - INSERT INTO ... SELECT *
- про Load DATA INFILE почитать
ivan-lev, ТРОЛОЛО,
Жаль, на большее не хватает...
Den73, не уверен, что мы друг друга поняли.
а толку, это же просто интервал запросов, сколько им нужно сделать request - столько они и сделают все равно просто с другим интервалом.
Робот может и сделает то же количество обращений, но он не будет одномоментно (с короткими промежутками, пока сервер не успел обработать, добавлять ему ещё пару) грузить сервер кучей запросов. Всплесков не будет.
используемые ресурсы пользователем будут такие же в итоге.
Используемые ресурсы в единицу времени уменьшатся при уменьшении request per second (или увеличении таймаута между запросами, что по сути одно и то же)
А как же тогда используя мой урл, будет как то реврайтится на облако?
Поддомен
Например, так: http://habrahabr.ru/company/selectel/blog/143796/
а во вторых если заблокирует то вызов apache все равно проходит.
Ну.. зато загрузка WP со всеми плагинами не проходит..
На шареде не так много вариантов ведь:
- Поинтересоваться у хостера, можно ли ограничить количество обращений в секунду. (mod_limitconn.. если nginx фронтендом стоит - про limit_req спросить)
- в RewriteCond по %{USER_AGENT} проверять... так, например:
RewriteRule .* - [L,F]
это не поможет.
"правильные" роботы слушаются. А неправильных - в бан.. Другое дело, что он может User Agent-а поменять.. или вообще не передавать..
А что изменится с поддоменом?
Если DNS будет смотреть на другой сервер, трафик не будет считаться на основном сервере.
Может порекомендуете облако, где оно поддерживает привязку поддомена?
Может VPS/VDS взять с безлимитным трафиком под картинки..
Или доплатить за траф на основном сервере?