Pharo 5.0 Released!

20 октября 2016 г., 15:54 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="VL-m-9u3BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

Я, в принципе, на книжки сетую, что там много важного не описано.

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

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

А если нет реальной необходимости в этом, то и за FFI переживать не стоит. Нет таких нагрузок, где будут видны проблемы.

20 октября 2016 г., 15:25 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="GQoeq-q2BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

Продолжаю переписываться с цинкомовцами. По-видимому, мы вплотную подошли к моменту, когда они признаются, что правительство с его запретами не причём, а они лично наложили на меня и ещё на 5-10 человек (думаю, по России больше не наберётся) за Сирию.

It's amazing :)

Какая требуется нагрузка на сервер, сколько соединений, байт в секунду, количество сессий?

20 октября 2016 г., 20:22 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ZhZYhS26BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

"Чужая" балансировка едва ли может работать в данном случае.

Положим, у нам N сеансов и M имиджей. N, очевидно, много больше, чем M. Для Seaside напрашивается привязать каждый сеанс к имиджу. Тогда, пока имидж занят обслуживанием одного сеанса, другие сосут лапу. Но мы к этому привыкли, и, вроде бы, всё ОК. Но это пока нет долгоиграющих запросов, в ситуации с которыми и призван помогать MT FFI.

Тогда сеанс должен обитать не в slave-имидже, а где-то ещё. Но где? На балансировщике загрузки или в базе данных. При этом балансировщик загрузки должен быть осведомлён, что если имидж "занят", то посылать ему другой запрос ни в коем случае нельзя. А содержимое Seaside-сеанса (включая блоки кода и содержимое кложур) надо будет передавать туда-сюда, между имиджами и, возможно, базой данных.

Такое уже готовое есть? Это просто сделать?

On Thursday, October 20, 2016 at 7:00:29 PM UTC+5, Denis Kudriashov wrote:

20 октября 2016 г., 15:54 пользователь Victor Metelitsa <[hidden email]> написал:

Я, в принципе, на книжки сетую, что там много важного не описано.

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

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

А если нет реальной необходимости в этом, то и за FFI переживать не стоит. Нет таких нагрузок, где будут видны проблемы.

--
--
<a href="http://groups.google.ru/group/sugr" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес <a href="javascript:" target="_blank" gdf-obfuscated-mailto="ZhZYhS26BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

20 октября 2016 г., 16:22 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ONmEth26BQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

"Чужая" балансировка едва ли может работать в данном случае.

Положим, у нам N сеансов и M имиджей. N, очевидно, много больше, чем M. Для Seaside напрашивается привязать каждый сеанс к имиджу. Тогда, пока имидж занят обслуживанием одного сеанса, другие сосут лапу. Но мы к этому привыкли, и, вроде бы, всё ОК. Но это пока нет долгоиграющих запросов, в ситуации с которыми и призван помогать MT FFI.

Тогда сеанс должен обитать не в slave-имидже, а где-то ещё. Но где? На балансировщике загрузки или в базе данных. При этом балансировщик загрузки должен быть осведомлён, что если имидж "занят", то посылать ему другой запрос ни в коем случае нельзя. А содержимое Seaside-сеанса (включая блоки кода и содержимое кложур) надо будет передавать туда-сюда, между имиджами и, возможно, базой данных.

Такое уже готовое есть? Это просто сделать?

Такого нет. Так только gemstone может работать. 

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

On Thursday, October 20, 2016 at 6:43:13 PM UTC+5, Denis Kudriashov wrote:

20 октября 2016 г., 15:25 пользователь Victor Metelitsa <[hidden email]> написал:

Продолжаю переписываться с цинкомовцами. По-видимому, мы вплотную подошли к моменту, когда они признаются, что правительство с его запретами не причём, а они лично наложили на меня и ещё на 5-10 человек (думаю, по России больше не наберётся) за Сирию.

It's amazing :)

Другая сказала, что я сделал неверное умозаключение. Она считает (!), что запретили таки американские власти, как продукцию потенциального военного назначения!

On Thursday, October 20, 2016 at 7:25:08 PM UTC+5, Victor Metelitsa wrote:

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

On Thursday, October 20, 2016 at 6:43:13 PM UTC+5, Denis Kudriashov wrote:

20 октября 2016 г., 15:25 пользователь Victor Metelitsa <[hidden email]> написал:

Продолжаю переписываться с цинкомовцами. По-видимому, мы вплотную подошли к моменту, когда они признаются, что правительство с его запретами не причём, а они лично наложили на меня и ещё на 5-10 человек (думаю, по России больше не наберётся) за Сирию.

It's amazing :)

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

21 октября 2016 г., 17:53 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2PnkXSZRBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

У нас маленькие нагрузки на вебсервер, от 10 до 300 юзеров во внутренней/полувнутренней сетке, хотя приложение не одно. Зато таблицы в базе данных бывают широкие и толстые, а соединять их надо кучу. Как ни оптимизируй, иногда приличного для вебсервера отклика добиться не удаётся.

On Thursday, October 20, 2016 at 7:42:58 PM UTC+5, Kleptsov Nikolay wrote:

Какая требуется нагрузка на сервер, сколько соединений, байт в секунду, количество сессий?

20 октября 2016 г., 20:22 пользователь Victor Metelitsa <[hidden email]> написал:

"Чужая" балансировка едва ли может работать в данном случае.

Положим, у нам N сеансов и M имиджей. N, очевидно, много больше, чем M. Для Seaside напрашивается привязать каждый сеанс к имиджу. Тогда, пока имидж занят обслуживанием одного сеанса, другие сосут лапу. Но мы к этому привыкли, и, вроде бы, всё ОК. Но это пока нет долгоиграющих запросов, в ситуации с которыми и призван помогать MT FFI.

Тогда сеанс должен обитать не в slave-имидже, а где-то ещё. Но где? На балансировщике загрузки или в базе данных. При этом балансировщик загрузки должен быть осведомлён, что если имидж "занят", то посылать ему другой запрос ни в коем случае нельзя. А содержимое Seaside-сеанса (включая блоки кода и содержимое кложур) надо будет передавать туда-сюда, между имиджами и, возможно, базой данных.

Такое уже готовое есть? Это просто сделать?

On Thursday, October 20, 2016 at 7:00:29 PM UTC+5, Denis Kudriashov wrote:

20 октября 2016 г., 15:54 пользователь Victor Metelitsa <[hidden email]> написал:

Я, в принципе, на книжки сетую, что там много важного не описано.

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

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

А если нет реальной необходимости в этом, то и за FFI переживать не стоит. Нет таких нагрузок, где будут видны проблемы.

--
--
<a href="http://groups.google.ru/group/sugr" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
--
<a href="http://groups.google.ru/group/sugr" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес <a href="javascript:" target="_blank" gdf-obfuscated-mailto="2PnkXSZRBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

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

22 октября 2016 г., 21:36 пользователь Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Vao6oVWBBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> написал:

Я, знаете ли, 1z0-117 сдал ( <a href="https://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&amp;get_params=p_exam_id:1Z0-117" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Feducation.oracle.com%2Fpls%2Fweb_prod-plq-dad%2Fdb_pages.getpage%3Fpage_id%3D5001%26get_params%3Dp_exam_id%3A1Z0-117\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFKbf_aihvoFhhfxfNtHzjvXL8RFg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Feducation.oracle.com%2Fpls%2Fweb_prod-plq-dad%2Fdb_pages.getpage%3Fpage_id%3D5001%26get_params%3Dp_exam_id%3A1Z0-117\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFKbf_aihvoFhhfxfNtHzjvXL8RFg&#39;;return true;">https://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=5001&get_params=p_exam_id:1Z0-117 ) , так что кое-что про индексирование знаю. (На самом деле на этом экзамене куча тонкостей и не раскрыта, из тех, что пришлось изучить)
Но таблички многомиллионные (есть и который больше ста миллионов) и притом широкие (многие десятки полей), плюс джойнятся с кучей других. Для веба же нормальный отклик, считается, меньше секунды. У меня в некоторых местах бывает по 15-30. Справится (и справляется) имидж с многонитевым FFI.

On Saturday, October 22, 2016 at 5:49:34 PM UTC+5, Kleptsov Nikolay wrote:

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

21 октября 2016 г., 17:53 пользователь Victor Metelitsa <[hidden email]> написал:

У нас маленькие нагрузки на вебсервер, от 10 до 300 юзеров во внутренней/полувнутренней сетке, хотя приложение не одно. Зато таблицы в базе данных бывают широкие и толстые, а соединять их надо кучу. Как ни оптимизируй, иногда приличного для вебсервера отклика добиться не удаётся.

On Thursday, October 20, 2016 at 7:42:58 PM UTC+5, Kleptsov Nikolay wrote:

Какая требуется нагрузка на сервер, сколько соединений, байт в секунду, количество сессий?

20 октября 2016 г., 20:22 пользователь Victor Metelitsa <[hidden email]> написал:

"Чужая" балансировка едва ли может работать в данном случае.

Положим, у нам N сеансов и M имиджей. N, очевидно, много больше, чем M. Для Seaside напрашивается привязать каждый сеанс к имиджу. Тогда, пока имидж занят обслуживанием одного сеанса, другие сосут лапу. Но мы к этому привыкли, и, вроде бы, всё ОК. Но это пока нет долгоиграющих запросов, в ситуации с которыми и призван помогать MT FFI.

Тогда сеанс должен обитать не в slave-имидже, а где-то ещё. Но где? На балансировщике загрузки или в базе данных. При этом балансировщик загрузки должен быть осведомлён, что если имидж "занят", то посылать ему другой запрос ни в коем случае нельзя. А содержимое Seaside-сеанса (включая блоки кода и содержимое кложур) надо будет передавать туда-сюда, между имиджами и, возможно, базой данных.

Такое уже готовое есть? Это просто сделать?

On Thursday, October 20, 2016 at 7:00:29 PM UTC+5, Denis Kudriashov wrote:

20 октября 2016 г., 15:54 пользователь Victor Metelitsa <[hidden email]> написал:

Я, в принципе, на книжки сетую, что там много важного не описано.

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

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

А если нет реальной необходимости в этом, то и за FFI переживать не стоит. Нет таких нагрузок, где будут видны проблемы.

--
--
<a href="http://groups.google.ru/group/sugr" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
--
<a href="http://groups.google.ru/group/sugr" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
--
<a href="http://groups.google.ru/group/sugr" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Vao6oVWBBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

Но таблички многомиллионные (есть и который больше ста миллионов) и притом широкие (многие десятки полей), плюс джойнятся с кучей других. Для веба же нормальный отклик, считается, меньше секунды. У меня в некоторых местах бывает по 15-30. Справится (и справляется) имидж с многонитевым FFI.

Но таблички многомиллионные (есть и который больше ста миллионов) и притом широкие (многие десятки полей), плюс джойнятся с кучей других. Для веба же нормальный отклик, считается, меньше секунды. У меня в некоторых местах бывает по 15-30. Справится (и справляется) имидж с многонитевым FFI.

Расскажите, пожалуйста, как многопоточность в образе Smalltalk поможет лучше работать с сложными запросами (join/complex indexes) к БД ?

Ага, я понял.

какие-то средства оптимизации доступны - precalculated e.g. ?

On 24 Oct 2016, at 13:25, Victor Metelitsa <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="bbrkqef0BgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vvm...@...> wrote:

Относительно долгих запросов, в принципе, немного, и используются нечасто (хотя и каждый день). При многонитевом FFI юзер нажал на кнопку и ждёт, его нить "замёрзла", но все остальные юзеры продолжают работать. Без многонитевого FFI "замерзает" весь имидж, все юзеры ждут. Я считаю это неприемлемым, но каждый запрос сделать быстрым не могу.

On Sunday, October 23, 2016 at 11:06:25 PM UTC+5, Vladimir Musulainen wrote:

Но таблички многомиллионные (есть и который больше ста миллионов) и притом широкие (многие десятки полей), плюс джойнятся с кучей других. Для веба же нормальный отклик, считается, меньше секунды. У меня в некоторых местах бывает по 15-30. Справится (и справляется) имидж с многонитевым FFI.

Расскажите, пожалуйста, как многопоточность в образе Smalltalk поможет лучше работать с сложными запросами (join/complex indexes) к БД ?

--
--
<a href="http://groups.google.ru/group/sugr" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;" onclick="this.href=&#39;http://groups.google.ru/group/sugr&#39;;return true;">http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес <a href="javascript:" target="_blank" gdf-obfuscated-mailto="bbrkqef0BgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.