Проблемы с SOAP веб-сервисами...

[Yarick]

У нас интернет магазин работает на PHP с web-сервисами от 1С.
И в ситуации когда, происходят проблемы на стороне нашего сервера: чрезмерная загрузка 1С сервера, конфликт блокировок, проблемы с сетью предприятия, отсутствие интернета и пр...

Клиенты, не смотря на уведомления об ошибках, продолжают пытаться работать в интернет магазине, что за собой вызывает лавину SOAP запросов к серверу 1С, на которые не приходят ответы (или приходят но медленно). Таким образом накапливаются соединения на которые web-сервер ждет ответа в результате чего он уходит в свап...

Чтобы его вытянуть оттуда достаточно просто перезагрузить apache...

Как можно избежать таких проблем? Мне кажется что проблема в настройках apache...

 

[Redjik]

nginx как реверс прокси

 

[MiksIr]

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

 

[Yarick]

Спасибо...

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

Спасибо...

У нас в принципе и реализовано все так, что интернет магазин является больше frontend оберткой, вся логика выполняется сервисами 1С. А клиенты видят остатки, цены (каждый свою), баланс в реальном времени...
У меня есть идея реализовать еще один слой сервисов, т.к. многие клиенты просят API для своих ERP-систем и интернет-магазинов. И уже наш интернет магазин пустить тоже через этот API.
А в этом слое реализовать все почти так-же как Вы и пишите, только он будет запросы клиентов обрабатывать на основе собственной БД, которая в свою очередь будет синхронизироваться с 1С по расписанию, например по критичным показателям (остаткам) раз в минуту-две...

Я не архитектор, поэтому было бы интересно услышать мысли более опытных

И все таки остается огромное желание уйти от синхронизации...

 

[artemyaz]

Yarick, пожалуйста, напишите, как вы решили проблему с веб-сервисами.

Советы понятны:
- кеширование ответов веб-сервиса на сайте,
- хранение на сайте очереди запросов на запись - на случай, если веб-сервис отвалится.

Но что делать если веб-сервис отвалился, а мы к нему делаем много обращений на чтение. Пользователи (пусть даже через ajax) , будут делать очень медленные запросы на PHP до таймаута. Апач перестанет обрабатывать новые запросы, когда заполнится MaxClients, и сайт повиснет.

Совет про nginx как реверс прокси не совсем понял. Как это поможет уменьшить количество процессов Апача, если PHP - это модуль апача.

 

[Yarick]

Проблема не решена!
У интернет-магазина огромные обороты, и ассортимент. Руководство хочет видеть остатки, на текущий момент, критичны секунды. Так что вариант с синхронизацией отпадает.
- Все что я сделал, везде где не критично добавил кэширование чем уменьшил количество запросов через веб-сервисы.
- Также прикрепил еще один костыль. Добавил html заглушку, когда замечаются проблемы с веб-сервисами. Пользователи 1-5 мин. видят эту заглушку.

Сейчас я уже как полгода не работаю на той фирме. И новый программист вроде как переделывает архитектуру.

P.S. Еще мне советовали, не использовать стандартный класс SoapClient, а поискать другие библиотеки, где можно будет эти ситуации обрабатывать.

 

[artemyaz]

Спасибо Yarick, и еще вопрос:
на какой системе управления ваш сайт? Или он полностью самодельный?

В Битриксе, например, есть свой модуль веб-сервисы. Но как там решен этот вопрос, еще не знаю.

 

[Yarick]

Там была CMS студии которая начинала это сайт разрабатывать (CM5). Но со временем отказались от их поддержки и вели сами. Работа с веб-сервисами, да и вообще весь интернет-магазин, полностью самописный модуль к этой CMS.

 

[grigori]

Как можно избежать таких проблем? Мне кажется что проблема в настройках apache...

Проблема в генофонде.
Надо не джипы покупать, а не жлобиться на инфраструктуре. Нанять грамотного техдира, который поставит процесс разработки.

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

Руководство хочет видеть остатки

Сказки Венского леса. Я в Сотмаркете 2 года работал. "Остатки" есть в инвентаризации. В магазине понятия "остатки" нет, есть "статус".

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

 

[artemyaz]

Grigori, пожалуйста, напишите, как правильно.

Задача: сайт на PHP подключается к 1С через SOAP. Сайт находится далеко от 1С. Пользователи ходят по сайту и смотрят свои отчеты. Некоторые отчеты кешировать невозможно, потому что они каждый раз разные.

Ситуация с длинными PHP запросами (даже на ajax) может привести к переполнению MaxClients. Что делать?

 

[grigori]

artemyaz, ваш вопрос аналогичен простой житейской проблеме: есть маршрутка и пассажиры, иногда пассажиров больше, чем влазит в маршрутку, и пассажиры дерутся чтобы в нее влезть чтобы не стоять на морозе, что делать?

вариантов масса: выводить еще одну маршрутку (добавить сервер 1С), расширить маршрутку (апгрейднуть сервер 1С), проложить метро (выстроить нормальную архитектуру), построить зал ожидания и автомат с билетами (перед 1С создать сервер очереди, клиенту по AJAX показывать его номер в очереди и тетрис чтоб время скоротал), и так далее

но я бы начал с того, что нанял бы начальника транспортного цеха,
правда, ему тоже надо будет купить внедорожник, но иначе вы будете лежать, советами здесь не поможешь

 

[artemyaz]

Я сам начальник транспортного цеха и выбираю архитектуру. Могу настраивать Nginx и Apache. Смотрю, как можно написать свой веб-сервер на PHP, чтобы держать много соединений.

Мне не важно, как долго пользователи будут смотреть как крутится колесико загрузки. Сейчас важнее, чтобы соединений могло быть много, и когда ответ пришел, пользователь бы получал свой результат. И чтобы тот, кто тыкает бесконечно кнопку "Обновить" не смог бы всё завалить.

Так что grigori, поможете такое реализовать?

 

[grigori]

вообще-то настраивать nginx и apache должен админ
помочь - не вопрос, $70/hr

 

[artemyaz]

Увы и ах. Заказчику невозможно объяснить за что ему вам платить. Даже, когда нагрузка возрастёт. А может и не возрастет.

 

[grigori]

так выпьем за то, чтобы не возрастала! люблю Jonny Walker

на самом деле если вы готовы платить за помощь - напишите пост в "Работу" с пометкой "удаленно" и поставьте ту почасовую ставку, на которую вы готовы