nopCommerce 4.40 - Bug fixes and improvements

@Nop-Templates.com
(I'd like to see that other thread ;)    I'm curious why you need to "persist temporary address data like country, city, etc. during the checkout".  (I suspect it must be related to your one-page-checkout.  I suppose you could instead use generic attribute on customer.)

New York wrote:

Hi Dennis,

Thank you for asking!

Yes, it is related to our One Page Checkout plugin.
As you know we have everything on a single page i.e addresses, shipping, and payment methods etc.
We need to persist certain fields of the address i.e country, state, etc. mainly due to the fact that some payment and shipping providers have restrictions and won't show up unless the country is set to the billing/shipping address in the database. Of course, it is configurable which fields of the address to be persisted.
That is why we use "temporary" addresses as unless the customer finishes the checkout and places an order we don't want to show these addresses as part of the address book.
Yes, we already use generic attributes to "mark" which are these "temporary" addresses of the customer but we have no way to "hide" them from the customer in the My Account area for example or the administration, etc.

In previous versions of nopCommerce (prior to 4.3), there were no constraints for the address to be part of the customer addresses but now we need to keep these "temp" addresses there as we have no choice.
We have to constantly answer our clients why they have some blank or incomplete addresses in their accounts which is a total waste of time and we have no real solution for them.

Thanks,
Boyko

Serious degradation in performance between this new Release and the Beta under load.

After initially testing 4.40 Beta on 25th Feb, I was actually impressed with the performance under load compared with 4.30, but something has happened from Beta to Release which has seriously affected the performance under load (Response Times are dreadful compared to Beta!).

I know how much work the team have put into this release, so I don’t want to come across as bashing it, but I do want to point out the serious degradation in high load performance between beta and release.

All tests use https://loader.io - it’s easy enough for you to do your own testing with a free account.

4.40 Beta No Source

50 Clients per second, 1 min.
Response Times
Average: 162 ms
Min/Max: 119 / 954 ms

Response Counts
Success: 2999
Timeout: 0
400/500 errors: 0/0
Network errors: 0

100 Clients per second, 1 min.
Response Times
Average: 207 ms
Min/Max: 123 / 1329 ms

Response Counts
Success: 5999
Timeout: 0
400/500 errors: 0/0
Network errors: 0

120 Clients per second, 1 min.
Response Times
Average: 3139 ms
Min/Max: 250 / 10396 ms

Response Counts
Success: 3756
Timeout: 0
400/500 errors: 0/1
Network errors: 0

150 Clients per second, 1 min.
Response Times
Average: 9669 ms
Min/Max: 287 / 26501 ms

Response Counts
Success: 1565
Timeout: 0
400/500 errors: 0/103
Network errors: 0

Note, the 150 clients per second resulted in “Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.” errors in the logs.

This can be fixed by increasing the max pool size via the connection string, but the response times basically make the site unusable.

0-500 over 1 min
Response Times
Average: 2298 ms
Min/Max: 117 / 12936 ms

Response Counts
Success: 4987
Timeout: 0
400/500 errors: 0/0
Network errors: 0

0-1000 over 1 min
Response Times
Average: 5036 ms
Min/Max: 118 / 20393 ms

Response Counts
Success: 4894
Timeout: 0
400/500 errors: 0/0
Network errors: 0

Under this test, the site is basically unusable once response times get above 5 seconds.

4.40 Release No Source

50 Clients per second, 1 min.
Response Times
Average: 1631 ms
Min/Max: 474 / 3374 ms

Response Counts
Success: 2464
Timeout: 0
400/500 errors: 0/0
Network errors: 0

100 Clients per second, 1 min.
Response Times
Average: 7333 ms
Min/Max: 762 / 23900 ms

Response Counts
Success: 1086
Timeout: 0
400/500 errors: 0/44
Network errors: 0

The site is basically unusable with these response times with 100 connections.
I didn’t run 120 clients per second, or 150 as the response times at 100 were bad enough.

0-500 over 1 min
Response Times
Average: 4884 ms
Min/Max: 155 / 18720 ms

Response Counts
Success: 2436
Timeout: 0
400/500 errors: 0/0
Network errors: 0

I didn’t run a 0-1000 as there was no point.

All tests performed on standard installs (both are no source downloads), with sample data. Nothing changed from the initial install, apart from enabling the ajax menu. App Pool is NoManaged Code.

Server details:
Dual E5-2620 v3 CPU’s (@ 2.4GHz).
Dual 1TB SSD in raid 1.
128GB ECC ram.
Windows Server 2019 on SSD.
IIS 10.
MSSQL, with web licence (30gb allocated).
Plesk.
1Gb/s port.
All files on an NVMe.

If anyone would like links to each specific test graph, just shout.

I'm thinking of going through the commits, to see where the issue arrises from?

Craig

untiedshoes
Can you do the test with the same data for nop 4.30?

@foxnetsoft

Hey man! I did plenty last year when my client moved from 4.20 > 4.30 and published the result on GitHub.

I’ll put some of the results up tomorrow morning.

@UntiedShoes
Did you ever check the System > Log to see if any errors, or any "Application started" messages?

New York wrote:

With 4.30 I used to a lot of completely random restarts.

I've just checked both 4.40 sites (release & beta, both haven't been touched since, my last load tests) and both restarted when I went onto them, even though the keep alive scheduled task is running.

untiedshoes wrote:

These 2 issues are very important to fix. We have webshops that has campaigns all the times with newsletters and facebook posts. So the stress test log you posted for 4.4 doesnt look too good.

Regarding my tests, I've just ran another 100 clients per second, for 1 min on the latest release, and found multiple "Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached." errors in the log.

Adding "Connection Timeout=300;Min Pool Size=0;Max Pool Size=2024;Pooling=true;MultipleActiveResultSets=True" to the connection string stops this error, and the associated 500 timeouts in the test.

The results of that test are better than the previous 100 per second, without the modification to the connection string.

Response Times
Average  : 4062 ms
Min/Max: 725 / 8933 ms

Response Counts
Success: 2442
Timeout: 0
400/500: 0 / 0
Network: 0

Without the connection string modification:
Response Times
Average: 7333 ms
Min/Max: 762 / 23900 ms

Response Counts
Success: 1086
Timeout: 0
400/500 errors: 0/44
Network errors: 0

Running 120 clients per second for 1 min on the beta, with the same modification to the query string results in:

120 Clients per second, 1 min.
Response Times
Average: 1842 ms
Min/Max: 436 / 5742 ms

Response Counts
Success: 3756
Timeout: 0
400/500 errors: 0/1
Network errors: 0

Without the connection string modification:
120 Clients per second, 1 min.
Response Times
Average: 3139 ms
Min/Max: 250 / 10396 ms

Response Counts
Success: 3756
Timeout: 0
400/500 errors: 0/1
Network errors: 0

As you can see, there is a stark difference between Release & Beta, and both require the MaxPool size increasing via the connection string.

If anyone else is willing, it would be extremely helpful if you could run the same tests on a server of your own.. as said, it's easy to do, even with the free account from loader.io?

hkbits wrote:

I have multiple clients all running different versions of nopCommerce, but I have one, one very very important client that runs a large, multi-store (the very first, 3.00 multi-store to go live). Since that store was launched, we've had so many issues with the sites going down under load.

The sites are for football clubs, and when there's a new kit launch, sale etc, traffic to the websites can increase in very large amounts, over a very short period... this can bring them down. The client has invested heavily over the years, upgrading the server to what we have now (details in my original post).

Once this initial surge is over, the sites can easily handle 600/700 on a site at a time (via analytics) without even noticing it. I moved this client from 4.00, to 4.30 last year, and to be honest, I wish I never had.

I did have huge hopes for all the async work that's been done, which from testing the beta version, it looked like big improvements had been made, but testing release, it looks like a huge step back.

Craig