|
ERP в WEB
|
|||
---|---|---|---|
#18+
wamacos_ustinovв лучшем случае, все основывается на субъективных оценках... так собственники, руководители, директора, инвесторы и т.д. и есть субъекты которые решают БЫТЬ или НЕ БЫТЬ! а не общественное мнение кучки специалистов рассуждающих на различных форумах о пользе или бесполезности того или иного внедрения. (в данном случае я имею ввиду и себя!) правильно но собственнику для принятия решения нужно получить исходные данные - сколько стоит, каков уровень надежности (что SLA обещает), комфортность для использования и, что характерно, собственникам не очень нравится опираться просто на субъективное мнение ИТ специалиста, что вот это - отстой, а это - круто собственникам комфортнее работать с цифрами, которые при желании можно и перепроверить - насколько точно посчитаны ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 11:18 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Chop, Проблема, что время ответа (от начала действия до окончания) для синхронных событий должно укладываться в 70 мс, для асинхронных в 200-400 мс (хотя тоже зависит от конкретных форм иногда меньше). А если учесть что вы recalculate style+layout+paint таблицы 40x20 вы физически за 50мс не выйдете, а еще есть scripting и ping... То есть все должно быть оптимизировано по самое не могу. Может конечно когда-нить подтянут R+L+P, а для javascript'а сделают нормальный JIT (пока даже у chrom'а это одно название), но пока так :( ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 11:29 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ДжекНепотрошительs_ustinovи стоимость электроенергии в год на сервера, персоналки, принтеры и прочее? Нет, стоимость электроэнергии на технику отдельно не считается, но это на ИТ-затраты относить и не совсем корректно. Это общие затраты компании, такие же, как аренда офисов и водопоставка. Тем более что стоимость электричества, которое потребляет серверная, в год у нас выходит в среднем $4000, чем вполне можно пренебречь ;) то есть на серверную вы все же посчитали? молодцы, это нечасто делают, к сожалению... а насчет пренебречь... часто у аудиторов граница существенности - 5% (верхняя планка) насколько знаю, никто не закладывает срок службы серверов меньше, чем 5 лет для расчета амортизации, а амортизация железа одна из основных статей расхода - обычно не меньше 30-40% то есть чтобы пренебречь этой суммой, у вас железа в серверной должно быть больше чем 4000($)/5(%)*35(%)*5(лет)=140'000 и тогда возникает подозрение - или вы закупаете железо по завышенным ценам, или оно у вас совсем мало работает, или неточно посчитали потребление энергии - столько железа (на такую сумму) обычно потребляют в год больше электричества или пренебрегать затратами на электроенергию все же нельзя и электроенергия на персоналки вообще то относится к ИТ затратам фактически правильнее считать - а сколько компания тратит на то, чтобы человек работал с программами ведь тот же тонкий клиент по потреблению электричества в несколько раз экономнее стандартной персоналки - и за год получается неплохая часть стоимости ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 11:39 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Nitro_JunkieChop, Проблема, что время ответа ... Может конечно когда-нить подтянут R+L+P, а для javascript'а сделают нормальный JIT... то, что время жизни php-скрипта ограничено, да и браузер может обломаться ждать ответа от сервера - это таки да время жизни php-скрипта можно увеличить, с браузером особо не поспоришь ограничение на время ответа в вебе пока не обойдешь JIT для яваскрипта... это если совсем уж толстого клиента писать со сложной бизнес-логикой... по юзабельности же jQuery, ExtJS, Flex и прочая, и прочая уже сейчас позволяют создавать "почти-десктопные" приложения, ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 11:44 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ДжекНепотрошительДля каждого документа есть какой-то ответственный за него сотрудник. Если ERP нет, все равно логист получает акты выполненных работ от ТК, и подает их в бухгалтерию на оплату, а учетчик сервисного отдела делает акты списания материалов для обслуживания оборудования. Сейчас они делают ту же самую работу, только проводят их в NAV. проблема обычно именно в правильном распределении затрат. то есть сумму расходов в целом по предприятию посчитать можно без проблем, а распределить по видам - уже надо прикладывать усилия. та же амортизация серверов - оно вроде и несложно в том же навике настроить, чтобы амортизация разносилась со всеми аналитиками (измерениями), но почему-то это очень часто не делают ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 12:10 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ChopNitro_JunkieChop, Проблема, что время ответа ... Может конечно когда-нить подтянут R+L+P, а для javascript'а сделают нормальный JIT... то, что время жизни php-скрипта ограничено, да и браузер может обломаться ждать ответа от сервера - это таки да время жизни php-скрипта можно увеличить, с браузером особо не поспоришь ограничение на время ответа в вебе пока не обойдешь JIT для яваскрипта... это если совсем уж толстого клиента писать со сложной бизнес-логикой... по юзабельности же jQuery, ExtJS, Flex и прочая, и прочая уже сейчас позволяют создавать "почти-десктопные" приложения, Причем тут php-скрипт? С сервером то все как раз хорошо, пишите его на чем-нить компилируемом типа C++ или лучше с JIT (Java, C#) и будет вам счастье. Вопрос с клиентом, а вот тут тормозит все (по сравнению с JIT средой и "native" интерфейсам (swing'ом, WPF, да уж Дельфи на худой конец :) )), причем очень и очень существенно (даже на pc, про мобильные я вообще), но это я уже повторяюсь. И речь даже не о сложной бизнес-логике, даже на 1С УТ (где каждый конкретный пользовательский интерфейс весьма элементарен) вон какие проблемы с вебом. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 12:41 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Nitro_JunkieВопрос с клиентом, а вот тут тормозит все (по сравнению с JIT средой и "native" интерфейсам (swing'ом, WPF, да уж Дельфи на худой конец :) )), причем очень и очень существенно (даже на pc, про мобильные я вообще), но это я уже повторяюсь. И речь даже не о сложной бизнес-логике, даже на 1С УТ (где каждый конкретный пользовательский интерфейс весьма элементарен) вон какие проблемы с вебом.так вы о клиенте? если сложной бизнес-логики нет, какого-то анализа громадного количества данных, то ничего не тормозит... :) веб-интерфейс от 1С видел только на картинках время ответа сервера зачастую существенно больше, чем отображение/обработка полученных данных в браузере зы. ЕРП на мобилах - полный изврат :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 12:50 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Chop, А вы попробуйте сгенерить (javascript'ом к примеру) и отрендерить таблицу на клиенте 40x20, увидите что быстрее чем за 50-100 мс вы этого не сделаете. То есть в супер идеальном случае (чистый javascript, никаких стилей и т.п.) может и сделаете, но даже в minimum viable - нет. Я в свое время над этим очень долго работал, и когда даже в идеальном случае получил около 40мс, понял что это к сожалению и есть essential complexity. То есть веб сделать можно и даже нужно, но на интенсивном вводе нужны очень психически устойчивые пользователи (которых едва уловимые задержки не доведут до невроза :) ) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 13:13 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Nitro_JunkieChop, А вы попробуйте сгенерить (javascript'ом к примеру) и отрендерить таблицу на клиенте 40x20, увидите что быстрее чем за 50-100 мс вы этого не сделаете. То есть в супер идеальном случае (чистый javascript, никаких стилей и т.п.) может и сделаете, но даже в minimum viable - нет. Я в свое время над этим очень долго работал, и когда даже в идеальном случае получил около 40мс, понял что это к сожалению и есть essential complexity. То есть веб сделать можно и даже нужно, но на интенсивном вводе нужны очень психически устойчивые пользователи (которых едва уловимые задержки не доведут до невроза :) ) только что в phpMyAdmin отработал простой запрос на выборку 500 первых записей (30 полей) запрос занял 0.0036 сек. ответа сервера ждал 5.6 сек. и это - на элементарном запросе, а если сам запрос выполняется несколько минут? по вашему в этой ситуации есть существенная разница за 0.05 сек или 0.1 сек отрисуется таблица? на интенсивном вводе обновлять таблицу при редактировании каждой ячейки - какой смысл? асинхронно обновляйте одну ячейку грида, или строку/запись, если не хочется лишний раз дергать сервер либо же если это, например, ввод приходной накладной, то там в процессе ввода вообще ничего обновлять не надо, пусть пользователь заполнит весь документ, а потом только отсылайте/обновляйте пысы. даже не знаю как измерить время рендеринга таблицы/страницы :( не подскажите? есть какие-то утилиты или писать свой код? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 13:58 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Скорость рендеринга больших таблиц существенно зависит от браузера. Но справедливо сказано, что рендерить нужно как правило то, что реально отображено на экране. Логика десктопа, когда запрашивается вся таблица - это не совсем путь веба. В конце концов то что реально может видеть пользователь на экране - так это около 10 Кбайт информации - и то лучше меньше. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 19:24 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Chopи это - на элементарном запросе, а если сам запрос выполняется несколько минут? Мы говорим про ERP. Если на OLTP-базе есть запрос, который выполняется несколько минут, и это не отчет какой-нибудь, то разработчик данной системы просто обязан выброситься в окно с верхних этажей. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2013, 22:41 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ShuhardДжекНепотрошитель А раз спроса на веб-интерфейс нет, то и вкладываться в его разработку производители ERP особо не спешат в 1С УП 2.0 все три интерфейса, толстый, тонкий и веб идентичны в 1с нет web интерфейса. Запуск обычного приложения через web браузер - это не веб приложение. Не надо вводить людей в заблуждение. С таким "web интерфейсом" работать невозможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 10:30 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
popov19Shuhardпропущено... в 1С УП 2.0 все три интерфейса, толстый, тонкий и веб идентичны в 1с нет web интерфейса. Запуск обычного приложения через web браузер - это не веб приложение . Не надо вводить людей в заблуждение. С таким "web интерфейсом" работать невозможно. угу невозможно пока в серьезных масштабах а вот выделенное хотелось бы чтобы было развернуто подробнее что имеется ввиду под этим ? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 12:03 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
В 1с 8.х начиная с какого-то релиза появилась возможность работать из браузера по протоколу http с сервером. Называется ли это веб-интерфейсом? Если веб-клиент работает через веб-сервер с сервером приложений. Удобно ли это (пользователю)? - Не совсем. Т.к. 1 с пошло по пути полного воспроизведения интерфейса толстого клиента средствами веб-браузера. И реально в толстом клиенте работать удобнее. Но это не означает что любое приложение из браузера ьенее удобно чем десктоп. Я разрабатываю веб-интерфейсы для работы в режиме ввода большого количества информации (почти операторского ввода информации) во внутрикорпоративных системах. И практически все пользователи отмечают более комфортную работу, чем со стандартными интерфейсами десктоп-приложений. Тут весь вопрос в том, задается ли разработчик такой целью - обеспечить удобство работы пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 12:37 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
apapacyЯ разрабатываю веб-интерфейсы для работы в режиме ввода большого количества информации (почти операторского ввода информации) во внутрикорпоративных системах. И практически все пользователи отмечают более комфортную работу, чем со стандартными интерфейсами десктоп-приложений. Я могу на любой священной книге поклясться, что никакой веб-интерфейс никогда и ни за что не позволит сделать более комфортную работу, чем интерфейс десктоп-приложения при прочих равных условиях . Из-за двух аксиом: 1. При одинаковой производительности компьютера время реакции правильно спроектированного веб-интерфейса всегда больше, чем правильно спроектированного десктопного интерфейса. 2. Элементы управления веб-интерфейса представляют собой подмножество элементов управления десктопного интерфейса. Т.е. если пользователи говорят, что "веб-интерфейс лучше, чем десктоп", это всего лишь означает, что у них раньше был плохой десктоп, а не потому, что им так нравится работать в броузере :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 18:27 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
В одном я с Вами согласен. До этого и после этого им приходилось работать с галимыми десктопами. От стандартной палитры Делфей до Аксапты. И тут мы приходим к вывдоу о том, что на хрен, ни десктоп сам по себе, ни веб-интерфейс сам по себе не является гарантией или преимуществом при создании хорошего интерфейса. Что касается Ваших конкретных доводов о скорости отклика приложения - тут все если, если. Если правильно, если неправильно. Боюсь что правильно спроектированный десктоп-интерфейс и веб-интерфейс дадут равные показатели. Касательно многообразия десктоп по сравнению с веб. Так это что с чем сравнивать. Стандартную палитру Нет или Делфей с HTML4. А если с HTML5? Java.Swing? Давайте сначала отметим тот факт, что можно ваять хорошие и плохие интерфейсы на десктоп и на веб. Теперь отметим преимущества веб-интерфейсов. 1) Как это не странно, многим пользвоателям наравится, что в любой момент они могут закрыть браузер не отвечая на десяток модальных диалогов типа "Сохранить документ - Да/Нет" "Вы действительно хотите выйти - Да/Нет" "Вы осознаете всю тяжесть последствий закрытия непроведенного документа - Ок" "Возвратить точку актуальности на начало проведения документа без записи проводок - Да/Нет/Затрудняюсь ответить". 2) Документоориентированность интерфейса - то что пользователь видит на экране привычный уютный документ создает у него ощущение уверенности в своих действиях, в сравнении с десктоп-контролом. Кроме того, документ-приложение я обычно снабжаю большим количеством вспомогательной информации для пользвателя. Напр. не просто кнопка Ок а та же кнопка Ок с письменной инструкцией как ей пользоваться - как на огнетушителе - чего я редко наблюдаю в десктоп-интерфейсах. 3) И о многобразии. Если м имеем дело с текстовой информацией - то любой мыслимый контрол это тот же текст в рамочке - и я его могу с легкостью создать, а пользователь воспользоваться.1 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 20:25 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
apapacyеперь отметим преимущества веб-интерфейсов. 1) Как это не странно, многим пользвоателям наравится, что в любой момент они могут закрыть браузер не отвечая на десяток модальных диалогов типа "Сохранить документ - Да/Нет" "Вы действительно хотите выйти - Да/Нет" "Вы осознаете всю тяжесть последствий закрытия непроведенного документа - Ок" "Возвратить точку актуальности на начало проведения документа без записи проводок - Да/Нет/Затрудняюсь ответить". 2) Документоориентированность интерфейса - то что пользователь видит на экране привычный уютный документ создает у него ощущение уверенности в своих действиях, в сравнении с десктоп-контролом. Кроме того, документ-приложение я обычно снабжаю большим количеством вспомогательной информации для пользвателя. Напр. не просто кнопка Ок а та же кнопка Ок с письменной инструкцией как ей пользоваться - как на огнетушителе - чего я редко наблюдаю в десктоп-интерфейсах. 3) И о многобразии. Если м имеем дело с текстовой информацией - то любой мыслимый контрол это тот же текст в рамочке - и я его могу с легкостью создать, а пользователь воспользоваться.1 Вы отметили не преимущества веб-интерфейса, а определенные сценарии интерфейса в принципе, которые по вашим наблюдениям не нравятся пользователям. Но тоже самое делается на десктопе. Разница только в методах построения интерфейса. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 21:09 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Ну, положим, документоориентированность - это не сценарий а как раз наиболее существенный признак веб-интерфейса, если он не пытается подделываться под десктоп. Что касается сценариев - да сценарий таков, что общение с сервером похож на обмен пушечным ядрами. То ест большую часть времени пользователь как бы оффлайн. И вынужден действовать запросами (пусть даже асинхронными). Но в этом проявляется другой существенный признак уже всего веб-приложения. Можно ли так строить десктоп-приложение - можно. Но в большинстве случаев разработчик десктопа как можно скорее ваяет спасительный датагрид/BROWSE - который редактирует данные по месту и действует на свое усмотрение как хвост Свирепого Бамбра. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 21:28 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
apapacyБоюсь что правильно спроектированный десктоп-интерфейс и веб-интерфейс дадут равные показатели. Никоим образом. Средства построения веб-интерфейсов не позволяют. В случае десктопа это будет нативный код. В случае веб-приложений это будет медленный AJAX/HTML5 и среда выполнения броузера. Можно "за уши" к веб-приложениям притянуть еще SL и Java-апплеты, хотя формально они веб-приложениями и не являются, но и в данном случае разница в производительности имеет место быть. apapacy1) Как это не странно, многим пользвоателям наравится, что в любой момент они могут закрыть браузер не отвечая на десяток модальных диалогов типа "Сохранить документ - Да/Нет" "Вы действительно хотите выйти - Да/Нет" "Вы осознаете всю тяжесть последствий закрытия непроведенного документа - Ок" "Возвратить точку актуальности на начало проведения документа без записи проводок - Да/Нет/Затрудняюсь ответить". Это не преимущество веб-интерфейса. Если правила работы с приложением допускают такую модель его закрытия, то можно сделать это и на десктопе, кто ж запрещает? С другой стороны, раз окно "вы действительно должны хотите выйти" делают модальным, это ведь сделано для того, чтобы пользователь потом не рыдал над потерянным документом, верно? apapacy2) Документоориентированность интерфейса - то что пользователь видит на экране привычный уютный документ создает у него ощущение уверенности в своих действиях, в сравнении с десктоп-контролом. И это не преимущество веб-интерфейса. Если правила работы с приложением предполагают работу с документом WYSIWYG, кто ж мешает делать это на десктопе? Наоборот, там это вообще естественная фича, в то время как на вебе это стало более-менее реальным только сейчас, с HTML5. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 21:32 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
Ладно хрен с ней со скоростью. Где-то читал, что в некоторые приложения для комфорта работы с пользователем используют (во всяком случае психологи рекомендуют использовать) замедлители интерфейса. Что бы пользователь успевал уследить что собственно там происходит на компьютере. Правда нашего неизбежного ператора с охапкой накладных это должно раздражать. Но все же не в скорости счастье. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 22:18 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
apapacyПравда нашего неизбежного ператора с охапкой накладных это должно раздражать. Но все же не в скорости счастье. Наши сотрудники филиалов, которые сидят по регионам с MS CRM на ноутах, могут убедительно рассказать, почему счастье именно в скорости :) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 22:30 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
apapacyНу, положим, документоориентированность - это не сценарий а как раз наиболее существенный признак веб-интерфейса, если он не пытается подделываться под десктоп. Что касается сценариев - да сценарий таков, что общение с сервером похож на обмен пушечным ядрами. То ест большую часть времени пользователь как бы оффлайн. И вынужден действовать запросами (пусть даже асинхронными). Но в этом проявляется другой существенный признак уже всего веб-приложения. Можно ли так строить десктоп-приложение - можно. Но в большинстве случаев разработчик десктопа как можно скорее ваяет спасительный датагрид/BROWSE - который редактирует данные по месту и действует на свое усмотрение как хвост Свирепого Бамбра. все делается точно так же. Различие только в том, что у веб-приложения формированием интерфейса занимается веб-браузер, на основании контента, полученного от веб-сервера. У десктопного приложения с тонким клиентом этим занимается тоже а-ля браузер (тонкий клиент), на основании контента, полученного от сервера приложений. Большую часть времени пользователь оффлайн и обменивается с сервером "пушечными ядрами", как вы это назвали. Все зависит не от того что это десктопное или веб-приложение, а от того каким образом оно устроено. Вы правы в том, что веб приложение просто не предлагает других вариантов решения, поэтому построить систему, которая будет редактировать данные "по месту" просто затруднительно, по причине отсутствия доступа к этому месту. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.06.2013, 23:52 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ДжекНепотрошительСредства построения веб-интерфейсов не позволяют. В случае десктопа это будет нативный код. В случае веб-приложений это будет медленный AJAX/HTML5 и среда выполнения броузера. Можно "за уши" к веб-приложениям притянуть еще SL и Java-апплеты, хотя формально они веб-приложениями и не являются, но и в данном случае разница в производительности имеет место быть. лет 20 назад люди умудрялись строить достаточно удобные и быстрые интерфейсы. причем тогда у них доступные вычислительные мощности на целевых машинах были в несколько раз меньше , чем " медленный AJAX/HTML5 и среда выполнения броузера" - тогда еще вовсю пользовались 286ми. так что рассказывать, что мощности железа не хватает для быстрой работы интерфейса - это чистой воды отмазки людей, не умеющих или программировать, или проектировать итерфейсы, или и то и другое. единственный существенный недостаток веб интерфейса - менее стабильный канал передачи данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2013, 00:10 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
s_ustinovлет 20 назад люди умудрялись строить достаточно удобные и быстрые интерфейсы. причем тогда у них доступные вычислительные мощности на целевых машинах были в несколько раз меньше , чем " медленный AJAX/HTML5 и среда выполнения броузера" - тогда еще вовсю пользовались 286ми. Готов поспорить, производительность 286-го в текстовом режиме будет выше, чем производительность JavaScript в современном броузере на современном компьютере. Так что замечание явно не по адресу. У моего телефона вычислительная мощь раз в тысячу больше, чем "двойки". Но при этом возможности программного обеспечения даже хуже, чем у древней IBM PC, ну разве что MP3 да видюшки обрабатывать умеет, на это PC не хватит. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2013, 00:46 |
|
ERP в WEB
|
|||
---|---|---|---|
#18+
ДжекНепотрошительГотов поспорить, производительность 286-го в текстовом режиме будет выше, чем производительность JavaScript в современном броузере на современном компьютере. Так что замечание явно не по адресу. У моего телефона вычислительная мощь раз в тысячу больше, чем "двойки". Но при этом возможности программного обеспечения даже хуже, чем у древней IBM PC, ну разве что MP3 да видюшки обрабатывать умеет, на это PC не хватит. насколько я себе представляю, из JavaScript можно выкинуть все графические возможности (не использовать их) - и внутри браузера сделать "дос окошко"... вы утверждаете, что при таком режиме работы скорость у современного компа будет меньше? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2013, 01:25 |
|
|
start [/forum/topic.php?fid=29&msg=38291222&tid=1526007]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
158ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 284ms |
0 / 0 |