Err, TWO metres apart unless you are using medical grade PPE mask, face guard, protective suit, gloves etc...
Mark
Moderator: druellan
Err, TWO metres apart unless you are using medical grade PPE mask, face guard, protective suit, gloves etc...
Apologies [mention]1024MAK[/mention]. You are quite right. The 1M does not start until Saturday 4th July (England). By the way, who on earth came up with the idea of re-opening all the pubs on a Saturday....
Code: Select all
J.K. Greye Software Ltd's {3D Monster Maze|J.K. Greye Software Ltd} for the ZX81 emulated on a 128K Spectrum.
Code: Select all
J.K. Greye Software Ltd's {3D Monster Maze|J.K. Greye Software Ltd|0028617} for the ZX81 emulated on a 128K Spectrum.
Code: Select all
J.K. Greye Software Ltd's {software|0028617} for the ZX81 emulated on a 128K Spectrum.
You're obviously confused. This is the Spectrum Computing form. This section is ZXDB discussion, so this thread - about the use of ZXDB on WoS - is perfectly on topic.
Is it really so? As far as I can see, at least logo (which is a truely static asset) is being served through Apache. And anyway PHP-FPM is also working through apache process, so it cannot be faster than apache itself.Mike Davies wrote: ↑Fri Jul 03, 2020 12:09 pm Note: SC doesn't use Apache to serve up static assets, and I believe it's using PHP-FPM -- which is why SC is still quick loading when dealing with traffic levels multiple times higher than what currently takes WoS down.
He's not confused at all, Mike.Mike Davies wrote: ↑Fri Jul 03, 2020 6:43 pmYou're obviously confused. This is the Spectrum Computing form. This section is ZXDB discussion, so this thread - about the use of ZXDB on WoS - is perfectly on topic.
The WoS forum, too, is even more so on topic. Remember when Fogarty said his development plan for WoS was to integrate the WoS forum with the rest of the site, so your login details would also be used when you submit a change? That indicates that the intention of new WoS is to not have a "separate forum". And WoS is using ZXDB. Highlighting that on the WoS forum is perfectly on topic -- heck Einar's post is in the Updates section -- the section of the forum that talks about updates to the World of Spectrum archive.
Really, you are confused, @polomint.
Why are Fogarty and Chandler keeping quiet? Why don't they offer a clear explanation of how it is all these details noticed by Einar are completely coincidental, and not taken from ZXDB? Don't you find that odd?
I, for one, praise Einar for making his point publicly, and standing his ground. The evidence is irrefutable -- you must already recognise that.
Yeah, that would be really appropriate, wouldn't it Mark?
This is not my forum and I’m just an ordinary user here. Just as I’m just an ordinary user over on WoS.I wrote:You know what Einar has said publicly on both forums.
As an observer, it does seem to me that he does make a very convincing case.
errr... no. PHP-FPM doesn't run through an apache process. It's a standalone process manager. Once you're on the process manager stage, you'd also realise there's no point running Apache, and instead run NginX. And Nginx handles concurrent requests a heck of a lot better than Apache, lightweight and faster. And only requests that need to be handled by PHP are proxied to the PHP-FPM process, and scaling horizontally becomes just a config tweak in Nginx.moroz1999 wrote: ↑Fri Jul 03, 2020 7:30 pmIs it really so? As far as I can see, at least logo (which is a truely static asset) is being served through Apache. And anyway PHP-FPM is also working through apache process, so it cannot be faster than apache itself.Mike Davies wrote: ↑Fri Jul 03, 2020 12:09 pm Note: SC doesn't use Apache to serve up static assets, and I believe it's using PHP-FPM -- which is why SC is still quick loading when dealing with traffic levels multiple times higher than what currently takes WoS down.
Ok, PHP-FPM can be run on nginx as well, that's true. What I meant is that PHP-FPM is not an HTTP server, and it requires one.Mike Davies wrote: ↑Fri Jul 03, 2020 8:57 pm errr... no. PHP-FPM doesn't run through an apache process. It's a standalone process manager. Once you're on the process manager stage, you'd also realise there's no point running Apache, and instead run NginX. And Nginx handles concurrent requests a heck of a lot better than Apache, lightweight and faster. And only requests that need to be handled by PHP are proxied to the PHP-FPM process, and scaling horizontally becomes just a config tweak in Nginx.
For the record, no-one from the WoS admin team has responded fully to Einar's concerns in the same manner Einar raised them. And that same team is quite content to slander Einar and his work at every turn.
it is hard to do while WoS team keep on delivering.
Apache concurrency is limited to how many child processes you are running. 10 child processes, 10 concurrent requests. The maximum number of child processes you can run is based on how much RAM a child process needs, and how much RAM your server has. The size of the child process is based on which extensions you enable in Apache. Something like mod_php plus a bundle of "standard" extensions can seriously weight down a child process, and hit the number of concurrent requests the server can handle.
I want it all the same Mark, even more than that.1024MAK wrote: ↑Fri Jul 03, 2020 8:55 pm @Pegaz
Hey, I’m not on anyone’s side and I certainly have no intention of being anyone’s ‘boy’ or of being ‘played’. I make my own decisions based on the information available to me.
Hence elsewhere I said:This is not my forum and I’m just an ordinary user here. Just as I’m just an ordinary user over on WoS.I wrote:You know what Einar has said publicly on both forums.
As an observer, it does seem to me that he does make a very convincing case.
I would prefer the community to work together rather than against one another, that’s all.
If you want to carry on talking about WoS in this topic, that’s up to you.
Mark
Sorry, I don't get it. How would you pass request data to PHP-FPM without a web server? Whether it is Apache or nginx. Otherwise I agree to the concept you are writing about. It's just my initial comment was an answer to your post:Mike Davies wrote: ↑Fri Jul 03, 2020 9:22 pm Offloading PHP from Apache into a process manager means apache child process can be much smaller. Not every request needs a PHP engine -- static assets certainly don't. So you can get Apache to deal with the static asset requests (and redirections, ssl handshakes, authentication, etc.), and proxy to a process manager when a PHP script needs to handle the request. That pushes the concurrency level much higher, because you can shape both the apache child process and FPM processes based on your traffic.
Points which made me asking for the details are these. As far as I know:Mike Davies wrote: ↑Fri Jul 03, 2020 12:09 pm Note: SC doesn't use Apache to serve up static assets, and I believe it's using PHP-FPM -- which is why SC is still quick loading when dealing with traffic levels multiple times higher than what currently takes WoS down. And on a fraction of the computing power. You (SC) are doing some things right, and better than WoS on a technical level.
Confusion is relative, and so is manipulating the thoughts of others...Mike Davies wrote: ↑Fri Jul 03, 2020 6:43 pmYou're obviously confused. This is the Spectrum Computing form. This section is ZXDB discussion, so this thread - about the use of ZXDB on WoS - is perfectly on topic.
PHP-FPM can be used instead of mod_php. Mod_php is an Apache extension that put the full PHP runtime into each Apache child process.
But you still need some http server, whether it is FPM or mod_php. And it is Apache on SC. And I am pretty sure that there is no HHVM on SC, there is Apache + PHP-FPM, which are effective enough for SC needs.Mike Davies wrote: ↑Fri Jul 03, 2020 9:53 pm PHP-FPM can be used instead of mod_php. Mod_php is an Apache extension that put the full PHP runtime into each Apache child process.
I don't think SC uses PHP-FPM, but HHVM instead. Which is a facebook-optimised PHP runtime.
it is too late. if they'll do it, they would have to admit that they were lying all along, and were trying to cover their traces. considering the hyperinflated ego of some WoS team members it is very unlikely that they will agree to accept their wrongdoings. even if we all will promise to never ever talk about that again. alas.