Доброе время суток.
Понимаю, что вопрос нередкий, но ответы на него столь быстро меняются,
что актуальной инфо может и нет.
Требования
0) .net не рассматривается
1) Обслуживание большого числа пользователей
2) Хранение больших БД с множеством полей
3) Сервер будет работать с клиентом. Клиент работает через flash.
4) Высокий уровень безопасности
5) Сайт должен быть симпотичным
6) Будут висеть демоны (вдруг это важно) (и наверное много)
* Задача сервера: авторизовать, распределить ключи, хранить настройки и на нем также будет сам сайт.
* Причем клиентская программа может работать на любом сайте (вдруг это тоже важно) и на сайте сервера тоже.
* Желательно, чтобы это было java или python или perl (что лучше?).
* Какой лучше всего взять сервер, что Вы думаете о Apache, nginx? Что лучше для этих серверов (в смысле java,python,perl или c++ или...).
* Какая ОС подходит наиболее для этих серваков? Какой *nix наиболее подходящий для этих требований и не очень жесткий в настройках
(или хотя бы жесткий, но много инфы в нете)?
* И какая БД Вам больше всего нравится и подходит по требованиям? Что Вы думаете о MongoDB, что нужно знать, чтобы с ней работать?
* Неконкретный вопрос, но отвечая на другие вопросы, как это скажется на hard'e сервера?
* И конечно, сколько это стоит?(+ лицензии, если они с подковыркой)
Возможно, я путаю несколько тем сразу, но по сути ведь это все составляющие сервера или зависит от того, что на сервере.
Просьба, если у Вас есть мнение хотя бы на один вопрос, то ответьте (авось ответы наберутся).
Заранее спасибо.
V>Понимаю, что вопрос нередкий, но ответы на него столь быстро меняются, V>что актуальной инфо может и нет. V>Требования
Смешались в кучу кони, люди.
V>0) .net не рассматривается
Почему?
V>1) Обслуживание большого числа пользователей
Что значит много?
V>2) Хранение больших БД с множеством полей
Что значит большие БД с полями? Может быть, таблицы с полями? И таких таблиц может быть много? Или полей в таблице может быть много?
V>3) Сервер будет работать с клиентом. Клиент работает через flash.
Сервер всегда работает с клиентом. То, что это будет флэш — это дело десятое.
V>4) Высокий уровень безопасности
Как спроектируешь, такой и будет. От языка программирования не зависит
V>5) Сайт должен быть симпотичным
Как спроектируешь, такой и будет. От языка программирования не зависит
V>6) Будут висеть демоны (вдруг это важно) (и наверное много)
Пусть висят
V>* Задача сервера: авторизовать, распределить ключи, хранить настройки и на нем также будет сам сайт.
Как спроектируешь, так и будет. От языка программирования не зависит
V>* Причем клиентская программа может работать на любом сайте (вдруг это тоже важно) и на сайте сервера тоже.
Что значит «клинетская программа будет работать и на сервере тоже»?
V>* Желательно, чтобы это было java или python или perl (что лучше?).
Зависит от задачи, от уровня занний, от опыта команды, от знаний команды.
V>* Какой лучше всего взять сервер, что Вы думаете о Apache, nginx? Что лучше для этих серверов (в смысле java,python,perl или c++ или...).
Зависит от задачи
V>* Какая ОС подходит наиболее для этих серваков? Какой *nix наиболее подходящий для этих требований и не очень жесткий в настройках V>(или хотя бы жесткий, но много инфы в нете)?
Ubuntu Server по умолчанию достаточно, чтобы начать, не особо забивая себе мозг
V>* И какая БД Вам больше всего нравится и подходит по требованиям? Что Вы думаете о MongoDB, что нужно знать, чтобы с ней работать?
Так нет же требований. Были бы, подсказали бы.
V>* Неконкретный вопрос, но отвечая на другие вопросы, как это скажется на hard'e сервера?
Как спроектируешь, так и скажется
V>* И конечно, сколько это стоит?(+ лицензии, если они с подковыркой)
Здравствуйте, venicum, Вы писали:
V>Я писал: V>>Доброе время суток. V>>... V>>Заранее спасибо. V>Пока получается так: FreeBSD + Apache + nginx + python (на сервере). V>С БД еще не определился.
тогда и PostgresSQL в догонку ))
если игромеханика не сложная, то Python'а должно хватить, а если что-то типа realtime с тесным взаимодействием, то придется некоторые части писать на C/C++ тут иначе никак...
Здравствуйте, Mamut, Вы писали: M>Смешались в кучу кони, люди.
Да я об этом говорил M>Почему?
Такие требования M>Что значит много? (пользователей)
порядка 100000 чел в с сутки, а то может и больше M>Что значит большие БД с полями? Может быть, таблицы с полями? И таких таблиц может быть много? Или полей в таблице может быть много?
Не мало таблиц, полей тоже не мало. Большие значит много записей (очень много). M>Сервер всегда работает с клиентом. То, что это будет флэш — это дело десятое.
Это хорошо M>Как спроектируешь, такой и будет. От языка программирования не зависит
Тоже хорошо. Какой язык Вам больше нравится? M>Как спроектируешь, такой и будет. От языка программирования не зависит
Тоже хорошо. Какой язык Вам больше нравится? У которого по богаче возможности, по-минимому грузящий сервер. M>Что значит «клинетская программа будет работать и на сервере тоже»?
Это я не правильно сформулировал, потом уже понял, вопрос отпал. M>Зависит от задачи, от уровня занний, от опыта команды, от знаний команды.
Какой из приведенных языков какой уровень требует не подскажите? M>Зависит от задачи
Так что же Вы думаете по поводу Apache, nginx? M>Ubuntu Server по умолчанию достаточно, чтобы начать, не особо забивая себе мозг
А она сильно отличается от других популярных никсов, которые скорее всего потом будут на хостинге? M>Так нет же требований. Были бы, подсказали бы.
Теперь есть или еще надо добавить? M>Как спроектируешь, так и скажется
А-а M>Непонятно, что и как считать.
А теперь?
Здравствуйте, Viper_Craft, Вы писали: V_C>Здравствуйте, venicum, Вы писали: V>>Я писал: V>>>Доброе время суток. V>>>... V>>>Заранее спасибо. V>>Пока получается так: FreeBSD + Apache + nginx + python (на сервере). V>>С БД еще не определился. V_C>тогда и PostgresSQL в догонку )) V_C>если игромеханика не сложная, то Python'а должно хватить, а если что-то типа realtime с тесным взаимодействием, то придется некоторые части писать на C/C++ тут иначе никак...
Да я так и собирался, спасибо.
Я писал, решил еще уточнить. V>Здравствуйте, Mamut, Вы писали: M>>Что значит много? (пользователей) V>порядка 100000 чел в с сутки, а то может и больше
Много людей будут пользоваться сервером одновременно, продолжительность сессии секунд может 5.
Периодически клиент будет отправлять на сервер небольшую информацию о себе. Это нужно будет заносить в базу, чтобы сервер был в курсе,
что же там творит клиент. M>>Что значит большие БД с полями? Может быть, таблицы с полями? И таких таблиц может быть много? Или полей в таблице может быть много? V>Не мало таблиц, полей тоже не мало. Большие значит много записей (очень много).
С 5-6 нулями * на число
M>>Что значит много? (пользователей) V>порядка 100000 чел в с сутки, а то может и больше
Прямо сразу или это планируемая достижимая цифра?
M>>Что значит большие БД с полями? Может быть, таблицы с полями? И таких таблиц может быть много? Или полей в таблице может быть много? V>Не мало таблиц, полей тоже не мало. Большие значит много записей (очень много).
Что такое очень много? 100 000? Миллион? 10 миллионов? (прочитал в дополнении, что до десятка миллиона записей на каждого пользователя)
M>>Как спроектируешь, такой и будет. От языка программирования не зависит V>Тоже хорошо. Какой язык Вам больше нравится?
Мне нравится Erlang Но зря ты убрал контекст. Здесь был вопрос: «Высокий уровень безопасности». Это не зависит от языка программирования.
M>>Как спроектируешь, такой и будет. От языка программирования не зависит V>Тоже хорошо. Какой язык Вам больше нравится? У которого по богаче возможности, по-минимому грузящий сервер.
Мне нравится Erlang Но зря ты убрал контекст. Здесь был вопрос: «Сайт должен быть симпотичным». Это не зависит от языка программирования. Это зависит от дизайнера и верстальщика сайта.
«Богатые возможности» надо рассматривать только в контексте поставленной задачи. Например, умение Perl'а работать с текстом нафиг не нужно, если нужно просто что-то писать в log.
M>>Зависит от задачи, от уровня занний, от опыта команды, от знаний команды. V>Какой из приведенных языков какой уровень требует не подскажите?
Зависит и от задачи и от команды и от языка программирования. Зависит от того, что с данными надо делать. Если их просто надо писать в лог, то можно взять вообще любой язык программирования. Если надо проводить сложный анализ, синтаксический и семантический разбор текста, то понадобятся другие языки и команда совсем другого уровня.
Если это онлайн игра, то любой язык, который команда лучше всего знает или готова выучить.
M>>Зависит от задачи V>Так что же Вы думаете по поводу Apache, nginx?
Так как прозвучала цифра 100 000 человек в сутки, Апач отпадает.
M>>Ubuntu Server по умолчанию достаточно, чтобы начать, не особо забивая себе мозг V>А она сильно отличается от других популярных никсов, которые скорее всего потом будут на хостинге?
Для 100 000 человек в сутки и сотен миллионов записей все понадобится выделенный сервер, а там может быть и Убунту (у меня — Убунту). И нет, не сильно отличается.
M>>Так нет же требований. Были бы, подсказали бы. V>Теперь есть или еще надо добавить?
Скопирую сюда требования:
Много людей будут пользоваться сервером одновременно, продолжительность сессии секунд может 5.
Периодически клиент будет отправлять на сервер небольшую информацию о себе. Это нужно будет заносить в базу, чтобы сервер был в курсе,
что же там творит клиент.
Непонятно, что с этой информацией дальше надо делать. Если периодически, небольшая информация, то может поставить ejabberd, к нему прикрутить/написать требуемые модули и не мучаться?
Если это всего лишь логгер каких-то действий, то на среднем сервере с этим даже РНР справится.
Если это онлайн игра (угадал?), то все равно справится РНР Хотя можно попробовать любой другой язык, который знаешь, который нравится или который можно быстро выучить.
M>>Как спроектируешь, так и скажется V>А-а M>>Непонятно, что и как считать. V>А теперь?
Здравствуйте, Mamut, Вы писали: V>>порядка 100000 чел в с сутки, а то может и больше M>Прямо сразу или это планируемая достижимая цифра?
Конечно, планируемая . Сервис социальный как бы.
А задачу я писал: авторизовать, распределить ключи, хранить настройки и на нем также будет сам сайт.
Эти настройки нужны для клиентской программы, ключи, т.к. будет обмениваться информация "серьезная". M>Что такое очень много? 100 000? Миллион? 10 миллионов? (прочитал в дополнении, что до десятка миллиона записей на каждого пользователя)
Возможно, я не так понимаю терминологию. Запись одна на одного юзера и в ней не мало полей, которые относятся к юзеру: логин, пароль,
сколько раз заходил, другая статистика, настройки клиентской программы (может и в отдельной таблице, хотя как я понимаю mongodb без таблиц и мне это нравится ). M>Мне нравится Erlang Но зря ты убрал контекст. Здесь был вопрос: «Высокий уровень безопасности». Это не зависит от языка программирования.
Учить новый язык совсем не хочется. Я больше склоняюсь к python + C++ на сервере. M>Мне нравится Erlang Но зря ты убрал контекст. Здесь был вопрос: «Сайт должен быть симпотичным». Это не зависит от языка программирования. Это зависит от дизайнера и верстальщика сайта.
Тогда все отлично. M>«Богатые возможности» надо рассматривать только в контексте поставленной задачи. Например, умение Perl'а работать с текстом нафиг не нужно, если нужно просто что-то писать в log.
Сервер будет слушать порты, получать инфо от пользователей и давать им ключи для передачи данных серверу (через ассиметричный), perl лично я как-то
и не очень хотел, python красивше . M>Зависит и от задачи и от команды и от языка программирования. Зависит от того, что с данными надо делать. Если их просто надо писать в лог, то можно взять вообще любой язык программирования. Если надо проводить сложный анализ, синтаксический и семантический разбор текста, то понадобятся другие языки и команда совсем другого уровня.
Надо будет делать анализ, но структуру передаваемых данных понятно думать будем сами, python с этим отлично справится M>Если это онлайн игра, то любой язык, который команда лучше всего знает или готова выучить.
Не это не игра M>Так как прозвучала цифра 100 000 человек в сутки, Апач отпадает.
Оуоуоу. Это плохо, а не подскажете какой сервер можно использовать? А если apache + nginx (вроде это ускоряет работу)? M>>>Ubuntu Server по умолчанию достаточно, чтобы начать, не особо забивая себе мозг M>Для 100 000 человек в сутки и сотен миллионов записей все понадобится выделенный сервер, а там может быть и Убунту (у меня — Убунту). И нет, не сильно отличается.
Когда арендуешь выделенку, ведь предоставляют ОС на выбор из списка? Хотя это к теме уже не очень относится. M>Скопирую сюда требования: M>
M>Много людей будут пользоваться сервером одновременно, продолжительность сессии секунд может 5. (1)
M>Периодически клиент будет отправлять на сервер небольшую информацию о себе. Это нужно будет заносить в базу, чтобы сервер был в курсе,
M>что же там творит клиент. (2)
(1) Это генерация паролей по RSA, (2) а это как раз-таки данные, которые надо парсить M>Непонятно, что с этой информацией дальше надо делать. Если периодически, небольшая информация, то может поставить ejabberd, к нему прикрутить/написать требуемые модули и не мучаться?
Erlang для меня все равно, что Algol60 — слышал, но не видел. M>Если это всего лишь логгер каких-то действий, то на среднем сервере с этим даже РНР справится.
Не совсем, пользователь также может вносить изменения в свои настройки и соот надо их менять в его записи. M>Если это онлайн игра (угадал?), то все равно справится РНР Хотя можно попробовать любой другой язык, который знаешь, который нравится или который можно быстро выучить.
поэтому python + c++ — знаю и хочется попробовать M>Все равно непонятно Вот, например, что использовали ребята из eventr: http://habrahabr.ru/blogs/webdev/99101/ Там похожая задача, только с другой стороны
А я эту статью уже читал сегодня , спасибо
Я писал: V>...много чего...
Кому тема интересна.
Последний раз Mamut писал, что apache в пролете для высоко нагруженных серверов.
И судя по отношению Mamut'a к php программистам, пишущих игрушки на flash, очевидно, Mamut прав
Что есть другое: на wiki есть веб-серверы, оттуда узнаем про lighttpd, nginx (made in Russia).
Оба для "крутых" серверов. Здесь неплохая статья по nginx: http://hlabs.spb.ru/development/nginx.html.
Многое разъясняет, если многое не знаешь.
V>>>порядка 100000 чел в с сутки, а то может и больше M>>Прямо сразу или это планируемая достижимая цифра? V>Конечно, планируемая . Сервис социальный как бы.
Тогда не знаю, есть ли смысл сразу бросаться на задачу как на «сразу получим 100 000» посетителей. С другой стороны, чем черт не шутит.
V>А задачу я писал: авторизовать, распределить ключи, хранить настройки
Это мелочь
V>и на нем также будет сам сайт.
А вот что за сайт, что он будет делать и т.п. — это уже совсем не мелочь.
V>Эти настройки нужны для клиентской программы, ключи, т.к. будет обмениваться информация "серьезная". M>>Что такое очень много? 100 000? Миллион? 10 миллионов? (прочитал в дополнении, что до десятка миллиона записей на каждого пользователя) V>Возможно, я не так понимаю терминологию. Запись одна на одного юзера и в ней не мало полей, которые относятся к юзеру: логин, пароль, V>сколько раз заходил, другая статистика, настройки клиентской программы (может и в отдельной таблице, хотя как я понимаю mongodb без таблиц и мне это нравится ).
Зачем держать все в одной таблице, если те же настройки у одного клиента будут меняться может раз в год (как пример)? То, что в MongoDB нет таблиц в классическом понимании, не значит, что все надо пихать в один документ.
M>>«Богатые возможности» надо рассматривать только в контексте поставленной задачи. Например, умение Perl'а работать с текстом нафиг не нужно, если нужно просто что-то писать в log. V>Сервер будет слушать порты, получать инфо от пользователей и давать им ключи для передачи данных серверу (через ассиметричный)
И вот здесь засада Какие данные, что с этими данными должен будет делать сервер? Потому что генерация ключа — это мелочь по сравнению с тем что может делать весь остальной сайт.
V>, perl лично я как-то и не очень хотел, python красивше .
Perl я как пример привел.
M>>Так как прозвучала цифра 100 000 человек в сутки, Апач отпадает. V>Оуоуоу. Это плохо, а не подскажете какой сервер можно использовать? А если apache + nginx (вроде это ускоряет работу)?
Проблема в самом апаче. Он достаточно тяжеловесен сам, и грамотно настраивать его надо уметь. Правда, GitHub работает на Django, f нагрузки у них огого, может есть в интернете информация, как они этого добились —
M>>>>Ubuntu Server по умолчанию достаточно, чтобы начать, не особо забивая себе мозг M>>Для 100 000 человек в сутки и сотен миллионов записей все понадобится выделенный сервер, а там может быть и Убунту (у меня — Убунту). И нет, не сильно отличается. V>Когда арендуешь выделенку, ведь предоставляют ОС на выбор из списка? Хотя это к теме уже не очень относится.
Зависит, конечно, от хостера. На моем (iweb.com) — как раз в списке Ubuntu Server. Более того сейчас масшабные проекты часто выносят «в облака» (Amazon EC2, RackSpace и т.п.), где вопрос об операционке может не стоять — что хочешь, то и бери.
M>>Скопирую сюда требования: M>>
M>>Много людей будут пользоваться сервером одновременно, продолжительность сессии секунд может 5. (1)
M>>Периодически клиент будет отправлять на сервер небольшую информацию о себе. Это нужно будет заносить в базу, чтобы сервер был в курсе,
M>>что же там творит клиент. (2)
V>(1) Это генерация паролей по RSA, (2) а это как раз-таки данные, которые надо парсить M>>Непонятно, что с этой информацией дальше надо делать. Если периодически, небольшая информация, то может поставить ejabberd, к нему прикрутить/написать требуемые модули и не мучаться? V>Erlang для меня все равно, что Algol60 — слышал, но не видел.
К ejabberd'у не обязательно на Erlang'е писать, емнип
M>>Если это всего лишь логгер каких-то действий, то на среднем сервере с этим даже РНР справится. V>Не совсем, пользователь также может вносить изменения в свои настройки и соот надо их менять в его записи.
Ну, это тривиальная задача уровня UPDATE user_settings SET key=value WHERE user_id=1 AND key=k
M>>Если это онлайн игра (угадал?), то все равно справится РНР Хотя можно попробовать любой другой язык, который знаешь, который нравится или который можно быстро выучить. V>поэтому python + c++ — знаю и хочется попробовать
Тогда без проблем. Главное — точно уяснить что именно хочется. Написать для себя приблизительный workflow и dataflow, njuда многие вопросы отпадут сами собой.
V>Последний раз Mamut писал, что apache в пролете для высоко нагруженных серверов. V>И судя по отношению Mamut'a к php программистам, пишущих игрушки на flash, очевидно, Mamut прав
Yи того ни другого я не говорил и отношения не показывал
На глазах же умер Апач как только количество хитов (не посетителей, а хитов) достигло 40 000 в сутки. Реанимированию не поддался, nginx + php-cgi спаслли
V>Что есть другое: на wiki есть веб-серверы, оттуда узнаем про lighttpd, nginx (made in Russia).
Не забывай, что это надо прикручивать к питону, который не обязательно хорошо прикрутится
Здравствуйте, Mamut, Вы писали: V>>и на нем также будет сам сайт. M>А вот что за сайт, что он будет делать и т.п. — это уже совсем не мелочь.
Сайт просто что-то вроде о компании, соот регистрация и т.п.
Единственная динамика сайта (помимо красивостей)- это опять же панель пользователя со всеми настройками (здесь уже клиентская программа второстепенна). M>Зачем держать все в одной таблице, если те же настройки у одного клиента будут меняться может раз в год (как пример)? То, что в MongoDB нет таблиц в классическом понимании, не значит, что все надо пихать в один документ.
Это как просто пример. M>И вот здесь засада Какие данные, что с этими данными должен будет делать сервер? Потому что генерация ключа — это мелочь по сравнению с тем что может делать весь остальной сайт.
Данные это: либо настройки, либо что сделал юзер, либо что хочет юзер. Обработка этих данных значит — изменить что-то в записи юзера или узнать какую-то инфо
о другом юзере. M>Проблема в самом апаче. Он достаточно тяжеловесен сам, и грамотно настраивать его надо уметь. Правда, GitHub работает на Django, а нагрузки у них огого, может есть в интернете информация, как они этого добились —
Я вроде смотрел nginx и то, что к нему не сложно прикрутить python. (поддержим русского производителя, тем более, что по отзывам он популярен).
Просто кол-во юзеров, которые сидят на самом сайте скорее всего не будет большим, во всяком случае по идее.
Основная нагрузка будет только на слушание клиентских программ. Клиент может быть не только на официальном сайте,
возможно, он будет работать на другом сайте. M>К ejabberd'у не обязательно на Erlang'е писать, емнип
Я посмотрю подробнее, но не уверен, что лицензия подойдет. M>Ну, это тривиальная задача уровня UPDATE user_settings SET key=value WHERE user_id=1 AND key=k
Вот поэтому я и хочу mongo, задачи-то там нестрашные, а вот, что действительно может быть частым,
так это поиск юзера в базе с соот-ми свойствами. M>Тогда без проблем. Главное — точно уяснить что именно хочется. Написать для себя приблизительный workflow и dataflow, тогда многие вопросы отпадут сами собой.
Тут недостача знаний в области серверо-сайто-строительства, а так, все без проблем Поэтому такой ликбез по конфигурациям.
V>Я писал: V>Что есть другое: на wiki есть веб-серверы, оттуда узнаем про lighttpd, nginx (made in Russia). V>Оба для "крутых" серверов. Здесь неплохая статья по nginx: http://hlabs.spb.ru/development/nginx.html.
Если кто будет читать статьи, то смотрите на даты.
Здравствуйте, venicum, Вы писали:
v> порядка 100000 чел в с сутки, а то может и больше
При такой цифре посетителей в сутки, стоимости одного backend-а в ~2000 рублей и условии среднестатистического говнокода на PHP, затраты на аренду парка будут приблизительно 15-30КRUR/мес — это смешная цифра по сравнению с тем профитом, который будет получаться от такого количества уников. По этому тут легко справится и апач и php (уж про питон при грамотном приготовлении и речи не веду).
Другое дело, что большинство подобных проектов совершенно не адекватно (завышено) оценивают свою аудиторию.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, venicum, Вы писали:
v>> порядка 100000 чел в с сутки, а то может и больше
AB>При такой цифре посетителей в сутки, стоимости одного backend-а в ~2000 рублей и условии среднестатистического говнокода на PHP, затраты на аренду парка будут приблизительно 15-30КRUR/мес — это смешная цифра по сравнению с тем профитом, который будет получаться от такого количества уников. По этому тут легко справится и апач и php (уж про питон при грамотном приготовлении и речи не веду).
AB>Другое дело, что большинство подобных проектов совершенно не адекватно (завышено) оценивают свою аудиторию.
Здравствуйте, Mamut, Вы писали:
M>Так как прозвучала цифра 100 000 человек в сутки, Апач отпадает.
Сдаётся мне, ты просто не умеешь их готовить.
Сейчас вот зашёл на первую попавшуюся машину, не самую мощную, кстати — в acces_log'е на порядок больше записей. И idle редко когда ниже 70% опускается.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
M>>Так как прозвучала цифра 100 000 человек в сутки, Апач отпадает.
F> Сдаётся мне, ты просто не умеешь их готовить.
F>Сейчас вот зашёл на первую попавшуюся машину, не самую мощную, кстати — в acces_log'е на порядок больше записей. И idle редко когда ниже 70% опускается.
В access_log'eвсе равно будет на порядок больше записей Он туда пишет все, что ему не лень
Здравствуйте, Mamut, Вы писали:
F>>Сейчас вот зашёл на первую попавшуюся машину, не самую мощную, кстати — в acces_log'е на порядок больше записей. И idle редко когда ниже 70% опускается.
M>В access_log'eвсе равно будет на порядок больше записей Он туда пишет все, что ему не лень
Ну не скажи, там всего "что не лень" не больше половины, это я и не учитывал, кстати. Но остальное — то, что надо так что цифра в 1M для довольно нетривиальных действий — вполне себе честная.
На топовом железе и хорошем охлаждении можно и 10М с машики при желании получить.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
F>>>Сейчас вот зашёл на первую попавшуюся машину, не самую мощную, кстати — в acces_log'е на порядок больше записей. И idle редко когда ниже 70% опускается.
M>>В access_log'eвсе равно будет на порядок больше записей Он туда пишет все, что ему не лень
F>Ну не скажи, там всего "что не лень" не больше половины, это я и не учитывал, кстати. Но остальное — то, что надо так что цифра в 1M для довольно нетривиальных действий — вполне себе честная. F>На топовом железе и хорошем охлаждении можно и 10М с машики при желании получить.
В таком случае — да. У меня просто далеко не топовая, и апач ее клал на лопатки легко
Здравствуйте, Mamut, Вы писали:
M>У меня просто далеко не топовая, и апач ее клал на лопатки легко
Предположу, что всё-таки не апач, а какой-нибудь модуль или кривой скрипт. Я знаю несколько "честных" (т.е. без злого умысла) способов "положить машину на лопатки" при небольшой нагрузке.
Самый простой пример, небольшие утечки памяти -> внезапный своп -> машина стоит раком. Чуть более сложный пример — долгая инициализация воркеров при старте, когда слушащий сокет уже открыт, и родительский процесс активно штампует новых воркеров. Несколько секунд — и сервер может и не выйти из такого старта (при этом если нагрузку увеличивать с нуля плавно — то после старта всё может работать как часы). Ещё более сложный случай — когда у воркеров фиксированное время время жизни, а запросы они разбирают более-менее равномерно, и вот в какой-то момент они пачкой начинают помирать, а на их месте появляются новые — вкупе с долгой инициализацией это также легко может уложить машину (но проявляется это не всегда а при "неблагоприятных фазах луны"). В общем, примеров много. Надо только правильно их готовить
Курица — это инструмент, с помощью которого одно яйцо производит другие.
M>>У меня просто далеко не топовая, и апач ее клал на лопатки легко
F>Предположу, что всё-таки не апач, а какой-нибудь модуль или кривой скрипт. Я знаю несколько "честных" (т.е. без злого умысла) способов "положить машину на лопатки" при небольшой нагрузке. F>Самый простой пример, небольшие утечки памяти -> внезапный своп -> машина стоит раком. Чуть более сложный пример — долгая инициализация воркеров при старте, когда слушащий сокет уже открыт, и родительский процесс активно штампует новых воркеров. Несколько секунд — и сервер может и не выйти из такого старта (при этом если нагрузку увеличивать с нуля плавно — то после старта всё может работать как часы). Ещё более сложный случай — когда у воркеров фиксированное время время жизни, а запросы они разбирают более-менее равномерно, и вот в какой-то момент они пачкой начинают помирать, а на их месте появляются новые — вкупе с долгой инициализацией это также легко может уложить машину (но проявляется это не всегда а при "неблагоприятных фазах луны"). В общем, примеров много. Надо только правильно их готовить
Есть такая скотина, как Invision Power Board. Ее как ни готовь, все задница будет Переход Apache -> nginx+php-cgi вернул машину к жизни. Но может мне действительно мозгов не хватило для правильной настройки.
Хотя можно попробовать любой другой язык, который знаешь, который нравится или который можно быстро выучить.
Сдаётся мне, ты просто не умеешь их готовить.