Доброго вечера!
Впервые довелось столкнуться с базами, опубликованными в web. Очень долго запускается, хоть через браузер, хоть через клиента на удаленных компах.
Базы 1С УТ 11 и БП 3, релизы относительно не заросшие еще мхом (последнее обновление перед новым годом), на компе, где хранятся базы, переустановлена ОС на windows 10 pro, антивирус пока отключен, запущен апачи. На удаленных компах загружается 5-15-30 минут (дольше не хватало терпения), после загрузки работать почти невозможно. Проблема возникла до обновлений, до переустановки ОС, точного момента, когда все стало тормозить и какого-то события, повлекшего это, клиент назвать не может. Со слов клиента, когда-то уже была у них подобная проблема, сделали свертку, после свертки какое-то время все было очень шустро.
Размер УТ 1С.cd 2,8Гб, вся папка весит 3,93. БП 2,1 Гб.
Платформа 8.3.18.1289 x-64.
apache_2.4.23-x64-openssl-1.0.2h (были опробованы и др версии)
Комп, на котором размещены базы: AMD Ryzen 3 2200G 3.50 GHz, 8 Гб, ssd.
Предполагаю, что дело все-таки в неправильной настройке апачи...Хочу попробовать демо-базу опубликовать, не кажутся мне базы огромными.
Подскажите, пожалуйста, в чем может быть дело, что посмотреть?

"8 Гб" имхо вот тут затык

(1) - благодарю! посоветуйте, пожалуйста, сколько, по вашему опыту, будет достаточно?
провести эксперимент с добавлением оперативки в ближайшие дни, к сожалению, нет возможности.
перенести на более мощный комп базу на тест - нет белого ip((

есть ли еще что-то, что может быть причиной такой медленной работы через web?...

(2) >>есть ли еще что-то..
диалап (ну т.е. медленная сеть)

(2) "тест - нет белого ip" стартаните тонкий через публикацию локально
(3) +1

(3),(4) - благодарю!
(4) - имеете ввиду, запустить на др компе в локальной сети эту базу, прописав путь через web? или же перенести базу на др комп в этой же локальной сети и поднять апачи там?
пробовала оба варианта, тормоза жуткие, второй комп, правда, там мало чем отличается по характеристикам.

(4) - в дополнение к (5) -  нет более мощного компа в организации, всего 2 - на котором база сейчас и примерно такой же второй, на который пробовала перенести базу и  опубликовать с него (те же тормоза)

(0) А что показывают команды Ping и traceroute с клиентских тачек на веб-сервер? может у вас там что-то с сетью?

(7) - вечером смогу выложить

Если ничего не публиковать, остановить Апач и зайти в базу толстым/тонким клиентом, на этом компьютере локально, так же невозможно тормозит? Тест Гилева что показывает? Режим высокой/максимальной производительность В Windows установлен?
SSD начал портиться, может быть.

(9) - спасибо за отклик!
      если заходить в базу обычным способом, без публикации, то и на компе, где база расположена, и на компе, который по локальной сети подключен, работает вполне сносно(если сравнивать с попыткой подключиться по web, то просто летает на сверхзвуковых скоростях, ну а так - средней паршивости).
      Подскажите, какой прогой пользуетесь для теста SSD? Смотрела  Victoria 5.35 smart, полностью зеленый, зажелтел только на температуре 30 гр (что, думаю, вполне нормально?). Что-то еще запускала, но тоже из-под винды, доверия особо нет к результатам.
      Пробовала публиковать базу с соседнего компа, различий не заметила.
      На остальные вопросы постараюсь сегодня или завтра ответить, подключусь к ним.

(9) - было еще подозрение, что вирус что-то пожрал, потому поставила новую на чистый раздел, до установки антивиря и каких-либо вообще прог опубликовала базу, попробовала со своего компа подключиться - висит...Чуточку быстрее, прям чуточку, чем с клиентских машин.

Ужос какой то,комп с вин 10 и тп=)
Переходите в 1с трэш и не морочьтесь

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

(1) А вот нифига. По опыту, апач на БП3 и ЗУП3 больше пары гигов не съедает.
Подключение через веб к базам происходит всегда очень быстро. Если у вас не так - значит что-то криво настроено или в системе, или в апаче.

Базу, надеюсь, публикуете по IP, а не по имени хоста?

(15) резолвить имя хоста по 10 минут?

(16) Мало ли какие глюки могут быть. Лучше, надежнее, публиковать по IP, если есть такая возможность.

(0) Методом исключения получается, что виноват действительно апач, скорее всего. Очень странно, что вы там могли так напутать, в текстовом-то конфиге с горсткой ключевых параметров, но другие оставшиеся варианты ещё менее вероятны. База без веб-публикации у вас работает хорошо (значит, база, скорее всего, ни при чём), веб-публикация на другом компьютере работает по-прежнему плохо (значит, ни ОС, ни сетевое подключение, скорее всего, тоже ни при чём). Поэтому попробуйте поднять IIS — благо он встроен практически в любой виндовс уровня выше домашнего, и в малых масштабах совершенно ничем не уступает апачу. Ну и демо-базу тоже бы неплохо попробовать — хорошая идея была, с этого сразу начать нужно было, сразу многое прояснилось бы.

(17) Сертификат же вроде не получится прикрутить без доменного имени. По крайней мере, без некоторых усилий не получится, вроде какие-то там были костыли для этого дела.

(0) Кстати, а у вас сеть не Wi-Fi ли, часом?

(10) вам предложили зайти с того-же компа через веб

(19) https нужен только при публикации базы в реальном интернете. Для впн или локалки это избыточно.

(22) смотря какая локалка. На крупных предприятиях в ней могут быть сотни или тысячи человек, там безопасники вполне могут потребовать настроить HTTPS.

(23) nginx с проксированием вполне решает проблему https,а апача нечего нагружать лишний раз.

(23) Для большинства локалок (кроме разве что совсем уж микробизеса, ютящегося в нескольких комнатах и имеющего один свитч на всех) совсем не избыточно, поскольку среднестатические реалии примерно таковы: несколько зданий или хотя бы несколько этажей, десятки коммутаторов, сотни пользователей, тысячи розеток, тут вайфай раздают, там арендаторов пустили, здесь вообще проходной двор (но тоже с розеткой), там часть помещений продали, но сети, конечно же, не демонтировали, и так далее. При этом об архитектуре безопасности (даже хотя бы об элементарном разделении подсетей) думают, как обычно, в последнюю очередь. В таких услових только и остаётся, зачастую, что ВПН внутри локалки поднимать, чтобы хоть какое-то подобие контроля существовало. Вот тогда да, тогда хттпс становится уже избыточным, конечно.

(25) Это всё для (22) было, конечно.

(25) С этим согласен. Кстати, непонятно, почему до сих пор не придумали "впн внутри локалки", работающий не в туннельном режиме, а в броадкастном домене.

Как то так - ставишь виртуальный адаптер, задаешь ему ключ, общий для всех компов из этой "защищенной локалки", он привязывается к реальному сетевому адаптеру и гоняет через него зашифрованный трафик. Задачка чуть сложнее студенческого курсовика по системному программированию, если конечно не ставить целью поддержку всего зоопарка ОС.

(27) давно существует. Назыаается vlan

(28) Это не то, там нет шифрования, просто некий признак vlan id в пакеты цепляется

(29) а для этого есть ipsec

Просто нет приложений, которые в пару кликов бы все настраивали. Но наверно потому что и спроса нет

(30) ipsec это слишком сложно настраивается для задачи, с ним не будет никто связываться. Да и работает он только для IP, а прочий трафик, всякий netbios и ipx, и прочую низкоуровщину тоже хотелось бы "спрятать". Реально не хватает такого вот vpn. С обычным симметричным алгоритмом шифрования для работы на уровне фреймов.

(32) а как маршрутизаторы будут трфик гонять, если вме спрятать?

А кстати впн можно и внутри локалки поднять. Никто не запрещает

(32) А зачем? Речь о внутрисетевом трафике исключительно. Если маршрутизатор должен получать доступ к этому трафику - на нем тоже ставится точка входа в vpn и далее он имеет доступ уже к расшифрованному трафику.
Тут задача конкретная - закрыться от снифферов внутри локалки

(34) Да, кучу туннелей, или ставить vpn-сервер, создающий единую точку отказа, или делать извращение с соединениями точка-точка между всеми компами...

(27) >> "впн внутри локалки", работающий не в туннельном режиме, а в броадкастном домене <<
Отличная ведь идея, кстати сказать. Даже для многих более экзотических сценариев зачастую существуют свои специализированные решения, а уж городить из камней и палок хоть сколько-нибудь безопасную внутреннюю сеть просреди дикой помойной инфраструктуры — дело довольно-таки нередкое (по крайней мере, в немосковском захолустье), а ведь ещё зачастую приходится подстраиваться под привычки и представления аборигенов. Было бы здорово, конечно, если б существовало что-нибудь уже готовое, типа вами предложенного, хотя бы в качестве быстрого временного решения.

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