Native vs. Plug-in Authentication

Question

We've been doing some testing of CompleteFTP and we like what we've seen so far. The plug-in architecture for .Net is very nicely designed and suits our needs particularly well, especially for events. Hooray!

One thing we've noticed in our testing is that the native CompleteFTP authentication appears to produce significantly better performance numbers in our stress test benchmarks than a custom authentication plugin, even when said plugin does no lookups, just returns true for authentication. Is this due to the plugin call overhead?

We tried writing directly to the CompleteFTP tables in the config.sdf file but the user we created wasn't active until the service was restarted, so we're assuming that the native authentication credentials are cached at startup and updated when "Apply Changes" is clicked in the admin tool. Is that the case?

We're looking for the most performant method of user authentication where we can manage the creation/update/deletion of users. It would seem that the authentication extension feature will let us maintain the users in our own database but at the cost of some performance. Can anyone confirm this hypothesis?

Thanks in advance,

Bob Mc.

Answer 1

Hi Bob

Yes, the database is only read on start-up.

We were actually not aware that authentication via plug-in was significantly slower than native authentication. There's very little overhead, so it's a little surprising. Can you please describe your tests? Also, have you got other authenticators enabled (e.g. DB-auth) that might be slowing things down? Could you please set the logging level to DEBUG and do an authentication. The log may reveal the reason for the performance.

- Hans (EnterpriseDT)

Answer 2

Hans,

Thanks for confirming the database start-up read hypothesis. It makes sense, and confirms that we should use the authentication extension approach.

All other authenticators were disabled, so I don't think that's the issue.

We're testing via a custom upload/download app. The upload process establishes a connection for each file and disconnects after each file upload, to mirror the situation we'll encounter in production deployment. We're uploading about 4,000 files via four threads, so 1,000 files per thread with an authentication for each file.

The logging didn't indicate anything unusual. But it does indicate that the authentication extension is working quite quickly, as you indicated.

I'll try to post some benchmark information for you regarding my claim that the native authentication is faster, but given what you just confirmed it makes sense. When you natively authenticate you're probably just doing a lookup to a shared dictionary of users loaded at startup, whereas the authentication extension instantiates a POCO object each time an authentication is requested, or so it appears via .Net debugging. It then invokes the implemented methods of the instantiated extension via whatever mechanism you employ. Therefore it is bound to be somewhat slower over a large number of authentication requests (4000+).

However, it's probably not an issue for us. We will likely make a purchase based on the strength of what we've seen so far.

Thanks,

Bob Mc.

Answer 3

Hans,

Here's another related question. Your admin app for CompleteFTP must be communicating with the CompleteFTP service in order to notify the service that user credentials have been updated. Is it possible to invoke that same mechanism from our application? This way we could add native CompleteFTP users to the "config.sdf" database and signal the service that a change has been made, similar to what you do in the admin application.

Bob Mc.

Answer 4

Actually you can do that easily now, via SSH, with 7.0, which has just been released:

http://www.enterprisedt.com/products/co ... admin.html

Answer 5

Oh, that's very nice. I like the clustering support as well. We'll give this a test run and see how it looks, hopefully before my trial version runs out.

Bob Mc.

Answer 6

We can extend your trial if needed.

- Hans (EnterpriseDT)