OK, sounds like sunshine is getting the best of you. It's working with a pretty heavy load, I see ways of solving potential problems that haven't become a problem yet, and I'm enjoying it.
Maybe you should tone down the coaching until someone asks for it. Regards, Morten On Fri, Jul 29, 2022 at 10:46 PM Chris Angelico <ros...@gmail.com> wrote: > On Sat, 30 Jul 2022 at 04:54, Morten W. Petersen <morp...@gmail.com> > wrote: > > > > OK. > > > > Well, I've worked with web hosting in the past, and proxies like squid > were used to lessen the load on dynamic backends. There was also a website > opensourcearticles.com that we had with Firefox, Thunderbird articles > etc. that got quite a bit of traffic. > > > > IIRC, that website was mostly static with some dynamic bits and heavily > cached by squid. > > Yep, and squid almost certainly won't have a thread for every incoming > connection, spinning and waiting for the back end server. But squid > does a LOT more than simply queue connections - it'll be inspecting > headers and retaining a cache of static content, so it's not really > comparable. > > > Most websites don't get a lot of traffic though, and don't have a big > budget for "website system administration". So maybe that's where I'm > partly going with this, just making a proxy that can be put in front and > deal with a lot of common situations, in a reasonably good way. > > > > If I run into problems with threads that can't be managed, then a switch > to something like the queue_manager function which has data and then > functions that manage the data and connections is an option. > > > > I'll be quite frank with you: this is not production-quality code. It > should not be deployed by anyone who doesn't have a big budget for > "website system administration *training*". This code is good as a > tool for YOU to learn how these things work; it shouldn't be a tool > for anyone who actually has server load issues. > > I'm sorry if that sounds harsh, but the fact is, you can do a lot > better by using this to learn more about networking than you'll ever > do by trying to pitch it to any specific company. > > That said though: it's still good to know what your (theoretical) > use-case is. That'll tell you what kinds of connection spam to throw > at your proxy (lots of idle sockets? lots of HTTP requests? billions > of half open TCP connections?) to see what it can cope with. > > Keep on playing with this code. There's a lot you can gain from it, still. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- I am https://leavingnorway.info Videos at https://www.youtube.com/user/TheBlogologue Twittering at http://twitter.com/blogologue Blogging at http://blogologue.com Playing music at https://soundcloud.com/morten-w-petersen Also playing music and podcasting here: http://www.mixcloud.com/morten-w-petersen/ On Google+ here https://plus.google.com/107781930037068750156 On Instagram at https://instagram.com/morphexx/ -- https://mail.python.org/mailman/listinfo/python-list
