Performance: slow login

[姜晨]

Hellow:

I currently use idempiere version 5.1. The server configuration is 16g memory, processor inter (R) Xeon (R) CPU e5-2603 V4 @ 1.70GHz 1.70GHz (2 processor), and the database is Oracle11g. It will take a long time to log in each time. Is there any solution to solve this problem.

thank you.

[Victor Suárez]

Hello,  

Have you checked for open transactions? Or blocking transactions?

Regards

[Carlos Antonio Ruiz Gomez]

There are a lot of threads in these forums about slowness on login,
and/or slowness on completing documents.

AFAIR that situation was created by a change in the browsers, and is
already solved in iDempiere 7.1 and above.

So, the recommended solution would be to migrate to 7.1

Regards,

Carlos Ruiz


El 14/07/20 a las 4:16 p. m., 姜晨 escribió:

[Hiep Lq]

What's your browse? how much role, org on your system?

i get slow with firefox on linux with hundreds orgs AND hundreds roles

you have strong server but did you adjust -Xmx -Xms?

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/0b2ccb58-ae9f-e115-b03b-a357c833d89e%40gmail.com.

--

Lê Quý Hiệp
Email: hie...@hasuvimex.vn
Skype: admin.hasuvimex

Company: Thanh Hoa Fishery Import - Export J.s.c  (Hasuvimex) DL 47

Add: Lot E, Le Mon Industrial Zone, Thanh Hoa, Vietnam

[Martin Schönbeck]

Hi Carlos,

Carlos Antonio Ruiz Gómez schrieb am Dienstag, 14. Juli 2020 um 18:21:39 UTC+2:

So, the recommended solution would be to migrate to 7.1

Even then you could get a very slow login. Use e.g. csv-import for a very big number of products (in my case to add a vendor). It then will take very long to prepare the list  of last used entries.

Regards,

Martin

[Carlos Antonio Ruiz Gomez]

Not sure if about "last used entries" you mean "Recent Items"?

If that's the case, the number of recent items saved is driven by the SysConfig parameter RecentItems_MaxSaved

And also is configurable the number of items shown with RecentItems_MaxShown

Perhaps you have a very big value configured there?

Regards,

Carlos Ruiz

El 14/07/20 a las 8:41 p. m., Martin Schönbeck escribió:

--

[Heng Sin Low]

if it is working badly for you (the recent items), please raise it up as a bug (jira ticket) with details to reproduce.

--

You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/f04ab47c-8dc6-4fa3-8334-10d253ccdb71n%40googlegroups.com.

[姜晨]

Because when the project is just started, the login system will be slow, so there is no check

[Martin Schönbeck]

Hi Carlos,

Carlos Antonio Ruiz Gómez schrieb am Dienstag, 14. Juli 2020 um 23:40:17 UTC+2:

Not sure if about "last used entries" you mean "Recent Items"?

Yes.

 

If that's the case, the number of recent items saved is driven by the SysConfig parameter RecentItems_MaxSaved

Is set to 50

And also is configurable the number of items shown with RecentItems_MaxShown

Is set to 10 

Perhaps you have a very big value configured there?

No, but the table then contained about 60.000 entries. Deleting them made login fast again. I'll do as hengsin proposed but I'll have to check the exact way I produced it first.

Regards,

Martin

[Martin Schönbeck]

Hi,

I tried to reproduce it. Tested different preconditions, but not a single recent item was created. So if it hits me again I'll observe what I did but for the moment I can't tell you what was wrong.

Regards,

Martin

[Martin Schönbeck]

Hi,

ok, now I could reproduce it. I had to add a replenish entry for 37000 existing products. I prepared four csv-files. Header:

"Value/KT","M_Replenish>M_Product_ID[Value]/KT","M_Replenish>M_Warehouse_ID[Value]/K","M_Replenish>IsActive","M_Replenish>ReplenishType","M_Replenish>Level_Min","M_Replenish>Level_Max","M_Replenish>QtyBatchSize"
running as merge. This produced a recentitem for each entry and for the second file took so long that the transaction for the import itself was aborted. I tried then with

"Value/K","M_Replenish>M_Product_ID[Value]/K","M_Replenish>M_Warehouse_ID[Value]/K","M_Replenish>IsActive","M_Replenish>ReplenishType","M_Replenish>Level_Min","M_Replenish>Level_Max","M_Replenish>QtyBatchSize"

which ran seamlessly. No additional recentitems. A third try with

"Value/KT","M_Replenish>M_Product_ID[Value]/K","M_Replenish>M_Warehouse_ID[Value]/K","M_Replenish>IsActive","M_Replenish>ReplenishType","M_Replenish>Level_Min","M_Replenish>Level_Max","M_Replenish>QtyBatchSize"

again produced recentitems.

All replenish entries didn't exist before.

After reloading the page where the import ran so that the connection to the window was broken, importing got much faster, I could see in another window the recentitems appearing much faster.

I didn't have a look at the source, but I assume, counting the actual present recentitems uses the session of the import while inserting them uses another session.

Regards,

Martin

[Martin Schönbeck]

Hi,

I must correct myself. The recentitems are created in masses even if the import is commited per line.

Regards,

Martin