Jump to content
pashast

Оптимизация движка под 120 000 товаров

Recommended Posts

Пролистав пару тем на форуме, где обсуждалась возможность использовать opencart для большого количества товара, захотелось попробовать все самому. :-)

Тем более подвернулся халявный VPS.

Вот что вышло: http://demo5.demo.pl.ua/

Что делал:

- софт на VPS: NGINX без apache, php-fpm, APC

- установил opencart 1.5.5.1

- сразу отключил счетчик товаров в админке, на 10 000 товарах помогло, далее стало бесполезно.

- от стандартного модуля категорий пришлось отказатся, страницы генерились по 2-3 минуты

- использовал этот модуль от toporchilo http://opencartforum...B8%D0%BE%D0%BD/

- категории в верхнем меню пришлось отрубить по той же причине, можно использовать http://www.opencart....tension_id=6074

- оптимизировал таблицы в mysql

Страницы стали открываться быстро, кроме категорий верхнего уровня, независимо от того есть ли в верхней категории товары или нет.

Пришлось закоментировать запрос в контролере категории.

Верхние категории открываются быстро, но стоит только добавть товар в 2 категории , все - хана, тормоза опять начинаются.

  $this->data['categories'] = array();

  $results = $this->model_catalog_category->getCategories($category_id);

  foreach ($results as $result) {
$data = array(
 'filter_category_id'  => $result['category_id'],
 'filter_sub_category' => true
);

/*$product_total = $this->model_catalog_product->getTotalProducts($data); */  

$this->data['categories'][] = array(
 'name'  => $result['name'] . ($this->config->get('config_product_count') ? ' (' . $product_total . ')' : ''),
 'href'  => $this->url->link('product/category', 'path=' . $this->request->get['path'] . '_' . $result['category_id'] . $url)
);
  }

Итог:

Мой способ подойдет тем, у кого строгая иерархия категорий и товаров.

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

Поиск все-равно тормозит

Еще наблюденя:

Построение индексов таблиц ничего в плане производительности не дало.

Платный модуль кэширования с opencart.com сделал только хуже. :-)

Просьба потестить: http://demo5.demo.pl.ua/

  • +1 5

Share this post


Link to post
Share on other sites

Спасибо за отчет

Не хватает параметров вашего халявного VPS и информации как именно вы оптимизировали таблицы в бд.

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

Поиск я немного оптимизировал в своем модуле поиска. Но понятно что для большого к-ва товаров идеально использовать отдельный поисковый движок а не искать все средствами mysql через джойн нескольких таблиц с сотнями тысяч записей.. причем если использовать "LIKE '%" то там даже индексы не будут работать.

Если под платным модулем кеширования емелся ввиду вот этот модуль то этот модуль это развод на деньги. Толку с него почти никакого.

Share this post


Link to post
Share on other sites

Параметры VPS: 12 ядер; 1ГБ оперативы, загрузить ее по полной так и не получилось, максимум 290МБ.

Оптимизация - стандартная, средствами phpmyadmin (пункт: оптимизировать таблицы)

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

Модуль кэширования другой, интересно было бы этот попробовать.

Share this post


Link to post
Share on other sites

Кэширование при такой номенклатуре точно не поможет. Количество файлов в кэше будет гарантировано в разы больше чем номенклатура и тогда на уровне работы операционки с файлами начнутся проблемы. С кэшами в оперативке тоже пробовать бесполезно. Там проблемы будут возникать еще быстрее, причем там могут сбоя проявляться так, что не сразу обнаружишь. А демо базу как делали? Можете архив выложить для общего пользования?

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб). Там ведь и дисковая система наверное такая что ... RAID 5 с кэшом на весь объем диска и 4-5 кратным распараллеливанием чтения записи.

В общем, можно ли тут говорить об оптимизации?

  • +1 1

Share this post


Link to post
Share on other sites

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб).

Вот например цены http://unihost.com/vps/

Share this post


Link to post
Share on other sites

Насчет кэширования товаров не знаю, а вот кэширование стандартных модулей и меню очень бы ускорило движок.

Share this post


Link to post
Share on other sites

На счет VPS тут желательно бы прикинуть, сколько будет стоить в месяц аренда такого чуда :-) (20, 30, 50 тыс руб). Там ведь и дисковая система

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

Share this post


Link to post
Share on other sites
Guest brk

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

тссс! :ph34r:

  • +1 2

Share this post


Link to post
Share on other sites

350 - 600 рублей в месяц, дешевле некоторых хостингов ))

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки). VPS это виртуальный сервер. Теперь получается что вы не ошиблись, а просто не понимаете о чем идет речь. За 350-600 рублей в месяц действительно можно получить только VPS.

sv2109, с расценками на хостинг и на дедики я знаком :-). И вопрос по цене у меня возник в связи с тем, что аренда 4-х ядерного сервера обходится в среднем во столько http://www.jino.ru/s...es/servers.html, а товарищ заявляет о 12-ти ядрах! И при этом утверждается что это стоит 350 рублей. Да не смешите мои подметки :-).

  • +1 1

Share this post


Link to post
Share on other sites

А вообще же мое представление о способности движка работать с номенклатурой в 100 и более тысяч товаров основывается на этом, а сама постановка вопроса кажется не совсем корректной.

Насчет кэширования товаров не знаю, а вот кэширование стандартных модулей и меню очень бы ускорило движок.

Вообще говоря, кэшируются либо запросе к БД, либо уже фрагменты HTML кода (ну или целые страницы). Что вы понимаете под кэшированием стандартных модулей?

Share this post


Link to post
Share on other sites
Оптимизация - стандартная, средствами phpmyadmin (пункт: оптимизировать таблицы)

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

  • +1 1

Share this post


Link to post
Share on other sites

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки).

Виртуальные ядра, как бы, общепринятый показатель производительности VPS.

Даже в дедике на core-i7, половина ядер -виртуальные, так что это все условности и маркетинговые уловки.

И да, нормальный впс может быть производительней дедика за такую же цену.

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

Помогает же, хоть и баловство. :-)

Share this post


Link to post
Share on other sites
Guest brk

12-ти ядерный?! Во первых я подумал что вы просто ошиблись, поскольку для VPS ядер не существует. Ядра можно считать у дедика (у арендованной физической железки). VPS это виртуальный сервер. Теперь получается что вы не ошиблись, а просто не понимаете о чем идет речь. За 350-600 рублей в месяц действительно можно получить только VPS.

sv2109, с расценками на хостинг и на дедики я знаком :-). И вопрос по цене у меня возник в связи с тем, что аренда 4-х ядерного сервера обходится в среднем во столько http://www.jino.ru/s...es/servers.html, а товарищ заявляет о 12-ти ядрах! И при этом утверждается что это стоит 350 рублей. Да не смешите мои подметки :-).

:) до 14 ядер и это тоже не предел

Я давно говорил что Вы теоретик.

5a1c4e3fe04a3c00d4f59ad869a93ba4.jpg

этот скрин другого серванта и он не относится к топику Паши

Share this post


Link to post
Share on other sites

:) до 14 ядер и это тоже не предел

Я давно говорил что Вы теоретик.

5a1c4e3fe04a3c00d4f59ad869a93ba4.jpg

этот скрин другого серванта и он не относится к топику Паши

Да, теоретически у вас красивые картинки. Виртуально нарисовать можно все что угодно. Если каждое виртуальное ядро считать эквивалентом 386-го, то и 140 можно нарисовать, и на гигагенцовом целероне, как маркетинговую уловку.

  • +1 1

Share this post


Link to post
Share on other sites

а как быть с нагрузкой? тестировали? что если завтра на сайт придет 10 000 человек. как себя тогда будет вести магазин? посещаемость на мой взгляд это очень важный показатель.

Share this post


Link to post
Share on other sites

Какой ты кешер юзал ?

Тот на который я наводку дал ?

Share this post


Link to post
Share on other sites

а как быть с нагрузкой? тестировали? что если завтра на сайт придет 10 000 человек. как себя тогда будет вести магазин? посещаемость на мой взгляд это очень важный показатель.

Посоветуете, где можно бесплатно взять хотя-бы 5 000 посетителей - потестирую.

Какой ты кешер юзал ?

Тот на который я наводку дал ?

не помню, что ты мне там советовал, если честно )

Share this post


Link to post
Share on other sites

ab -c 100 -n 5000 http://site.com/

Да это только морду проверит, выдержит.

Если-бы по страницам какой-то сервис полазил.

Share this post


Link to post
Share on other sites

Спасибо Паше, за дамп его монстр базы...

Веду тестирование у себя на сервантусе и буду апдейтить результаты экспериментов с замерами.

Может получится шпаргалка по оптимизации движка.

Итак.. Имеем сервант, стоящий практически в ногах, на котором хостится штук 5 проектов по 500 хостов в день.. Сейчас ночь, нагрузки на нем практически нет (параметров сервантуса не знаю, завтра скажу)

чистый свежеустановленный оф опенкарт 1,5,4,1 И подключенную базу

Все завелось. Работает... морда загрузилась сразу без проблем....

В верхнее меню вывел всего одну категорию, чтобы было куда клацнуть, чтобы протестить.

После публикации модуля категорий в категории. Я запарился ждать генерацию страницы и полез ковырятся. Вобщем из коробки не завелось.

Впилил в индекс файл замер времени...

1. Отключил подсчет количества товаров в катеории в контроллере модуля...

Страница сгенерирована за 52.657795 секунд

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

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

2. Отключил подсчет количества для блока на странице категорий. Прирост не ощутимый - всего секунда.. что можно списать на погрешность.

.Страница сгенерирована за 51.879392 секунд

3. Недоотключил я подсчет общего количества для категорий как оказалось в модуле категорий... Доправил. Получил уже вполне вменяемое значение. (но здесь был выпилен подсчет общего количества товаров для пагинации). Закешировал в модели getCategories.

Страница сгенерирована за 1.263737 секунд

4. Страница категории с 20 товарами и включенным модулем категорий... при первом заходе с 20 товарами на странице

Страница сгенерирована за 2.571835 секунд

Повторный заход

Страница сгенерирована за 0.086185 секунд

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

5. Посмотел модуль ТОПОРЧИЛО.. Имеет право на жизнь, как замена модуля категорий. Но по тому же принципу верхнее меню не реализуешь, (а я сторонник горизонтальной навигации) будет в минус юзаюбильности, пока оно будет подгружаться..

Но с меню не вижу никаких проблем. Если встанет вопрос о живом проекте с таким количеством товаров, то меню можно и ручками в хедер вписать (кажется RGB поднимал по этому поводу вопрос в какой то ветке). Ну и соответственно выпилить из контроллера headera кусок, который генерирует дерево категорий.

6. Совершенно непонятно как поведет себя это монстро с сеоурлами. Так как база под оф версию, в ней нет майн категорий, соответсвенно кешированное сео про не прикрутишь. Хотя я думаю что выборка из одной таблицы в три столбца и в 120 000 записей, пусть даже 50 полей, не сильно подгрузит производительность. А с кешированным допилом фрилансера, будет летать.

7. Валяется у меня где то модель продукта от Yesvik, оптимизированная до безумия, которую он пытался протащить в сборку, но она по моему под 0.2.0, поэтому перепиливать ее под новую версию и ставить на ней опыты нет желания и времени, хотя подозреваю, что толк был бы.

8. Теперь перейдем к тяжелой артиллерии.. Прикрутим кешер. Кешер у меня использует VQMOD, ща заодно посмотрим как меняется производительность с кешированным скриптом вкумода, хотя при том что вкумодов особо у меня нету вряд ли что то увидим. Но при использовании VQMOD на продакшн версии, все такие надо поменять скрипт самой библиотеки на модификацию с кешированием.

Вот такие вот результаты имеем для главной страницы:

Without Caching: 0.072319984436035 With Caching: 0.000507831573486339.

Для страницы категории без товаров с включенным модулем категорий вот такие:

1.3437700271606 With Caching: 0.0025069713592529И

Для страницы категории с товарами с включенным модулем категорий вот такие:

0.1599178314209 With Caching: 0.0027790069580078

Страница товара:

0.26726293563843 With Caching: 0.00058984756469727

Прошу заметить, это 120 тысяч товаров!!!!

9. Возникает логичный вопрос, как поведет себя этот колхоз, когда нагенерит кеша, а вот сейчас и проверим, запущу минут на 10 XENU, пусть походит, а там и посмотрим.

Пока работает, 20 одновременных потоков, ничего не отваливается, нагенерило уже тыщи 1,5 страниц, При это все остальные проекты хостящиеся на сервере, летают.

Я думаю пора останавливать.

Получаем на некешированном сайте производительность в 2000 страниц за 10 минут в 20 подключений.

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

При 100 одновременных тредах, потихонечку кое какие страницы начинают отваливаться....

Сейчас посмотрим что будет, если запустить процесс опять, у нас же есть кеш страниц....!

те же 2к страниц отдались уже за 2 минуты 50 секунд. Кешер дал прирост более чем в три раза...

Ну что ж. можно подводить итоги...

Однозначно есть вариант научить опенкарт работать с большой базой товаров.

1. Без железяки не обойдешься - факт. ни на дешевом VPS, а уж тем более на каких нить базовых хостинг пакетах такое поднять не удастся.

2. Кеширование результатов запросов на уровне моделей, отключение подсчета количества товаров - уже дают значительный эффект.

3. Для проектов с 1 языком и с 1 магазином, выжигаем напалмом всю мультиязычность и мультимагазинность - тоже получим профит однозначно (замахался я по 20 раз перезагружать одну и ту же страницу полночи). Может тест с обрезанием мультиязычности сделаю позже.

Но все это все равно не приводит к вменяемым результатам, потому что все остальные процессы генерации страниц, все равно пожирают моск остаются ресурсоемкими.

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

Контроллер футра в идеале надо оставить пустым, а в хедере оставить формирование метатегов и заголовка.

5. Все языковые переменные убираем из контроллеров и вживляем в тплки.

7. Использовали VQMOD? Закончили проект ? в идеале перелейте и переименуйте из его кеша все файлы на место оригинальных. Лень - поменяйте библиотеку на кешированный вариант.

8. Про автогенератор сайтмапа, или фид для яндексмаркета, придется забыть, либо же применить к ним суровый напильник. В коробочном варианте - они уложат вам любой сервант, на таком количестве товаров.

9. Но все же для полного HighLoada выход один, - кешировать страницу на уровне HTML. Для чего на офсайте хватает модулей. Которые вместо динамического контента отдают данные из кеша, пока посетитель не зарегался, или не положил чего нить в корзину. Чтобы не нагиналась файловая система, это кеширование нужно оптимизировать, раскладывая кеш страниц с товарами и подкатегориями в

соответсвующие родительские папки. Если потребуется реализация какого нить динамического контента, - AJAX в помощь, те же последние просмотренные можно легко реализовать через кукисы.

По такому принципу работает Lenta.ru. У них практически все страницы - статичные, а при добавлении новости - происходит автообновление кешированных данных.

В итоге получаем достаточно живенькую зверюжку, которая в состоянии обработать беспроблемно тыщ 10 хостов в день с 100к+ товарами, при средней глубине просмотра 10-15 страниц.

А ежели надабна будет поднять увеличится под количество посетителей, то потанцевав с бубном можно собрать интересное решение из, кеш-сервера и контент-сервера.

На проекте с 10к+ посетителей в день, даже если мы будем пирожки по 2 рубля продавать, затраты на такие изыски окажутся просто незаметными.

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

UPD. Ссылку на подопытного не дам, так как там несколько продакшн-проектов, и не хотелось бы чтобы они завтра умерли, изза того что например BRK начнет тесты на пиковые нагрузки))), но все цифры, может подтвердить Pashast, которому еще раз спасибо за дамп.

  • +1 4

Share this post


Link to post
Share on other sites
Guest brk

Да это только морду проверит, выдержит.

Если-бы по страницам какой-то сервис полазил.

315a9a3c6bbb34a3015f4283dc3ee403.png

UPD - оптимальный

f4229815fb215a4581f712fa84519365.png

  • +1 1

Share this post


Link to post
Share on other sites

UPD. Ссылку на подопытного не дам, так как там несколько продакшн-проектов, и не хотелось бы чтобы они завтра умерли, изза того что например BRK начнет тесты на пиковые нагрузки))), но все цифры, может подтвердить Pashast, которому еще раз спасибо за дамп.

Подверждаю, все работает быстро со стандартными модулями категории.

Спасибо за развернутый ответ.

С BRK я все согласовал ))), спасибо ему за тесты, с их помощью удалось подкрутить настройки сервера.

  • +1 1

Share this post


Link to post
Share on other sites

68000+ товаров. Самый дешевый невыделенный хостинг. Движок 1.5.5.1, сделана оптимизация медленных SQL-запросов. Дополнительное кэширование не используется.

http://toporchillo.jino.ru/oc1551opt/ - с небольшой оптимизацией

http://toporchillo.jino.ru/oc1551/ - OpenCart 1.5.5.1 из Git-репозитория.

Русского языкового пакета нет, так что не удивляйтесь, что база русская, а интерфейс английский.

Резюме: OpenCart для большого количества товаров подходит

Share this post


Link to post
Share on other sites

Поучаствую в совместной разработке...

6. Совершенно непонятно как поведет себя это монстро с сеоурлами. Так как база под оф версию, в ней нет майн категорий, соответсвенно кешированное сео про не прикрутишь. Хотя я думаю что выборка из одной таблицы в три столбца и в 120 000 записей, пусть даже 50 полей, не сильно подгрузит производительность. А с кешированным допилом фрилансера, будет летать.

Как оказалось - запрос из длинной таблицы SEO-URL небыстрый. Решается так:

1. Уменьшаем длину полей, индексируем. Индексы должны поместиться в Index Cache

1. Без железяки не обойдешься - факт. ни на дешевом VPS, а уж тем более на каких нить базовых хостинг пакетах такое поднять не удастся.

Надо делать различие между большим количеством товаров и много товаров + много посетителей. При первом варианте можно на дешевом хостинге, при втором - хостинг нужен дорогой.

3. Для проектов с 1 языком и с 1 магазином, выжигаем напалмом всю мультиязычность и мультимагазинность - тоже получим профит однозначно (замахался я по 20 раз перезагружать одну и ту же страницу полночи). Может тест с обрезанием мультиязычности сделаю позже.

С мультимагазинностью согласен, с мультиязычностью не совсем. Как им образом вы решили избавиться от мультиязычности? Хранить описание товара в таблице oc_product - плохая идея!

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

Контроллер футра в идеале надо оставить пустым, а в хедере оставить формирование метатегов и заголовка.

5. Все языковые переменные убираем из контроллеров и вживляем в тплки.

Это экономия на спичках

8. Про автогенератор сайтмапа, или фид для яндексмаркета, придется забыть, либо же применить к ним суровый напильник. В коробочном варианте - они уложат вам любой сервант, на таком количестве товаров.

Лечится их генерацией через CRON ночью, когда посетителей нет. Единственно, может не хватить памяти.

А теперь просьба. Вы не дали ссылку на тестируемого. Попробуйте проделать следующее: в строке поиска товаров поискать:

1. Пробел

2. a b c d e f g h i j k l m n o p q r s t u v w x y z (все одной строкой)

3. Проделайте поиск с включенной галкой "искать в описании".

Share this post


Link to post
Share on other sites

68000+ товаров. Самый дешевый невыделенный хостинг. Движок 1.5.5.1, сделана оптимизация медленных SQL-запросов. Дополнительное кэширование не используется.

http://toporchillo.jino.ru/oc1551opt/ - с небольшой оптимизацией

http://toporchillo.jino.ru/oc1551/ - OpenCart 1.5.5.1 из Git-репозитория.

Русского языкового пакета нет, так что не удивляйтесь, что база русская, а интерфейс английский.

Резюме: OpenCart для большого количества товаров подходит

Есть товары в двух категориях?

Или у каждого товара только одна категория?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By fduw
      Как подключить mysql через unix socket?
      В инете не нашел рабочей инфы
       
      Стандартная конфа

       Так не работает
      define('DB_HOSTNAME', 'unix:/tmp/mysql.sock'); define('DB_HOSTNAME', 'localhost/tmp/mysql.sock'); define('DB_HOSTNAME', 'tmp/mysql.sock');  
    • By perebor
      Ребят привет, нужна помощь, прошу не пинаться) я пока не силен в оптимизации БД, но очень интересно было бы разобраться самому.
      На сервере где-то раз в месяц происходят скачки по нагрузке и кол-ву запросов. Последний был 27 числа, админка при этом пару раз отдавала 503 ошибку. Хостинг шлет предупреждения.
      Есть лог запросов, но все, что пока понимаю, так это то, что основную нагрузку подбрасывают запросы из мегафильтра. Собственно вопрос в том, что бы понять что это за запросы и как это дело оптимизировать, или может вообще стоит хостинг сменить. Буду благодарен если направите в правильное русло)

      сайт: nice-office.ru
      хостинг: ihc.ru
      Slow log:
       
       

    • By Tinyled
      Добрый день, столкнулся с задачей, выборки данных из таблицы в бд
      сама задача состоит в том что бы получить из таблицы записи сгруппированные по телефону (phone), но перед этим отсортированные по дате (datetime DESC), при этом с лимитом в 200 записей (LIMIT 0,200)
      прошу помочь понять, как можно сформировать запрос к бд, дабы не нагружать сильно бд, и выполнить все условия.
      Или может быть я ошибаюсь, и конечную сортировку лучше делать на php?
      пробовал запросом 
      SELECT sends.* FROM (SELECT * FROM `oc_watsappchat_send` WHERE creator="" ORDER BY `id` DESC) as sends GROUP BY sends.phone ORDER BY `id` DESC LIMIT 0,200 но запрос выходит достаточно долгим, и как я понимаю при увеличении числа записей в таблице время будет также увеличиваться
    • By YaroslavFrolov
      Доброго времени суток. Помогите плиз, нужно данные из корзины вставить в письмо заказа. Обработчик не от опенкарт.
    • By TerranXXX
      Необходимо модифицировать CMS ocStore v2.3 (русский OpenCart 2.1) для работы с MS SQL Server 2012+.

      Обязательные требования:
      1. Взаимодействие CMS с БД должно происходить исключительно через хранимые процедуры (доступа к таблицам у CMS не будет)
      2. Часть логики из php нужно перенести в хранимые процедуры (например динамическое формирование запросов)

      В ответе сообщите срок и стоимость данной работы.
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.