Отправлено: 20.12.06 10:50. Заголовок: Люди, вы здесь ваще бываете?
Видимо, хана клипперу. Ссылки на сайте битые, или буржуйские. Ничего не найти по SIX3: -что это такое, где взять, и стОит ли брать? Искал фак по xHarbo-ру - нигде! Спрашивал про модем тут, на форуме. Я, чтоли, тут первый такой шизанутый с такими вопросами? Люди - хелп!
использовании SIXa дело обстоит лучше, "предел усеров" отодвигается до 40-60. Но дальше опять. Прибавьте сюда то, что усеры ВСЕГДА будут завершать работу вашей проги некорректно (скажем, закрывать "крестиком" или вообще тушить комп кнопкой). Также учитывайте и то, что 220В в любой момент могут пропасть. Усеров лечить бесполезно. Электриков тоже. И на самом хорошем железе такая данные вашей проги всё равно будут рано или поздно "криветь". А причина тут простая: нельзя делать обработку на клиенте. Ненадёжно всё это слишком.
А я про, что говорю!!! Вот эти, то проблемы и лечит терминальная система работы. Возмите по-пробуйте. Что мешает?
Мне уже поздно что-то пробовать - слишком большая прога, слишком много усеров. Даже если в процессе тестирования не найду ни одной ошибки или трабла, это СОВЕРШЕННО не говорит о том, что когда будет реальная эксплуатация и все 120 усеров на неё навалятся, то также всё будет Ок. Скорее, наоборот. Потому что когда я тестировал SIX и затем, через год, АДС - тоже всё было гладко и спокойно. А когда началась реальная экспл-ция, колбасило несколько месяцев (АДС). Есть еще один момент: терминальная система работы предполагает ПОЛНОЕ отключение клиентских машин из вычислительной деятельности. Т.е. вся нагрузка по арифметике и работе со строками ляжет на хрупкие плечи сервера. А у меня в проге достаточно и арифметики и, особенно, операций со строками. Какие требования надо в таком случае предъявлять к серверу, чтобы усеры не видели задержек ? Какая у него должна быть память, диски, ЦПУ ? Имхо, совсем не такие как сейчас (будете смеяться, но до сих пор фурычит P-III/700/512; из общего объёма RAM только около 20Мб жрёт АДС).
ЗЫ. У нас в конторе есть терминальная прога (не на клиппере), на ней сидит около 60 человек. По недавнему признанию её автора, работа часто тормозится, особенно по утрам (в "часы пик"). Хотя сервак там нормальный, вроде бы.
2lista. И еще. Предположим, что в Вашей проге в результате некоторой АЛГОРИТМЕЧЕСКОЙ ошибки в БД в некоторых случаях могут попадать некорректные с т.зр. бизнес-логики данные. Например, отрицательные остатки по к-л позициям склада и т.п. Без использования транзакций Вы не сможете предотвратить появление таких данных и будете периодически руками их выкорчёвывать. Потому что понятия "откат изменений" в клипперной системе (даже самой терминальной на свете) - нет. И второй вопрос. Даже если у Вас абсолютно выверенная (в смысле отсутствия ошибок в алгоритмах) система, всё равно остаётся "человечий фактор". А именно: какому-нибудь усеру рано или поздно обязательно "покажется", что программа зависла. Хотя она работает, пишет данные (но данных этих много и при хорошей загрузке сервера обновления, отклик системы на экране и т.п. - идут не всегда с достаточной скоростью). По своему опыту знаю, что задержка в отклике свыше 3 секунд БУДЕТ провоцировать усера шлёпнуть по к-л клавише. И в конечном счете, обязательно случится, что какой-нить удод закроет Ваше приложение некорректным образом (снимет терминальную задачу). Если в этот момент прога выполняет ОДНУ операцию - тут всё Ок, сервер её должен сам "доделать". А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ?
А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ?
Может быть для товарных накладных написать свою эмуляцию транзакции? То есть сначала все данные записываются в какой-то временный файл. Затем по закрытию накладной или нажатию клаиши, что-то вроде "сохранить", данные из временного файла переписываются в основную базу данных. Тогда если программа "вылетела", то на диске сохраняется временный файл, и по этому событию можно судить, что транзакиця не выполнилась. И следовательно из базы данных нужно удалить те записи, которые уже успели туда попасть, а всю транзакцию пересохранить в базе данных заново.
И следовательно из базы данных нужно удалить те записи, которые уже успели туда попасть, а всю транзакцию пересохранить в базе данных заново.
Я знаю этот метод. И читал в Инете, что им пользуются (где-то в "историях успеха", перечисленных для АДСа на сайте их русского дистрибьютера - hotsoft.ru). Однако: 1) трудозатраты на переделку приложения будут при этом ТАКИМИ же, как если сразу переделывать под работу настоящих АДС-транзакций. Именно так ведь и происходит у меня: сначала запрашиваются ресурсы (добавляются строки, ставятся блокировки), затем объявляется BEGIN TRAN и строки, которые предназначены для записи, заполняются данными. В завершении -- COMMIT. Различие только в том, что я не пишу во времянки; всё - сразу в живые файлы. 2) всё равно надо написать "единую точку" входа данных в БД, в которой проверять соответствие данных времянки бизнес-правилам. И не только данных времянки! Ведь эти данные будут чатсо СКЛАДЫВАТЬСЯ с данными основных файлов (например, с остатками склада). След., проверять надо еще и БУДУЩИЙ РЕЗУЛЬТАТ, который возникнет в основных файлах. 3) время проверки для большого числа строк может составить 2-3 секунды. А может, и больше. Это достаточно, чтобы когда-нибудь "поймать" гадость типа сбоя 220В или (что у нас гораздо чаще бывает) зависания машины/сети/хаба. Потому что закон Мерфи никто не отменял: всё что только может произойти, произойдёт ОБЯЗАТЕЛЬНО, причём в самом худшем проявлении. И я на этот закон налетал десятки раз. 4) даже если сами данные нормальные, алгоритм ПРОВЕРКИ может сбойнуть, т.к. сам запросто может содержать к-л ошибку или неверное предположение. Потому что его тоже пишет живой проггер, а не автомат. В результате пп 3 и 4 - чистка БД руками. Иногда - с отрубанием усеров минут на 20 (а это плохо). Именно эти факторы меня окончательно "достали" и заставили всё переделать под TRN. О чём нисколько не жалею теперь.
И второй вопрос. Даже если у Вас абсолютно выверенная (в смысле отсутствия ошибок в алгоритмах) система, всё равно остаётся "человечий фактор". А именно: какому-нибудь усеру рано или поздно обязательно "покажется", что программа зависла. Хотя она работает, пишет данные (но данных этих много и при хорошей загрузке сервера обновления, отклик системы на экране и т.п. - идут не всегда с достаточной скоростью). По своему опыту знаю, что задержка в отклике свыше 3 секунд БУДЕТ провоцировать усера шлёпнуть по к-л клавише. И в конечном счете, обязательно случится, что какой-нить удод закроет Ваше приложение некорректным образом (снимет терминальную задачу). Если в этот момент прога выполняет ОДНУ операцию - тут всё Ок, сервер её должен сам "доделать". А вот если осталось еще МНОГО операций, т.е. целое "задание" на обработку, скажем, еще 200 строк товарной накладной, - тогда что ?
Я в свое время тоже задавал такой вопрос. Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой.
На 50 юзерах я не видел перекособоченных документов (шапка есть, строк нет или частично нет). Реальный опыт больше 2-х лет.
Мне уже поздно что-то пробовать - слишком большая прога, слишком много усеров. Даже если в процессе тестирования не найду ни одной ошибки или трабла, это СОВЕРШЕННО не говорит о том, что когда будет реальная эксплуатация и все
Ничего не позно. Куда я пришел было наверное тоже самое. Хотел задачу запусить под ДОСЭМУ самое простое, но задача не собралась в Рела-моде. Только в Протек-моде, в это режиме под ДОСЭМУ не удалось решить проблему сжирания процессора. Пересобрали задачу на Clip. Первый сервер был Целерон 2гГц и памяти 1Гб тормозило только когда запускали большие отчеты. Но и то равномерно у всех. На терминалах по-запускал все, что можно даже машины под чистым ДОС-ом. Скорость была таже, что на новом системном блоке - терминалы же.
p519446 пишет:
цитата:
Есть еще один момент: терминальная система работы предполагает ПОЛНОЕ отключение клиентских машин из вычислительной деятельности. Т.е. вся нагрузка по арифметике и работе со строками ляжет на хрупкие плечи сервера. А у меня в проге достаточно и арифметики и, особенно, операций со строками. Какие требования надо в таком случае предъявлять к серверу, чтобы усеры не видели задержек ? Какая у него должна быть память, диски, ЦПУ ? Имхо, совсем не такие как сейчас
Я не знаю задачи. Но на юзера нужно порядка 4Мб памяти+система - да и памяти никогда не бывает много, диски - сам можешь прикинуть (брал сказевы физические зеркала). Реально юзеров разделили: - те кто набирает (здесь самое критичное) - и те кто выборки делает (да и задачи у них написаны на Фокпро и доспуп в только в режиме чтения) По ЦПУ взяли 2-х процессорную машину с гипертрейдами, т.е. Линух видет 4 проца. Система сама распределает потоки (задачи).
Код почти не переделывали, был глюк с длинными транзакциями, т.е. запись держали долго. Переделали на короткую, все ОК. Уже перевели и три филиала на терминальную систему (была винда).
А перейти просто, можно даже частями. Собралась бы задача под Clip-оп.
Однако: 1) трудозатраты на переделку приложения будут при этом ТАКИМИ же, как если сразу переделывать под работу настоящих АДС-транзакций. Именно так ведь и происходит у меня: сначала запрашиваются ресурсы (добавляются строки, ставятся блокировки), затем объявляется BEGIN TRAN и строки, которые предназначены для записи, заполняются данными. В завершении -- COMMIT. Различие только в том, что я не пишу во времянки; всё - сразу в живые файлы.
Во-во! Так только в Клиппер появились множественные блокировки, я так и делаю. - добавляю и блокирую - записываю - разблокировка Только все это запускал сразу под ДОСЭМУ и затем под Клип-ом. Проблем с этим нет работает!
Как мне объяснили процесс (задача) будет работать до тех пор пока не встретит на своем пути inkey() (на inkey()-реализован весь ввод с клавы), запрос на ввод данных с терминала. И если этого терминала на другом конце уже нет (закрыли крестом, пропало 220, выдернули кабель...) то, тогда программа вывалится с ошибкой.
А теперь, внимание, вопрос: допустим, Вам надо обработать документ с 300 строками (скажем, применить к стоимостям скидку NN %). Вы его, если я правильно понял, сначала копируете во времянку, затем модифицируете её и далее - пишите из времянки в основной файл. Меня интересует именно последний этап: что будет, если при записи 300 строк (которая длится НЕ 0.00 сек, а немного больше) эту задачу "снять крестиком" ? Что сделает серверная ОС, на которой крутится всё это ? Доведёт до конца или нет ? Если нет, то что в результате будет с основным файлом, у него строки частично поменяются или всё откатится назад (как будто преобразований не было) ?
что будет, если при записи 300 строк (которая длится НЕ 0.00 сек, а немного больше) эту задачу "снять крестиком" ? Что сделает серверная ОС, на которой крутится всё это ? Доведёт до конца или нет ? Если нет, то что в результате будет с основным файлом, у него строки частично поменяются или всё откатится назад (как будто преобразований не было) ?
Если говорить о серверной оси Линух, операции обработки баз данных не требуют наличия "живого" терминала. Что от туда ждать программе? Т.е. программа доработает свои 300 строк, дойдет до inkey() и отвалится.
Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь)
Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь)
Ладно, тогда последний вопрос: если мне надо будет сделать такую связку у себя дома, то что, устанавливать Линух ? Или второй комп ставить ? (вопрос без иронии, просто интересуюсь)
- можно и вторую машину поставить с Линухом, больших ресурсов для портирования-разработки не нужно. - на своей же машине вторую ось поставить (как это сделать в Инете есть описалово) - wnware не пробовал - еще вариант - это Клип можно собрать запустить ч.з. Cygwin (но в боевой работе не пробовал)
Все даты в формате GMT
3 час. Хитов сегодня: 269
Права: смайлы да, картинки да, шрифты да, голосования нет
аватары да, автозамена ссылок вкл, премодерация откл, правка нет
- участник сейчас на форуме
- участник вне форума