@asdf1337 do you know which version of Java you are using? Someone else reported slower performance and it ended up being Java 7 as being much slower than Java 8 (we have not fully figured out why but think it may be something involving invokedynamic [which we increased in using since 9.1.2.0]).

I thought it might have been the Java version as well, so today I upgraded but I've been using 8 the whole time. Went from java "1.8.0_91" to java "1.8.0_101".

Running the program with or without invokedynamic doesn't seem to do much either.

@asdf1337 thanks for checking. Some issue of invokedynamic are always on now but the fact you see this with Java 8 has me be hopeful that we just regressed in some other area

@asdf1337 Ok, we really want to fix this, but we need a way to reproduce so we can profile it.

If that's not possible, you'll have to do the profiling and we'll talk through it.

We have a wiki page on profiling here: https://github.com/jruby/jruby/wiki/Profiling-jruby.

Thank you for reporting this! We definitely should not regress this badly on performance, so we'll want to fix this up for 9.1.60.

Awesome! I'm going to put together a minimal version of my code that hopefully still exhibits the same effects.

It may not be possible to get it down to a version I can share easily.
When you have time let's go through the profiling procedure.
Thanks again.

This isn't going to make 9.1.6.0, and I apologize for the lack of progress here.

I have written up a wiki page on various methods of profiling JRuby here: https://github.com/jruby/jruby/wiki/Troubleshooting-Performance

These flags will give you a good start on profiling. Keep in mind the allocation profile will be very slow, so what you really need is to just ensure the main work of your application has been running for a while; it doesn't have to complete to be useful. We're looking for really high allocation counts in the resulting output.

You can also stop by IRC (perhaps after RubyConf this week) and some of us will be there to help you.

@asdf1337 - Is it possible that this is a manifestation of jruby/jruby-openssl#111
If so, we had success instantiating a certificate store, freezing it, assigning it to a constant, and then passing it into every HTTP request we made. The way to pass the certificate store varies depending on what library you use, but we've gotten it working with both httparty and rest-client. I have also had an engineer on our team make the claim that it doesn't matter if the request is HTTP or HTTPS or not, that the certificate store was being constantly reconstructed regardless, but I don't know if that assertion is true across all libraries.

Still an issue? We haven't revisited this in over a year.

I don't know if it there is still a performance degradation because we implemented a workaround (described above) in our application some time ago and it remains in place today. It consists of an initializer in our rails app that defines a constant:

CERTIFICATE_STORE = OpenSSL::X509::Store.new.freeze
CERTIFICATE_STORE.set_default_paths

In every place where we use HTTParty to make outbound connections, we pass in the constant as the value of the cert_store parameter like so:

HTTParty.get url, cert_store: CERTIFICATE_STORE

In every place where we use RestClient, we use a similar strategy:

RestClient::Request.execute method: :get, url: url, ssl_cert_store: CERTIFICATE_STORE

I still believe this issue is related to jruby/jruby-openssl/issues/111 - I haven't tried dropping the workarounds since that issue remains open.

Not sure what progress has been made on this. Mostly pending jruby-openssl work I believe.