Hi Jay. I’m new to Lucee as well coming from ACF. I would try adding the following lines to the AJP connector in the lucee\tomcat\conf\server.xml file:
maxThreads="500"
keepAliveTimeout="-1"
packetSize="65536"
Then add the following to the C:\Windows\BonCodeAJP13.settings file to match those parameters:
<MaxConnections>500</MaxConnections>
<PacketSize>65536</PacketSize>
See if that helps in any way.
Erick
Your issue stems from a lack of technical understanding of how Windows DNS works
& How Windows Name resolution works
https://support.microsoft.com/en-us/topic/microsoft-tcp-ip-host-name-resolution-order-dae00cc9-7e9c-c0cc-8360-477b99cb978a
We could sit down and go into how your server is actually configured, how many NICS, what time of switch, so on an so forth, but instead, here is some more reading:
I am sure you made sure the default send window was already set to match your network speed or internet facing speed, long before you came here only to say its a software issue.
But @Terry_Whitney, this issue doesn’t sound like a DNS problem, because everything else works fine and without any issues. If DNS would be the issue, it would have heavier symptoms, or not? It’s just the isolated issue with the fileupload that is taking a longer time on big files, and a test also showed that the issue triggeres when using the BonCode with IIS. I bet some tweakings will probably resolve it. I also never had such an issue, but just like @Julian_Halliwell I never had to deal with bigger files in fileuploads.
ACF adds a patch so their helpdesk isnt flooded with “I cant acess localhost” as their default install points CFIDE to localhost.
Windows is schizophrenic when it comes to understanding Localhost. Its been patched and re-patched over the years but even on fresh installs of 2019 IIS cant find localhost 1 in 8 times. Its random, its crazy but same system you install ACF on it and suddenly that windows box understands what localhost is. I am pretty sure that its hardcoded inside the isapi_redirect.dll.
So we will assume, at least I have that he fully patched windows 2016, then installed lucee on top of IIS.
He compaired IIS ACF to IIS Lucee, its different.
IIS is by default looking at every request, doing a lookup, then matching the lookup to the service filter.
Here in is the problem, his box is doing packet chunk by packet chunk, lookup for localhost, which first is trying His configured DNS Servers, then after that lookup fails, falls back to localhost then passes the data along. Its slow, which is the issue.
Hence the quick fix tell your Windows Box its localhost, the long fix is to properly tweak the hell out of your network and tell your Windows IIS install to do nothing but serve data and ignore DNS requests. To me, it seems like we are trying to physically beat a known issue with Windows into overhead for lucee, its not needed. Proper name resolution and network setup is key for speed in IIS, let alone Lucee which doesnt have all the crap and overhead that ACF has added…
@Terry_Whitney : At no time in this entire thread did I ever mention the use of localhost.
Let me be clear. This is absolutely Not a DNS issue having been proven by a direct load of jvm and tomcat. I am not the typical dev jacking off on localhost. This is a remote server setup proven 2 times over. localhost and DNS have absolutely nothing to do with it.
You’re not reading. Your just assuming. So I’m going to ask you to stop derailing this thread with your assumptions which are clearly evident from the first time you posted. Stop pumping this thread full of irrelevant garbage making the thread longer to get through.
Please Jay,
Now I am curious as hell.
How exactly does IIS talk to your lucee instance.
Is IIS running as PROXY over the network to a local box running Lucee, which is different that what you stated originally.
Please, do tell.
The more articulate and technically accurate you are, the better.
Thanks.
Well Jay,
That makes two of us.
Best of luck on your issue.
Are there no Moderators Here? … should we even need them?
I should not have to contend with adolescent forum jockeys…
I’m one of the moderators here… let’s just leave all the personal commentary aside OK?
so you aren’t using localhost? I honestly also assumed that as well
I’d suggest firing up procmon and seeing what the OS is doing during the slow upload
@Zackster Zac I completely understand. But literally from post 1 it’s total irrelevant and by definition : absurd assumptions leading to this thread Blowing up into totally irrelevant and subsequently confusing dialog for anyone else that reads.
I would like to think I’m among professionals but for real : look at his 1st post : it’s on another planet…
if you aren’t using localhost what are you using?
a hardcoded IP on a subnet with host header… using a hardcoded domain name
[Irrelevant Reading Removed by: Jay.MC]
[Update : SOLVED]
On an Absolute and Total Freak Accident : I solved it.
The bottom line answer is server.xml should be in XLM Format that would pass a parsing test.
@erick had most of the answer in his reply about : packetSize=“65536” - This is CRITICAL: so Many Thanks!
– Upload of 10MB now 300ms
– Upload of 80MB now 3-4 seconds
Some Detail:
This covers 2 known issues:
— this Slow File Upload issue…
— and The 1-Second Delay issue
Both are related to the format of : server.xml
Typical Path : C:\lucee\tomcat\conf\server.xml
Being a neat freak about code I got sick of all the commentary in the file. So I stripped it down inadvertently resulting in a properly formatted XML File. This was totally unexpected because I had been tweaking the file for days and any syntax error would keep Tomcat from starting. And typically an XML dependent operation will throw an error if not properly formatted.
So, apparently Tomcat IS Filtering Most comments and Line Breaks : But Not All : It is not Perfect. Tomcat should Enforce XML compliance (As IIS Does)… or Not. . It’s nice to be able to comment in files… but this cost me 3 days.
This also had the unexpected effect of solving the 1 second delay issue which was previously solved by changing out name=“127.0.0.1” - TO - name=“::1” … to solve the 1-second delay issue. That was a big hassled because it was cutting off access to the default Lucee Admin (which is probably a good security thing anyway). I’ll admit I was close to giving up and accepting 3 seconds on 10MB and up to 2+ minutes on an 80MB… but I’ve never quit on something like this and shouldn’t start now. If I dump even 50 users on there that are uploading constantly that would be a lot of overhead that doesn’t need to happen.
I may write a more detailed solution summary if I can spare the time.
Many Thanks to everyone that helped!
I will attempt to paste my code and I don’t care about the secret because it’s just a local VM on my desk
<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector port="8888" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
<Connector protocol="AJP/1.3" port="8009" secretRequired="true" redirectPort="8443" packetSize="65536" secret="095bf67d8"/>
<Engine name="Catalina" defaultHost="127.0.0.1">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="127.0.0.1" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
<Valve className="mod_cfml.core" loggingEnabled="false" maxContexts="200" timeBetweenContexts="2000" scanClassPaths="false" responseCode="307" sharedKey="a2e54e57cb4b"/>
</Host>
</Engine>
</Service>
</Server>
That’s awesome news @Jay.MC Yeah!!! Well said! Don’t quit!!! Never give up!!!
Lucee is an awesome cfengine, it has some pitfalls, but as soon as you get more familiar with it and that common pitfalls you’ll be feeling so well and comfortable . I still remember, when I’ve switched to Railo I was completely overwhelmed with everything. Nowadays I love looking into the raw source code, digging for undocumented stuff. With Lucee I’ve found my love for CFML again and that has been going for years now.
And by the way: thanks for posting and sharing your solution!
@Zackster …
… I find that I cannot alter the Title of the thread to append the word [Solved 2021]. I was able to do it before but perhaps it’s crossed some sort of threshold. The addition of that word would definitely help user click through to the forum when they are surfing for answers on Google…
I feel it would really help move this forum towards more Complete Documented Cases and their resolutions and result in more of a knowledge base and less time digging through ancient forum discussions.
I understand there are few people that would have time to work on that and we do have the solution elevated to the top once it has been achieved. But still a user is far more likely to click a link that includes the statement of [Solved] in the title.
So, while we may not have the time to condense/integrate forum discussions into a formal knowledge base… perhaps we can append the word [SOLVED and the Date such as 2021] to the titles.