Публикую базы клиентов через Apache (SSL, пользовательские сертификаты) уже достаточно давно, но массовый переход пока не осуществлял, так как это довольно много работы.
Сейчас возникла ситуация, когда RDP более не подходит . Сняли сервер на hezner, железо прекрасное, цена отличная, и надо бы переносить расчеты туда, но почему-то копирование файлов через RDP предельно ужасное, и при попытке что-нибудь скопировать RDP сессия просто вешается. Причины найти не можем всю голову сломали.

Если я на решусь на массовый переход публикацию через Web, то около 50 пользователей(а в дальнейшем больше) будут работать через Apache. Опасаюсь, что могу упереться в какую-нибудь особенность, которую сейчас предположить не могу.
(Как например использование нескольких процессов Apache в случае с публикацией в файловом режиме)

Буду пробовать 2 варианта, в первом Apache будет располагаться на Linux, во втором на винде. 1С сервер будет крутиться в любом случае на винде. Судя по обсуждениям здесь на форуме, нужно обязательно попробовать Apache 2.4. Буду пробовать 64-х разрядный апач (до этого всегда использовал 32х)

Есть ли опыт эксплуатации таких схем? Как то больше доверяю эмпирическому пути познания. Когда появится собственный опыт - обязательно выложу его тут.

Да. Совсем забыл указать свой опыт. Действующий сейчас мой вариант сделан очень топорно. В общем все компоненты стоят на Windows 2008 R2, том числе и Apache 2.2 (32-х битный).  
К каждой базе свой набор пользовательских сертификатов (самоподписанных). Лист отзывов не делал.
Тонкий клиент обновляется автоматически, через setuptc.zip.

Пока в этом режиме одновременно работают около 10-ти пользователей. Были жалобы, при работе через Йоту (высокие пинги около 500ms), жалобы прекратились после перехода на RDP на том же канале. Режим низкой скорости проблему не решил. При небольшом времени отклика - работа комфортная (но медленее, чем через RDP).

P.S. Схема если что указана только для публикации базы через интернет. Локальные схемы это совсем другая история.

несколько тупых вопросов. а почему не IIS? зачем пробовать 64х приложение, отъедается вся память? а если поднять несколько апачей по разным портам и разнести пользовталей по ним. У меня работают 70пользователей на самописке на БСП, IIS в одном инстансе и почти не конфигурировал его.

веб клиент априори тормознее рдп будетимхо. может попробовать взять тонкий, прописать путь http и включить режим медленного соединения?

(2) >> а почему не IIS
Может быть потому, что IIS под Linux не бывает?

(4) зачем на Windows 2008 R2 использовать апач?

(1) Может и IIS если он будет быстрее, чем Апач. Не конфигурил его никогда. С апачем я уже точно например знаю, что если мне понадобится добавить новую базу - мне не надо перезапускать сервис и тревожить работающих пользователей. В общем проблема в том, что я его никогда не пробовал.

Памяти при 10 пользователях на данный момент съел 30 Мб. Да, возможно 32/64 тут вообще не критично.

Несколько апачей конфигурировать вот ну никак не хочется. Естественно буду если делать будет больше нечего. Но вряд ли это необходимо если 1С серверная. (но не факт...)

(2) Забыл упомянуть, что речь не о веб клиенте а именно о тонком.

(0) При работе через веб-сервер в связке с сервером 1с фактически процесс веб-сервера не исполняет 1с-ный серверный код, а передаёт на сервер, так что неожиданностей тут вроде не возникает.
Разносить сервер 1с и веб-сервер на разные машины мне кажется не стоит - и настраивать геморнее, и работает чуть медленнее.
Ну и, как верно сказали, не вижу причин на винде предпочитать Apache встроенному IIS.
(3) Там речь про тонкий клиент, который получается тормознее RDP.
Вот это весьма и весьма странно и бывает скорее когда клиентский комп тормознутый совсем. В RDP локальной работы с диском фактически нет, например, а тонкий себе кэш конфы подгружает и дёргает его.

Базы фаловые или сервер 1С используется?

(8) О чем может говорить фраза "1С сервер будет крутиться в любом случае на винде. "?

(1) забыл спросить.70 юзверей это в через инет или локалку?
(7) Я так и думал по поводу, что в серверном режиме по идее приколов быть не должно. И с разносом тоже мысли, что при обновлении платформы придётся тянуть  ещё и дистрибутив 64/lin, что не комильфо.

И да... Был случай. Тонкий клиент работал медленнее, чем рдп. Клиентская машина бодрая, претензий к ней быть не может. Канал правда Yota c пингом 400-500... Тонкий клиент еле шевелился в том числе и с галочкой "низкая скорость" или как её там. При этом работа через RDP была комфортной. Для загадка что делать в этом случае(обновлять апач/платформу/молиться/пробовать IIS/выключать SSL).

(10) через локалку. еще как вариант сконфигурировать компрессию на веб-сервере не пробовали?

(10) Траффик надо замерять.
RDP должен больше генерировать, т.к. картинки передаёт, пусть и пожатые, сегментированные и оптимизированные.
Но вообще - зависит от конфигурации.
Если на клиенте выполнять поиск по таблице с 10000 строками, то траффика может нагенерироваться и много.

(11) хорошая идея. Вот накопал, что тонкий клиент поддерживает mod_deflate...  Вот кстати где это тоже было упомянуто: v8: 1С 8.2 тонкий клиент - медленная работа

(10) Конечно в итоге, если некуда будет деваться буду сидеть с каким-нибудь трафик анализатором... Конфа - торговля 11 только стандартный функционал... Я в этом не очень сильно разбираюсь, но возможно это связано с тем, что в случае с web клиентом, каждое действие - это отдельное tcp соединение, отдельный пакет new и так далее... а в случае с rdp это всё одно соединение и нет потерь на инициализацию новых.
Но из меня эксперт в этом вопросе не очень удачный.

P.S. Да... была как-то у меня конфа, где вместо дин списка оч. большая таблица, и этот элемент страшно тормозил, я из за этого как-то все новогодние каникулы просидел в серверной... а через буквально месяца 2 выпустили платформу, которая этот элемент через веб нормально отрисовывала...

(11) хотя у меня по-умолчанию в Режим: Веб-сервер (сжатие: усиленное)

(13) С чего ты взял, что tcp каждый раз новое создаётся?
В этом нет смысла, для описанной архитектуры тогда применялся бы протокол UDP.
В теории тонкий должен быть быстрее RDP.

Это предположение. Как работа в браузере - запрос - ответ (нет постоянного опроса)

На Апаче по 10000 пользователей работают норм (не 1С)
50 это не очем вообще. Те абсолютно, если только не файловая 1С

(17) В целом наверное так и есть.
(7) Про Web vs RDP
На данный момент у меня есть сервер, географически далеко размещённый. Пинг 150.
Я поочередно открывал реализации и поступления то там то там, чтобы  использовался кэш одних и тех же объектов. Записал на видео сравнение этих режимов http://screencast.com/t/TXZGYb1el , где видно что Web чуть проигрывает RDP (субъективно). Клиент не сильно слабее сервера.

Но проигрыш сходит на нет, когда отклик небольшой. При пинге в районе 10 на том же самом клиенте, та же самая база.
http://screencast.com/t/izRGvAlx02Du
При этом аппаратно местный сервер значительно слабее по всем характеристикам. И тот же самый клиент. Платформа чуть старее (8.3.7).

Среди баз есть одна, где большой оперативный журнал представлен в виде таблицызначений на форме, вместо дин. списка. Да, это неправильно и так далее, но в том случае полностью оправдано.
С этим объектом при пинге 150 мс работать невозможно вообще. При скроллинге приходится ждать по несколько секунд, в то время как на местном сервере эта таблица мотается плавно.

Да, на управляемых формах нечего делать большим таблицам значений и т.д. Но и на стандартной 11 торговле я наблюдал жуткие тормоза при пинге 450. Маршрут йоты видимо проходил из Владивостока во Владивосток через Москву. При этом на RDP та же база работала сносно.

В общем пока вывод такой(не смотря на шаткость качества исследования), что  качество работы тонкого клиента через web сервер стала зависит от времени отклика в куда большей степени, чем работа через RDP. Либо я где-то чего-то не настроил или не знаю/не понимаю.

(17) Интересно на это посмотреть.. Веб сервер все поступающие запросы ставит в очередь. Попробуй запустить сложный отчет или закрытие месяца и посмотри как это всех повесит. Хотя я не спец по веб серверам, может как то можно распаралелить.

(0) "Буду пробовать 64-х разрядный апач". Без шаманства wsapch2.dll не загрузится. А даже если и загрузится wsapch2.dll пока еще 32-х битный. Посему смысла в 64-х битном апаче нет.

(19) Судя по размеру занимаемой памяти апачу глубоко всё равно на отчеты. (в клиент-серверном режиме конечно). Он занимается передачей интерфейсных данных.
(20) Да. Желание использовать 64-разрядные версии всего канули в лету, когда не была обнаружена библиотека wsap24.dll соответствующей разрядности. По крайней мере в windows.

Интересует опыт использования через интернет в особенности с существенным временем отклика.

(0)>>> и надо бы переносить расчеты туда, но почему-то копирование файлов через RDP предельно ужасное, и при попытке что-нибудь скопировать RDP сессия просто вешается.

О чем идет речь? О копировании файлов с рабочего стола? Через буфер обмена?

последние полгода замечаю что при интенсивной работе апач под винду надо регулярно перезапускать..

дожирает оперативки и виснет, скотина такая..
причем как 2.2 х86 так и 2.4 х64 виснет..

такие дела...

(23)  ну и пользую я  и ряд моих клиентов "через интернет" в режиме "производственная база стоит дома у гендира в шкафу, весь офис работает с базой через тонкие клиенты и публикацию веб приложения через апач"

(21) Пишут, полечили https://bugboard.v8.1c.ru/error/000018408.html

(22) Речь о копировании на \\tsclient. Там долгая история, если коротко, то в один поток скорость от нас к серверу изумительная и упирается в нашу нищебродскую приморскую сторость, а в обратную сторону ужасная. Дело касается любого IP протокола. На RDP при просмотре своего диска С на терминале приходится ждать по пол минуты при листинге каждой папки. Копирование в нашу сторону в пределах 30 КБ/C Вроде как с Москвы такой проблемы нет.
(23) у меня в одном месте настроен файловый режим через Apache. Перезапускаю Apache каждую ночь регламентно. Если этого не делаю начинаются проблемы, причем довольно быстро. За клиент-серверным подобного не замечал.
(24) Сталкивались ли вы с клиентами, с большим временем отклика? От 150 мс. Если да, то наблюдали ли вы дискомфорт при работе? У вас Apache или IIS?
(25) Отлично, правда вряд ли дело в разрядности. Но тем не менее спасибо.

Буду пробовать на IIS. О результатах отпишусь.

IIS не пробовал, пока нет времени.
Попробовал 1cfresh через тонкий клиент. Проблема точно такая же - задержки при скроллинге дин. списка, при открытии документов с уже кэшированными формами. Причем база на фреше работает медленнее моей, вероятно потому, что моё оборудование не нагружено вообще.

Мои субъективные суждения подтвердились мнением бухов, недавно  перешедших на 1cfresh (тонкий клиент) (Скорость работ форм неудовлетворительная). Время отклика с Москвой у нас примерно 120 мс.

Из этого пока я делаю вывод, что комфортная работа через тонкий клиент через интернет (подключение без web сервера не рассматривается из соображений безопасности) при времени отклика 120 мс и более пока невозможна. И для себя консервирую идею арендовать сервер географически далеко расположенный под связку Тонкий клиент SSL Apache сервер.

Массовый перевод клиентов на 1cfresh тоже под большим вопросом. Попробую обратиться с поддержку и быть может у них есть дата центры поближе. А может пошлют меня и будут правы, так как объективных показателей я дать не могу, так как не смогу потратить на их добычу достаточное количество времени.

Ещё один интересный момент. Я упоминал, что есть у меня некая конфигурация, где огромный список представлен элементом ( не помню название самого элемента), производным от реквизита формы "ТаблицаЗначений", довольно большим.
С этим объектом, когда он в пределах 10 мс - удобно работать. При 150 мс, через тонкий клиент - с ним невозможно работать вообще, в отличие от динамического списка, который заставляет немного ждать при скроллинге.
Если запускать форму с таким объектом через web-клиент (через браузер) он работает просто прекрасно(при 150 мс), за исключением того, что в целом веб-клиент в целом работает медленнее тонкого.
Скроллинг этого объекта - плавный. Даже лучше, чем при 10мс в тонком клиенте.
Возможно в этом случае клиентская часть работает на сервере, не могу сказать точно, но судя по по размеру памяти браузера всё-таки на клиенте. Если это так - тогда получается проблема в тонком клиенте, раз веб может позволить себе мотать такой элемент плавно.