[closed] FarCry v7.x login request time

Hi guys! We noticed that from version 6.0.14 to version 7.x, the time for the login request to finish have increased significantly. In 6.0.x it takes less than 3-400ms (sysadmin user), in version 7.x it can take several seconds (from 2-3 seconds and more). Is this something that will be optimized in the near future?

1 Like

I do know of an issue where a particular large farLog table would slow down login, but thought it had been fixed in 7. For the most part the 6 and 7 logins are the same. Can you tell us more about your app? How many users are there? Do you have any custom security?

Blair

I just did a few quick tests on my personal website ($5/mo VM on Digital Ocean).

The login portion of the request (before the redirect to the webtop index) takes ~950-990ms. This is definitely “slower” in FarCry 7.x because a very strong password hashing algorithm (bcrypt) is used by default, whereas in FarCry 6.x you may have been using weak or no password hashing. It takes time for the CPU to do the necessary processing to hash the password before it can be matched.

However in FarCry 6.x, over time you might find that logins get slower and slower (taking 10 or 20 seconds or more). This was due to the way 6.x checked a log table for recent password failures, as the log grew the logins got slower and slower. This won’t happen in 7.x since the password failures are now stored against the user, so the login speed should remain predictable / relatively constant.

You can tune down the “work factor” of the hashing algorithm if login speed / CPU time is really becoming a factor (e.g. you are handling hundreds of new logins per minute). Assuming bcrypt is selected as the algorithm in the “Security Config” in the webtop, I think you can tune it down by extending core/packages/security/bcryptHash.cfc into your project, and setting the the “workfactor” attribute in the cfcomponent tag to a number smaller than 10. The smaller the number the faster the hash, but also the lower the security of the hash.

Other than that, the first load of the webtop may be slower if you have a very large webtop navigation structure. Is your app quite small or quite large? Another thing to check (if you’re running Adobe CF) is that you don’t have debugging enabled as this could slow things down a fair bit, it’s best to turn off debugging when trying to track down performance issues as it adds a large overhead.

How many roles does the application have? Do you have a lot of permissions in place?

If it’s a performance bottleneck we can replicate we’ll certainly look at optimising, but at the moment we don’t see that sort of behaviour in our operating environment.

The barebone skeleton is used on this application, the farRole, farGroup, farUser and farPermission are untouched after installation.

I did some testing the login with bcrypt takes about 700ms.

Something strange going on here, the getAllItems() takes ages to finish.

We have the same results both on CF10 and CF11.

You should turn off debugging output, it will slow things down a lot and isn't useful as a performance profiling tool because it adds it's own very large overhead.

Debugging was turned on for 10 seconds to take the screenshot.

What I mean is that the numbers in that screenshot aren't a true reflection of the performance under normal conditions - they can be quite misleading if you are trying to chase down performance issues based on what you see in that output.

To measure the performance of a particular method or block of code I would turn off debugging and place a getTickCount() before and after, then calculate the difference between the two values.

I think from memory webtop.cfc getAllItems() should be sub 50ms (except for the very first time a user with a particular combination of roles logs in, because it has to calculate a cache permissions). But, if it is consistently slow on subsequent logins then we should definitely take a closer look :)

I completely agree, it was mainly to give a quick feedback. I have added some code to measure performance in the code.
---------------------------------------
loginRequest 343 processLogin()
getAllItems 2886
getItemDetails 0


Inside getAllItems()
---------------------------------------
getID() 0
getCurrentRoles 0
getContentType 0
getItem() 2886

Do you want me to do some measuring ingetItem()?

This site runs alone on a Dell server with IIS 7.5, Windows 2008 xeon, CF11. The specs: CPU I think its a 2,4GHz quad core and 8 GB og memory, the DB (MSSQL 2008) is located on another server with good specs.

Just a follow up to this, getAllItems() will only take some time to process when the role(s) you are logging in with don’t have their webtop permissions cached yet. This is generally the case when you are logging in for the first time after the app has been restarted (or if groups/roles/permissions have been edited causing the permission cache to be cleared).

On subsequent logins getAllItems() should only take 0-1ms :slight_smile:

That is strange - getAllItems() is slow on all requests also on subsequent logins with the same user/role. Any suggestion how to debug this further?

Do you have the old "developer mode" flag turned on in one of the serverSpecificVars files perhaps?

Is it expected behavior that getAllItems() should run twice per login?

This is strange because it’s not the behaviour I’m seeing… I guess something in your app could be clearing the stPermissions struct or reinitialising application.security?

Could you perhaps test this on a simple Fandango install and use the same logging and let me know if you still have the problem? I’ll need a way to reproduce this, but I’m not sure how.

You can see the permissions getting cached in stPermissions, 4 lines after the code you referenced in the above link:

In regards to when getAllItems() is called, it’s not per login but twice per request; once for the webtop controller to set up the state of the current location within the webtop, and once for the header to render the navigation.

1 Like

I’m flagging the issue as [closed] – please feel free to update the thread if this still appears to be a problem (beyond the bcrypt work factor).