Re: контейнеры
В сообщении от Wednesday 09 January 2008 02:22:54 Michael Shigorin написал(а):
> On Fri, Dec 28, 2007 at 08:27:14PM +0300, Alexey Pechnikov wrote:
> > При проектировании обеих систем я не нашел ничего подходящего,
> > что имеет высокую производительность (поддержка не менее 50-100
> > одновременных пользователей на сервере целерон 2,6 ГГц с гигом
> > оперативки и SATA жестким диском)
>
> FYI в ТЗ видно сходу три изъяна по железу: процессор, память
> и количество дисков.
>
> Celeron -- это не процессоры, а недоразумение. Гиг оперативки
> при дешёвом диске -- это экономия на кэше. А один диск -- это
> перегрузка и недостраховка, если вообще хоть что-то происходит
> и что-то надо хранить.
>
> Сейчас дешёвый сервер -- это Athlon64 X2, от пары гиг оперативки
> (которые стоят чуть ли не дешевле того целерона) и _два_ хотя бы
> винта. Где как минимум система и важные данные лежат на softRAID1.
У меня рабочий сервер pentium D 2.8 GHz, 2 Gb RAM, soft RAID 1. Но для
минимальных требований этого слишком много, так что тестовый сервер как
указан ранее. А постгрес в свое время тестировал с прототипом БД на ARM 266
MHz+32 Mb RAM и нашел несколько "узких мест". Если вы назовете проекты, в
которых проведена подобная работа, буду рад расширить свой кругозор.
>
> > написано на функциональном языке (тикль, лисп, erlang, etc.),
>
> Ой, тикль уже функциональный... надо же. И сваливание в кучу
> тоже радует. Или это описание разведённого зоопарка?
Тикль уже почти функциональный, кое-что не реализовано, но мне жить не мешает.
В кучу не сваливал, просто это список языков, на которых имхо резонно делать
задуманное. Кстати, первые версии разрабатывались на перле, но на тикле
оказалось существенно удобнее. Конечно, этот выбор в значительной мере вопрос
личных предпочтений, но для нас важно то, что на тикле объем кода в три раза
меньше, чем на перле и в десять раз меньше, чем на С++ (может, у кого-то
наоборот? интересно будет узнать об этом).
>
> > "заточено" на работу с PostgreSQL
>
> Вы если наслушались про ФП -- может, ещё про иерархические или
> фреймовые БД где наслушаетесь? ;-)
Каждый день пользуюсь файловой системой ext3. Иерархическая, аж жуть. И вовсе
не вижу резона хранить все данные в реляционной БД.
> > имеет устраивающую меня модель безопасности, умеет работать с
> > веб-камерами на виндовых ПК любой версии, с камерами на КПК и
> > смартфонах, умеет работать с КПК и смартфонами с виндоус-хоста
> > путем выполнения сценария, имеет написанный на функциональном
> > языке клиент для КПК и смартфонов и проч.
>
> Хм, что-то не помню Вас в synce-devel@, ну да ладно.
> Виндовс-хост так виндовс-хост.
synce работает только со старыми версиями винмобайл, увы (и при существующей
стабильности имеет смысл только под линуксом). Так что использую ffidl,
успешно работает с rapi.dll из активсинка версий 4.1, 4.2, 4.5. Знаю, что
аналог ffidl есть, например, в питоне, но по ряду причин не считаю
его "промышленно пригодным" (посмотрел синтаксис, попробовал, впечатление
такое, что даже для "домашних" утилит использовать не стану).
>
> > Далее, для документооборота решил применить аналогию из
> > квантовой механики - проквантовать допустимые состояния
> > документов и описать правила их изменения. Подобного проекта я
> > также не нашел (независимо от требований выше). Почему-то все
> > описания сводятся к рекламным заявлениям и некоторым интересным
> > идеям, но мат. или физ. модели разработчики делать не
> > удосуживаются.
>
> Хотя бы тот же NauDoc из близлежащего уже посмотрели?
У них ограничение на несколько тысяч документов _в год_. У меня нагрузка
такого порядка _в день_. Я ведь не зря говорил про железо и количество
поддерживаемых пользователей. У NauDoc и других подобных систем довольно
широкие возможности, но низкая эффективность. Плюс возможны проблемы с
транзакционностью состояний документов - например, при выполнении одной из
операций над документом должны быть разосланы сообщения заинтересованным
пользователям, сохранена запись о произведенном изменении и т.п. и все это в
одной транзакции. Таким образом, вся логика должна быть реализована в БД,
чего я не нашел ни в одной из открытых систем (можно, конечно, делать на
прикладном уровне, но поддержка в этом случае значительно усложнится).
Думаю, у меня довольно типичные требования к системе документооборота, ничего
сверхестественного. Позвольте вопрос - хоть одну из открытых систем
документоборота вы сами стали бы использовать хотя бы для 1000 пользователей?
Думаю, что нет.
>
> > Итак, было принято решение делать "с нуля". Это было мое личное
> > решение, не будем его обсуждать, достаточно того, что созданная
> > система успешно работает в нескольких десятках регионов.
>
> Ну мне лично таких доводов недостаточно -- зная недостатки наших
> систем, работающих в нескольких десятках регионов... и той же
> винды, работающей по всему миру.
Ну конечно, мне бы этого тоже было недостаточно :-) Я имел в виду, что
поставленная передо мной задача решена.
> > Опен-сорс проект делать у меня нет свободных ресурсов -
> > трудозатраты огромные, а кому оно надо...
>
> Надо-надо.
>
> Трудозатраты огромные, если планировать не уметь совсем,
> а взаимодействовать -- совершенно. Иначе зачастую уже не
> полвелосипеда изобретено, а большая часть.
>
> Иначе они _могут_ быть и не огромными по сравнению с "пилим
> всё сами".
Возможно. Несколько раз пробовал делать открытые проекты, интереса к ним мало.
Например, в блоге по ГИС и навигации уже выкинул все исходники, поскольку
никто их и не смотрит (перл, питон, тикль). А геоинформатика как дисциплина
на порядки важнее, чем система документооборота (первое - фундаментальный
подход к миру, последнее - просто одна из прикладных задач, их вообще
сравнивать нельзя).
>
> > Кое-что публикую в своем блоге по постгресу, но постгресом мало
> > кто пользуется всерьез.
>
> Разумеется. Все так, поверхностно. Ну подумаешь, подпилили
> в LTC, ну что вы, право.
И много таких "пилителей" - единицы, десятки? И какое отношение это имеет
к "пользоваться"?
> > Также мало кто готов изучить новый язык/технологии
> > (postgresql+pltcl + tcl + aolserver+sqlite).
>
> AOL-то каким боком очутился?
Сервер приложений для tcl. Через CGI много не наработаешь.
> > Потому и открытое сообщество в рунете остановилось на уровне
> > "как настроить апач"
>
> Ой, не смешите мои тапочки.
>
> > в то время как во всем мире создаются и успешно развиваются
> > прекрасные открытые проекты.
>
> И в рунете создаются да успешно развиваются. Просто места знать
> надо, как обычно. (ну да сейчас меня опять за рекламу погонють ;)
Думаю, что рунет-сообщество там и остановилось. Как всегда в россии, есть
талантливые одиночки, но им есть чем заняться и без моих проектов.
Reply to: