alw: dd - вполне себе тест для некоторого небольшого подмножества задач. разумеется вебхостинг к ним не относится.
но изначально мы не оговаривали что мерить будем, поэтому с троечкой - рано )
Ну и совсем попозже -с помощью bonie++ подобие реальной нагрузки.
В общем, мне понравился только tiobench. Может быть потому, что тесты дают нужный мне результат - превосходят обычный массив по разным тестам от 5 до 140 раз :)
bonnie++ я раньше пробовал, но тут он похоже сходит с ума от ssd и пишет на многих полях плюсики +++. в интернете пишут, что так он сигнализирует о неадекватных значениях.
Вот так выглядят результаты программного ssd-ускорителя поверх самых обычных дисков 1Tb 7200 rpm. кешируются просто блоки устройства и никаких изменений в скриптах не нужно. Прямо так берем и пихаем на хостинг.
Общий объем массива 700 Гб , а 50 гб ssd-кеша "хватит любой программе" (c). Не так важно, что на момент завершения теста на самом деле данные еще не записаны в raid1. Сервер можно спокойно выключать или перегружать. Все запишется позже.
Unit information
================
File size = megabytes
Blk Size = bytes
Rate = megabytes per second
CPU% = percentage of CPU used during the test
Latency = milliseconds
Lat% = percent of requests that took longer than X seconds
CPU Eff = Rate divided by CPU% - throughput per cpu load
anton831: А вот другой вопрос, может ли кто то с другого домена (возможно даже с того же сервера), подключить фаил из моей админки, если allow_url у хостера закрыто. Можно ли как то обойти это ограничение
все возможно. можно хоть целыми днями параноить. только вы тогда вообще перестанете программировать и выдавать продукт.
Himiko: Почему не ловить подобные аномалии? В смысле уведомлять администратора о подобных изменениях.
ну почему именно snmp ? и нужно ли вообще уведомлять?
в бюджетном ДЦ при ddos начинает тупить сетевое оборудование (а то и вообще мрет). Разбудят админа и без скриптов. Полезет на цисочку и посмотрит ip атакуемого и засунет в blackhole.
В приличном ДЦ наверное могут netflow собирать и анализировать, но при их больших объемах трафика ddos порядка 100 мбит в принципе не проблема : ну поливает и пусть поливает. Клиент или отключит сайт и ддос закончится. Или свалит и ддос закончится. Или защитится и ддос закончится.
При большом ддосе опять же разбудят админа.
От мониторинга только электричество почем зря расходуется и ложные срабатывания.
coolwebsearcher, bind ругается специально чтобы сигнализировать о потенциальной проблеме. Это не нормальная ситуация и, как видим, ТС даже решил принять меры.
при таких опциях получится забивание кеша неклиентами и прочие потенциально ненужные запросы.
во многих движках такая ошибка при использовании utf8 возникает.
если не погружаться в код, то можно попытаться с помощью настроек php подменить строковые функции http://ru.php.net/manual/en/mbstring.overload.php
часто это работает.
dd - вполне себе тест для некоторого небольшого подмножества задач. разумеется вебхостинг к ним не относится.
но изначально мы не оговаривали что мерить будем, поэтому с троечкой - рано )
Ну и совсем попозже -с помощью bonie++ подобие реальной нагрузки.
В общем, мне понравился только tiobench. Может быть потому, что тесты дают нужный мне результат - превосходят обычный массив по разным тестам от 5 до 140 раз :)
bonnie++ я раньше пробовал, но тут он похоже сходит с ума от ssd и пишет на многих полях плюсики +++. в интернете пишут, что так он сигнализирует о неадекватных значениях.
Вот так выглядят результаты программного ssd-ускорителя поверх самых обычных дисков 1Tb 7200 rpm. кешируются просто блоки устройства и никаких изменений в скриптах не нужно. Прямо так берем и пихаем на хостинг.
Общий объем массива 700 Гб , а 50 гб ssd-кеша "хватит любой программе" (c). Не так важно, что на момент завершения теста на самом деле данные еще не записаны в raid1. Сервер можно спокойно выключать или перегружать. Все запишется позже.
память специально ограничена 512mb, потому что tiobench кеш в памяти забивает.
Где-то в таких условиях потестируйте и посмотрим чей raid-контроллер действительно круче.
Для сравнения вот еще результаты такого же теста на чистом raid1 без ssd
Raistlin, ну так если TLER создавался для рейда, у вас именно Raid Edition диск, может все-таки можно ?
сейчас попробовал выключить и включить на RE4 - все нормально.
а вот и нет.
начинать с осознания кто такой ваш клиент и захочется ли ему погружаться в этот xml rpc.
посмотрите на api sms-агрегаторов - все очень просто и доступно.
если api для суровых банковских программистов, то следует что-то и похлеще выкинуть. а то им скучно там.
Бюджетным ДЦ нет смысла держать специалиста на постоянку, им выгоднее платить ему по часам*
ddos то многие разглядят, а вот чтобы исправить ложные срабатывания вашей гипотетической системы придется вызывать лично вас. и очень много раз.
А вот другой вопрос, может ли кто то с другого домена (возможно даже с того же сервера), подключить фаил из моей админки, если allow_url у хостера закрыто.
Можно ли как то обойти это ограничение
все возможно. можно хоть целыми днями параноить. только вы тогда вообще перестанете программировать и выдавать продукт.
Почему не ловить подобные аномалии? В смысле уведомлять администратора о подобных изменениях.
ну почему именно snmp ? и нужно ли вообще уведомлять?
в бюджетном ДЦ при ddos начинает тупить сетевое оборудование (а то и вообще мрет). Разбудят админа и без скриптов. Полезет на цисочку и посмотрит ip атакуемого и засунет в blackhole.
В приличном ДЦ наверное могут netflow собирать и анализировать, но при их больших объемах трафика ddos порядка 100 мбит в принципе не проблема : ну поливает и пусть поливает. Клиент или отключит сайт и ддос закончится. Или свалит и ддос закончится. Или защитится и ддос закончится.
При большом ддосе опять же разбудят админа.
От мониторинга только электричество почем зря расходуется и ложные срабатывания.
coolwebsearcher, любую проблему. ТС не выключал и увидел свою проблему.
coolwebsearcher, пожалуй, безопасно, но лишаете себя возможности увидеть в логах потенциальную проблему.
coolwebsearcher, bind ругается специально чтобы сигнализировать о потенциальной проблеме. Это не нормальная ситуация и, как видим, ТС даже решил принять меры.
при таких опциях получится забивание кеша неклиентами и прочие потенциально ненужные запросы.